MSMQ throws away messages if the destination queue does not exist?

Question

I've encountered a weird situation:

Messages are sent from ServerA to ServerB. It goes into ServerA outgoing queue and then sent to ServerB's queue.

ServerB crashed. We had to reformat. When we brought it up, we forgot to install the MSMQ Service.

Messages begin pilling up in ServerA's outgoing queue until the program that sends messages throws an insufficient resources exception.

We notice the the error and installed the MSMQ Service onto ServerB. ServerA begins to immediately emptying its outgoing queue.

When we started the program to process messages on ServerB, it couldn't connect. We learned that we forgot to create the queue on ServerB. However, by this time, it was too late. All 900K messages that sat in ServerA's queue has been sent to ServerB. From what I can tell, ServerB threw them away because it was not configured with the destination queue. I already know that the correct solution is to STOP the queue on ServerA until after we've completely setup ServerB.

The question is: Is this really the true behavior that we should expect from MSMQ? I would've thought that a more defensive design approach would've been for ServerB to reject the messages instead of taking it and throwing them away.

Answer 1

It really depends a lot on what kind of queues you're using and what assurances you asked MSMQ to take with the messages. Remember that messages in MSMQ have time to live times that can expire while the message is in transit (or even Time to Read limits).

Depending on how you configure the sender, message that could not be delivered might have made it to a dead-letter queue, so I'd definitely check that on both servers to see what went there.

You can ask MSMQ to do a lot more if that's an scenario you want to handle better. For example, you can ask it to keep a copy of the sent messages in a journal queue (and then drain it as necessary yourself). Or you could ask it for positive or negative ACKs on message delivery or even of the messages getting read. In those cases, the ACK/NACKs are sent to an administrative queue of your choosing which your own app can monitor and respond to.

Answer 2

When opening a queue to send messages to a remote computer (when dwAccess is set to MQ_SEND_ACCESS), Message Queuing does not check for the existence of the queue.

From the MSMQ Docs:

http://msdn2.microsoft.com/en-us/library/ms699817.aspx

The reason seems to be that MSMQ is meant to be used as an async transport so the sender sends and then many different things can happen along the way to cause the message to not be delivered. It looks like the only way to check for sure is to look for negative acknowledgement messages coming back. We have never used these. Either you start using them, or try not to do remote sends.

Usenet thread discussing this.