(Cross-Post) Centralized Dead Letter Queue with Azure Service Bus
Thanks to Sean Feldman for writing this original post here!
Azure Service Bus provides a robust Dead Letter mechanism. Each queue (or subscription) has its dead letter queue (DLQ).
Messages ending up in DLQs are not necessarily poisonous, and potentially could be resolved by re-processing. That means DLQs should be monitored to allow dead lettered messages to be analyzed and re-processed if needed. The issue with this approach is monitoring and troubleshooting. When a number of queues is significant, monitoring becomes a real headache. When a message is moved to its DLQ, it's obvious what queue did it fail. But what about centralized DLQ? If dead lettered messages from various queues are moved into a centralized DLQ, knowing message origin is important to send it back for reprocessing.
Gladly, the recent version of ASB has added an additional standard property on the BrokeredMessage
called DeadLetterSource
. When a dead lettered message is forwarded to another queue, it's stamped with the source queue name.
Below is an example of a test
queue that has DLQed messages forwarded to a centralized error
queue. Assuming we're sending a message that fails the maximum number of deliveries to the test
queue.
The message will be DLQed and automatically moved by the broker to the error
queue.
Now message can be inspected and failed source queue retrieved.
In case of subscriptions, DeadLetterSource
works exactly the same way. I've set up a topic called events
with a subscription called sub
. Dead lettered messages on the subscription are forwarded to the centralized error queue error
.
Once a message on sub
fails more than allowed delivery count, it's moved to the error queue which was specified as a queue to forward to on dead lettering. Inspection of the forwarded message shows the following:
Happy centralized error handling!