Could you clarify - do we have one dead-letter queue for a topic or a lot dead-letter for each subscription within the topic?
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@bastyuchenko Thanks for your inquiry. I believe the DLQ is per Service Bus Name Space. You can use the Azure Portal or the Service Bus Explorer to list and view the Topics and Queues but, you should see a single DLQ per Service Bus Name Space instance.
Service Bus Explorer Downloads
The dead-letter queue
The purpose of the dead-letter queue is to hold messages that cannot be delivered to any receiver, or messages that could not be processed. Messages can then be removed from the DLQ and inspected. 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.
From 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. In addition, time-to-live is not observed, and you can't dead-letter a message from a DLQ. The dead-letter queue fully supports peek-lock delivery and transactional operations.
Note that there is no automatic cleanup of the DLQ. Messages remain in the DLQ until you explicitly retrieve them from the DLQ and call Complete() on the dead-letter message.
@bastyuchenko Does this answer your question? We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.
Kind regards,
Mike
@Mike-Ubezzi-MSFT Are you 100% sure on this? It sure looks like to me that there is one DLQ per subscription. I've created a Topic with two subscriptions, Subscription1 and Subscription2. Using the Service Bus Explorer I can see 7 items in the DLQ for Subscription1, and zero items for Subscription2.
@Blackbaud-MikeDuVall @Mike-Ubezzi-MSFT, were you able to verify whether the DLQ was per Subscription or Topic?
Thanks,
Moe
@Blackbaud-MikeDuVall @Moeahmad94 This is per queue and not per namespace. I just went through a quick deployment and when you click on Add Queue, you have the ability to add a DLQ to go with the new queue being added (see screen capture):
So if there's a topic with two subscriptions, is it possible for both
subscriptions to get/check messages from the DLQ, or is it first come first
serve?
Thanks,
Moe
On Tue, Dec 18, 2018, 2:53 PM Mike Ubezzi <[email protected] wrote:
@Blackbaud-MikeDuVall https://github.com/Blackbaud-MikeDuVall
@Moeahmad94 https://github.com/Moeahmad94 This is per queue and not per
namespace. I just went through a quick deployment and when you click on Add
Queue, you have the ability to add a DLQ to go with the new queue being
added (see screen capture):[image: screenshot 99]
https://user-images.githubusercontent.com/37126106/50187882-686ff200-02d4-11e9-88f6-fc23d12eb3c9.png—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/10363#issuecomment-448402216,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHOdC2CAcnX01X9Hb2O5lPdobScsZm82ks5u6XHwgaJpZM4Ur_WP
.
@Moeahmad94 If you have two clients (same as subscription if I understand your terminology) listening to the same queue, without a filtering method implemented, it is first come first served.
I feel like Queues vs Topics are getting confused in this discussion.
The original question on this thread is asking if there is only one DLQ per Topic(i.e. all Subscriptions to the topic share the same DLQ) or whether each subscription to a Topic has it's own DLQ. I've done a lot of work with DLQs for Topics and I'm fairly certain that each Subscription to a Topic has it's own distinct DLQ.
If you think about it, it makes zero sense for all Subscriptions to a single Topic to share the same DLQ. Each subscription could represent a separate service/team using that Topic, so if one subscription has an issue processing a message, it makes total sense that that message would go to the DLQ for just that Subscriptions. Why would the other team/services care?
Just FYI, I have this outstanding question on a forum for general advice on dealing with DLQ's for topics/subscriptions: https://social.msdn.microsoft.com/Forums/azure/en-US/2a003178-fe60-4ec6-90da-848f5823acf7/need-advice-on-dealing-with-deadletterqueues-for-topic-subscriptions?forum=servbus
Note the updated docs here: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues
"Azure Service Bus queues and topic subscriptions provide a secondary sub-queue, called a dead-letter queue (DLQ)"
@Blackbaud-MikeDuVall The DLQ is configured when you create a queue. The DLQ is not configured when creating a topic:
@Mike-Ubezzi-MSFT, I came across this thread today because the Azure product docs still seems to contradict your last comment, "DLQ is configured per queue, not topic". Are you saying there is no concept of a DLQ for topics? Github code samples provides a DLQ path for topics such as "Topic1/Subscriptions/Subscription1/$DeadLetterQueue".
More evidence of a DLQ per topic/subscription can be found here: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues
Could you help us understand this better? Thanks!
Beyond a shadow of a doubt, DLQ's exist for topic subscriptions. My company is currently heavily using them. The path you mentioned, "Topic1/Subscriptions/Subscription1/$DeadLetterQueue", is what we use to get to them.
@jordanchang Thanks for pointing this out. I was not pointing out that the DLQ does not exist for Topics. The DLQ exists for both Topics and Queues. I was pointing out the configuration aspect in the UI and the UI has changed a bit. Additionally, the path to the dead-letter queue is detailed specifically as:
<queue path>/$deadletterqueue
<topic path>/Subscription/<subscription path>/$deadletterqueue
If you are using the .NET SDK, you can get the path to the dead-letter queue by using the SubscriptionClient.FormatDeadLetterPath() method. This method takes the topic name/subscription name and suffixes with /$DeadLetterQueue.
The original question was with regard to a single DLQ for a topic or many DLQs, one per subscriber. There is a single DLQ that can support multiple subscribers. See: Moving messages to the DLQ (link).