Service Bus Queues provide a one-way message exchange pattern to pass messages between distributed and loosely coupled applications using the Azure SDK, WCF, AMQP, or HTTPS endpoints. These queues provide load leveling, by default, where the receiver processes messages off the queue at its own pace.
Load leveling can also be easily implemented by reading the queue length property and spinning up more processes to read the queue concurrently. As the queue length diminishes, the extra processors can be taken offline. When using multiple processors to read messages from the same queue concurrently, careful consideration must be given to the type of read lock you wish to perform. More about this is explained in the section Retrieving messages off a Queue.
There are many uses for this type of coupling pattern:
- Hybrid applications, which allow you to connect an on-premises application to a cloud-hosted service or application
- Loosely coupled applications, where Service Bus acts as a message broker between different systems
- Mobile applications, where clients are occasionally connected to a network
- Offline/batch processing, where the queue consumer is only available for a limited time span
While designing a queuing mechanism, consideration should be given to the size of each message. The current maximum content message size for Azure Queue Storage is restricted to 64 KB, whereas for Service Bus Queues, the restriction is 256 KB for the Basic and Standard tier whereas 1 Mb for the Premium tier.
To deal with the message size restriction, there are several options available. One option would be to use blob storage to store the message content and use the queues to hold metadata about the message and URI path.
Another option is to use sessions and break up the messages into smaller sizes (known as chunking). Each message chunk is placed on the queue with the same session identifier key. This instructs Service Bus to place all the received message chunks onto the same partition and in the correct sequence. The consumer would then read all the message chunks from the queue with the matching session identifier to reconstruct the entire message.
Each message has a time to live (TTL) property, which specifies how long a message will be available in the queue. If the message does not get consumed within the specified TTL value, it will be moved to dead letter queue. The maximum TTL for Azure Queues is seven days, whereas it is unlimited for Service Bus Queues.
Dead-lettering normally occurs when a message cannot be processed, either because the message is formatted incorrectly or because the TTL period has been exceeded.
In Azure Service Bus, the message will be placed on the $DeadLetterQueue subqueue for the following reasons:
- If the read message fails to get processed and reappears on the queue more than 10 times. This is the default maximum delivery count.
- When the message reaches the TTL threshold and the dead-lettering flag has been set in the queue or subscription.
- When a subscription filter evaluation exception occurs and dead-lettering is enabled on the filter.
Automatic dead-lettering does not occur for the ReceiveAndDelete read mode. This is because the message is automatically deleted from the queue once it has been read.
If using topics with multiple subscriptions, each subscription will have its own $DeadLetterQueue subqueue.
Sessions allow grouping of related messages to be processed in a single batch by the consumer. This guarantees FIFO delivery of the related messages.
Typically, the SessionId property on the BrokeredMessage class is used as the partition key. This allows all messages that have the same SessionId key to be handled by the same message broker.
Sessions are ideal when sending a large message (that must be broken up into smaller sizes) to a queue. The deconstructed message parts are then reconstructed into one message at the consumer end.