Whenever a message has been delivered under a peek-lock, but has been either explicitly abandoned or the lock has expired, the delivery count on the message is incremented. There is a limit on number of attempts to deliver messages for Service Bus queues and subscriptions. See the Maximum delivery count section for details. Message couldn't be consumed after maximum delivery attempts. The maximum number of allowed hops when forwarding between queues has been exceeded. Session enabled entity doesn't allow a message whose session identifier is null. See the Time to live section for details. The message expired and was dead lettered.
The size quota for this stream has been exceeded. Applications can define their own codes for the dead-letter reason property, but the system sets the following values. The following two properties (dead-letter reason and dead-letter description) are added to dead-lettered messages. An application can also explicitly move messages to the DLQ. There are several activities in Service Bus that cause messages to get pushed to the DLQ from within the messaging engine itself. You can also get the count of DLQ messages by using Azure CLI command: az servicebus topic subscription show. In the following example, Service Bus Explorer shows that there are 62 messages currently in the DLQ for the subscription "test1". So, you can see messages in the DLQ associated with the subscription for the topic. Instead, when a sender sends a message to a topic, the message is forwarded to subscriptions for the topic within milliseconds and thus no longer resides at the topic level. That's because messages don't sit at the topic level. It's not possible to obtain count of messages in the dead-letter queue at the topic level. Messages remain in the DLQ until you explicitly retrieve them from the DLQ and complete the dead-letter message. The dead-letter queue fully supports peek-lock delivery and transactional operations. In addition, time-to-live isn't observed, and you can't dead-letter a message from a DLQ. An application might, with help of an operator, correct issues and resubmit the message, log the fact that there was an error, and take corrective action.įrom an API and protocol perspective, the DLQ is mostly similar to any other queue, except that messages can only be submitted via the dead-letter operation of the parent entity. Messages can then be removed from the DLQ and inspected. The purpose of the dead-letter queue is to hold messages that can't be delivered to any receiver, or messages that couldn't be processed. Much of the discussion is illustrated by the Dead-Letter queues sample on GitHub. This article describes dead-letter queues in Service Bus. The dead-letter queue doesn't need to be explicitly created and can't be deleted or managed independent of the main entity. Azure Service Bus queues and topic subscriptions provide a secondary subqueue, called a dead-letter queue (DLQ).
0 kommentar(er)
