MSMQ Poison message and TimeToReachQueue

Question

I tried creating a poison message scenario in the following manner.

1- Created a message queue on a server (transactional queue). 2- Created a receiver app that handles incoming messages on that server. 3- Created a client app located on a client machine which sends messages to that server with the specific name for the queue.

4- I used the sender client app with the following code (C# 4.0 framework):

System.Messaging.Message mm = new System.Messaging.Message("Some msg");
mm.TimeToBeReceived = new TimeSpan(0, 0, 50);
mm.TimeToReachQueue = new TimeSpan(0, 0, 30);
mm.UseDeadLetterQueue = true;

mq.Send(mm);

So this is setting the timeout to reach queue to 30 seconds.

• First test worked fine. Message went through and was received by the server app.
• My second test, I disconnected my ethernet cable, then did another send from the client machine.

I can see in the message queue on the client machine that the message is waiting to be sent ("Waiting for connection"). My problem is that when it goes beyond the 30 sec (or 50sec too), the message never goes in the Dead-letter queue on the client machine.

Why is it so ? ... I was expecting it to go there some it timed-out.

Tested on Windows 7 (client) / Windows server 2008 r2 (server)

Answer 1

Your question is a few days old already. Did you find out anything?

My interpretation of your scenario would be that the unplugged cable is the key.

In the scenario John describes, there is an existing connection and the receiver could not process the message correctly within the set time limit.

In you scenario, however, the receiving endpoint never gets the chance to process the message, so the timeout can never occur. As you said, the state of the message is Waiting for connection . A message that was never sent cannot logically have a timeout to reach its destination .

Just ask yourself, how many resources Windows/ MSMQ would unneccessaryly sacrifice - and how often - to check MessageQueues for how-many conditions if the queues is essentially inactive ? There might be a lot of queues with a lot of messages on a system.

The behavior I would expect is that if you plug the network cable back in and the connection is re-established that then, only when it is needed, your poison message wil be checked for the timeout and eventually moved to the DeadLetter queue.

You might want to check this scenario out - or did you already check it out the meantime?