How do you 'verify' that a message sent using MSMQ to a private local queue was actually delivered? I'm especially thinking of a scenario where the listener (a C# service in my case) is not running and therefore delivery can't be successful.
+1
A:
It's always sent to the queue.
If your service isn't running to receive it, it just sits there, waiting patiently, until someone receives it.
You know it's been sent to the queue because .Send() returns without crashing.
Noon Silk
2009-08-30 00:45:11
Can I query the queue for the number of messages waiting, without actually taking the messages out of it?
Alex
2009-08-30 00:46:15
I'm not sure, I've never tried. There is `MessageQueue.GetAllMessages()`, but they may pop them off the queue. I suspect you can though, because the Windows Servers MMC snap-in can tell you.
Noon Silk
2009-08-30 00:49:15
Will Peek() do this? It's worth a try.
David Stratton
2009-08-30 01:03:10
I wouldn't think so, that just shows the next message, it doesn't let you count them.
Noon Silk
2009-08-30 01:06:20
+1
A:
You can only guarantee that it can get to the queue without taking extra steps. To deal with the "not running receiver" scenario, you would need to code the receiver to send a message back to the server when it processes the message. The original sender would be responsible for tracking the sent messages and verifying that the client has recieved them.
That's one of the decisions you should be taking when deciding whether or not to use MSMQ as opposed to a remoting or a web service scenario. For example, we had a project used for notifying all of our retail locations when an emergency occurred (such as a product recall/food safety issue.) We needed to know immediately if the store's listener was running so we chose remoting, and when the sender received an error indicating one of the listeners was not listenting, we would need to pick up the phone and call.
Just something to keep in mind.
Edit - clarification
I was really giving out two options above.
- Code the client to send a message back to the sender when it receives a message.
- Use another option, such as remoting, where you can detect if the client is running and receives the message.
David Stratton
2009-08-30 00:51:42
Just be clear, you're talking about checking if the *receiver* was running, not that it actually just went *onto the queue*. There is a difference.
Noon Silk
2009-08-30 00:52:46
Yes, but that's not what was asked (IMHO). That's about the integrity of your app, not MSMQ.
Noon Silk
2009-08-30 01:02:11
I don't want to argue, but look again at the question. He specifically asked "I'm especially thinking of a scenario where the listener (a C# service in my case) is not running and therefore delivery can't be successful."
David Stratton
2009-08-30 01:11:41
Fair enough, I just didn't want anyone thinking that you needed to specifically verify if a message went onto the actual queue.
Noon Silk
2009-08-30 01:16:34
A:
When you send a message you can specify the AcknowledgeType which will allow you find out (through positive or negative acknowledgement) whether the message reached the queue and/or was received from the queue. Acknowledgements are sent as messages, by MSMQ, to the AdministrativeQueue so make sure you assign that property on the Message object.
You can check the administrative queue for acknowledgements by correlation ID which is ID of the original message.
bfallin
2009-09-09 05:45:43