I’ve been writing about and speaking about Azure Service Bus a lot recently.
In this post, I’m going to focus on the Dead Letter Queue in more detail.
What is the Dead Letter Queue, and what has it ever done for me?
To describe what the dead letter queue does, I invite you to think about an assembly line for a car. The car in question has just come through to have a bonnet fitted (hood for any American readers). However, the guy that’s fitting the bonnet can’t get it to sit right in the hinges; he tries and tries, but it won’t fit. After a while, he goes to get his superviser, and they both try. They draft the workers in from all over the plant, but can’t get the bonnet fitted.
Meanwhile, the entire assembly line has stopped. The person that fits the steering wheel is behind the bonnet fitter, and there’s no space for him to move the car that he’s just fitted the wheel to; the dashboard fitter can’t pass onto the steering wheel, and so on.
(I have no knowledge of what a car assembly line looks like, outside of the film Christine, so apologies if this is incorrect).
A message that can’t be processed is often called a poison message, and it causes exactly this problem. The Service Bus can’t deliver any messages until this message has gone, and this message can’t go, because there’s something wrong with it. The solution is to have a dedicated queue that holds these messages: it’s called a Dead Letter Queue - it’s kind of like a holding bay for the car.
Why would a message be “poison”
There are a few reasons that a message can be considered “poison” and dead lettered; some of the most common are:
- Each queue has a maximum delivery count, if it's exceeded - that is, we've tried too many times to process it
- The message can be explicitly marked as bad by the client
- The size of the message is bigger than the allocated maximum size
- The message has been "auto-forwarded" too many timesEssentially, the system tries to work out whether this message is staying around too long and causing issues with the system. It’s important to know, though, that the dead letter queue is just another queue. The message isn’t lost - just side-lined.
Dead Lettering
Let’s see how we can force a message into a dead letter queue. The easiest way to do this is to explicitly just Dead Letter the message; for example:
var messageReceiver = new MessageReceiver(connectionString, QUEUE\_NAME);
var message = await messageReceiver.ReceiveAsync();
await messageReceiver.DeadLetterAsync(message.SystemProperties.LockToken, "Really bad message");
Here, we’ve read the message, and then told Service Bus to just Dead Letter it. In real life, you may choose to do this on rare occasions, but I imagine its main use is for testing.
Abandon the Message
Another way to cause a message to be dead lettered is to exceed the Max Delivery Count. You can do this by “abandoning” the message multiple times; for example:
var messageReceiver = new MessageReceiver(connectionString, QUEUE\_NAME);
var message = await messageReceiver.ReceiveAsync();
string messageBody = Encoding.UTF8.GetString(message.Body);
Console.WriteLine($"Message {message.MessageId} ({messageBody}) had a delivery count of {message.SystemProperties.DeliveryCount}");
await messageReceiver.AbandonAsync(message.SystemProperties.LockToken);
Here, we’re reading the message, and rather than completing it, we’re abandoning it. It’s worth bearing in mind that this is what happens when you abandon a message. It’s also what happens when you read a message and just implicitly abandon it (i.e., you read it on a PeekLock and then do nothing): the AbandonAsync method doesn’t actually change the functionality of the code above - it does change the speed, though.
Reading The Dead Letter Queue
Now that we’ve dead-lettered a message, we can read the Dead Letter Queue.
var deadletterPath = EntityNameHelper.FormatDeadLetterPath(QUEUE\_NAME);
var deadLetterReceiver = new MessageReceiver(connectionString, deadletterPath, ReceiveMode.PeekLock);
var message = await deadLetterReceiver.ReceiveAsync();
string messageBody = Encoding.UTF8.GetString(message.Body);
Console.WriteLine("Message received: {0}", messageBody);
if (message.UserProperties.ContainsKey("DeadLetterReason"))
{
Console.WriteLine("Reason: {0} ", message.UserProperties["DeadLetterReason"]);
}
if (message.UserProperties.ContainsKey("DeadLetterErrorDescription"))
{
Console.WriteLine("Description: {0} ", message.UserProperties["DeadLetterErrorDescription"]);
}
The code above sets up a MessageReceiver for the dead letter queue. The delivery count inside the dead letter queue does not increase, but it does retain the number that it had from the original queue. Effectively, all you can do with a Dead Letter message is to complete it.
DeadLetterReason
When a message is dead lettered, the properties DeadLetterReason and DeadLetterErrorDescription may get added to the message. If you forcibly dead letter the message then you have the option to add this: if you choose not to then it will not be present (hence the checks around the properties), but mostly, these will be available.
Re-submitting a Message and Transactions
We’ve now seen how to cause a message to Dead Letter, and read the Dead Letter queue; next we’re going to investigate re-submitting the message.
As a quick side not - you can’t really re-submit a message - as you’ll see, what we actually do is to complete the dead letter message, and send a copy back to the queue.
var serviceBusConnection = new ServiceBusConnection(connectionString);
var deadletterPath = EntityNameHelper.FormatDeadLetterPath(QUEUE\_NAME);
var deadLetterReceiver = new MessageReceiver(serviceBusConnection, deadletterPath, ReceiveMode.PeekLock);
var queueClient = new QueueClient(serviceBusConnection, QUEUE\_NAME, ReceiveMode.PeekLock, RetryPolicy.Default);
var deadLetterMessage = await deadLetterReceiver.ReceiveAsync();
using var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled);
var resubmitMessage = deadLetterMessage.Clone();
resubmitMessage.UserProperties.Remove("DeadLetterReason");
resubmitMessage.UserProperties.Remove("DeadLetterErrorDescription");
await queueClient.SendAsync(resubmitMessage);
await deadLetterReceiver.CompleteAsync(deadLetterMessage.SystemProperties.LockToken);
scope.Complete();
There’s a few points to note in the above code:
FormatDeadLetterPath
FormatDeadLetterPath gives you the entity path for the dead letter queue, based on an entity.
Transaction Scope
The scope ensures that everything between its creation and completion happens as a single transaction. That is, if part of that fails, the whole thing fails. For example, you could add a throw new exception between the send and the complete, and the new message will not send.
We’re using the new C# 8 using statement - that is, it will apply to everything between it, and the end of the method.
ServiceBusConnection
There are several overloads for most of these methods, and typically, you can pass a connection string into the constructor - for example, MessageReceiver could be called like this:
new MessageReceiver(connectionString, QUEUE\_NAME);
Typically, you can use this and it works exactly the same as if you established your own connection and passed that through; however, with a transaction, everything needs to share a connection. If they do not, then you may see an error such as this:
Transaction hasn’t been declared yet, or has already been discharged
Hence we’re creating the connection upfront.
References
https://blogs.infosupport.com/implementing-a-retry-pattern-for-azure-service-bus-with-topic-filters/
https://stackoverflow.com/questions/38784331/how-to-peek-the-deadletter-messages