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.
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.