Preserve message order when consuming MSMQ messages in a WCF application

4
votes

I have an application that consumes messages from an MSMQ queue. The application uses MSMQ activation of a WCF service hosted in the IIS using AppFabric.

It is essential that the order of messages is preserved. But does MSMQ guarantee that the message order is preserved?

It seems to me, that if my application fails to process a message, e.g. because of a broken connection to the database, then the message is moved to the retry queue. This allows the application to receive new messages from the main queue until the original message is moved from the retry queue back to the main queue. After a certain number of retry intervals, the message is moved to the poison queue. But if the application processes new messages, then poison queue handling is simply not an option.

Thus the order of the messages has not been preserved.

Am I wrong in my understanding of how application errors are handled?

Can I setup the binding so that message order is preserved, also in the case when message processing temporarily fails?

1
.netwcfmsmq
possible duplicate of Ordered Delivery with netMSMQbinding – tom redfern
Not really sure why do you wish to achieve this. The idea in using message queues is that if something fails it doesn't halts any other commands/message handling. If I understand you correctly, you want to do just the opposite of this (stop message handling when a failure occurs until it's sorted), is that right? Otherwise, any succeeding failures will be stacked in the failure queue in the correct order, so that retrying should work as soon as the problem got sorted. – nieve

1 Answers

3
votes

Pete,

A few tips from experience:

  1. nieve is correct, you should not rely on message order - if you have such a situation then the succesfull execution of the first message should trigger the next, they should not all be sent in the queue at the same time.
  2. For most people this doesn't seem relevant but one day, it may become so - how will this application scale? If one day you find yourself forced to place multiple workers on the destination of the queue - how will this scale to multiple machines? Your model will fail due to the fact that there cannot be parallel execution of messages.

I highly recommend that you investigate the Saga Pattern, this is the answer to this type of problem, it is offered by products such as NServiceBus and MassTransit which will both remove the difficulty of having to manage MSMQ directly which you are stuck doing.

I understand that in your situation you may simply not have a choice and cannot "throw away" the model you are using, however it would be much more to your advantage to trigger a message and then on successful execution of this message (Saga), you could then insert the next message.

I hope this helps,