Question

Here’s a theoretical question:

When I’m building an application using message queueing, I’m going to need multiple queues support different data types for different purposes. Let’s assume I have 20 queues (e.g. one to create new users, one to process new orders, one to edit user settings, etc.).

I’m going to deploy this to Windows Azure using the ‘minimum’ of 1 web role and 1 worker role.

How does one read from all those 20 queues in a proper way? This is what I had in mind, but I have little or no real-world practical experience with this:

Create a class that spawns 20 threads in the worker role ‘main’ class. Let each of these threads execute a method to poll a different queue, and let all those threads sleep between each poll (of course with a back-off mechanism that increases the sleep time).

This leads to have 20 threads (or 21?), and 20 queues that are being actively polled, resulting in a lot of wasted messages (each time you poll an empty queue it’s being billed as a message).

How do you solve this problem?

Answer 1

I read the other answers (very good answers) and wanted to put my own spin on this.

Sticking with Windows Azure Queues, as @Lucifure was describing: I really don’t see the need for multiple queues except for two scenarios:

• You want different priorities. The last thing you want is a high-priority message getting stuck behind hundreds of low-priority messages. Create a hi-pri queue for these.
• The number of message reads+deletes is going to exceed the target of 500 transactions per second. In this case, create multiple queues, to spread the transaction volume across storage partitions (and a storage account will handle upwards of 5K transactions per second).

If you stick with a single queue (storage-based, not service bus), you can read blocks of messages at one time (up to 32). You can easily work up a format that helps you differentiate message type (maybe with a simple prefix). Then, just hand off the message to an appropriate thread for processing. Service Bus queues don’t have multi-message reads, although they do allow for prefetch (which results in buffered messages being downloaded into a cache).

An advantage of one queue over many: you remove (or greatly reduce) the problem of “many queues having no messages, resulting in empty reads.”

If you need more throughput, you can always crank up the number of threads doing the queue-reading and dispatching.

Remember that each delete is atomic; no batching. And as far as queue-polling goes: you’re right to think about backoff. You don’t need to back off after successfully reading a message (or chunk of messages). Just back off when you don’t get anything after an attempt to read.

One nice advantage over Service Bus queues: Windows Azure queues provide you with an approximate message count (which is really helpful when considering scale-out to multiple instances). Service Bus queues don’t provide this.