Watch out, a coding related post.
So I coded up a little MSMQ dumping utility the other day, in part to learn about MSMQ and in part to pick up some domain knowledge around one of the more fragile systems at work. And before you start laughing, yes I know it’s been over 3 years since I wrote a real app, but anyhow I gave it a crack.
Coded the utility up in about four hours, including time to acquire domain knowledge and MSMQ knowledge and ended up with this app:
Now this thing works perfectly on the staging machine, but refuses to return the Queue Count on the live server. Enter the MSMQ from the plumber’s mate blog. Full of lots of little handy hints on how to make MSMQ performance counters actually work.
Why can MSMQ installs get so broken, so often, that an MSMQ blogger can have so much material to talk about when fixing it? I don’t know if I should be happy I found a plentiful source for potential solutions, or worried about the many ways a seemingly simple operation can go wrong?
June 17th, 2008 at 9:38 pm
[...] in reference to my previous post, I finally found a way to extract the queue length of an MSMQ Queue behind a clustered server, and [...]
June 19th, 2008 at 12:37 am
Hi John,
Glad my blog helped with the broken performance monitor counters. I’m not an expert on how the counters are set up but it seems to be some archaic linked list system. The list can be updated by any number of applications for which counters exist so the chance of a faulty change is higher than you’d expect (or want). Usually this error shows up in another unrelated application, such as MSMQ, being unable to load their counters.
Cheers
John
June 19th, 2008 at 4:36 pm
Hi John,
Thanks for the clarification. In hind-sight I was probably a little scathing of MSMQ in this post - isn’t that what blogs are about after all? Though to be honest, this being my first real exposure to using MSMQ from .Net it shouldn’t have been so hard.
The whole situation smacked of the pains I went through back in 2001 trying to get .Net to talk to exchange using WebDav (the recommended approach) with hardly any working examples anywhere to be seen.