Windows Azure Guidance – The “Get”, “Delete” pattern for reading messages from queues

  • Article

Fabio asked me on twitter “why there’re no dequeue, peek and enqueue on Windows Azure Queues?”  

One of the most common patterns for interactions with queues is this:

 

image 

  1. You get the message from the queue. This is not a “dequeue”, even though it looks like one. It is more a “peek & hide”. The message is retrieved and it is made invisible for others.
  2. The worker (or whatever got the message from the queue) does something useful with it.
  3. When work is complete, the message is explicitly deleted.

If something goes wrong with the Worker, then after some (configurable) time, the message becomes visible again and someone can pick the message again. Remember: anything can fail anytime!

 

image 

 

If you had a “dequeue” method, (dequeue = peek + delete), then there’s a non-zero chance your message is lost.

 

Things to consider:

1- Your message could be processed more than once:

a- If the “DoSomething” method takes longer than the time the message is invisible.

b- If your worker crashes just before you delete the message.

2- You must develop your system to handle duplicates.

3- There’s a chance that the process failing is actually due to a problem with the message itself. This is called a poison message. There’s a special property you can use (dequeuecount) to do something about it. For example, you can discard messages that have been dequeued beyond a certain threshold:

if( dequeucount > MAX_DEQUEUES )

      MoveMessageToDeadLetterQueue( message );

 

Fabio, is the floor steady again? :-)