bionmarketplace.blogg.se

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).