1

When using a brokered service bus (in Azure) with a topic with multiple subscriptions, some subscriptions throw exceptions when processing messages. Those messages then get placed into the dead letter queue for that subscription.

How can I see what the problem was, and why the message was dead lettered ?

I'm thinking I can amend the dead letter, but is it common practise to amend the message with the thrown exception ? If so, how is this done using a BrokeredMessage object ? Messages can be abandoned using BrokeredMessage.Abandon(IDictionary[String, Object]) but is using this to record exceptions a known practise or is there a better way ?

MrDeveloper
  • 1,041
  • 12
  • 35
  • Have you tried using Service Bus Explorer: https://code.msdn.microsoft.com/windowsapps/Service-Bus-Explorer-f2abca5a (btw not me downvoting your question) – Milen Dec 15 '15 at 16:55
  • Yes, it's a great tool. The `DeadLetterReason` is always `MaxDeliveryCountExceeded` (3 times) as messages are abandoned rather than dead lettered by the subscription. This is to eliminate any transient errors the subscriber might have had. – MrDeveloper Dec 15 '15 at 16:58
  • Not sure if it's common or best practise but it's a method that works for us when used in conjunction with ServiceBus Explorer. The exception is added to the message properties using the Abandon function. Messages that end up in the dead letter queue can be viewed using Service Bus Explorer and the exception reason is visible. Once the underlying reason for the exception is fixed you can use SBE to move the message back to the original queue to be retried. – Alex S Dec 16 '15 at 14:35
  • @AlexS Yes, that's exactly the thought I was having - it's good to see that other people have had the same idea, so I wouldn't say it was an 'uncommon' approach. – MrDeveloper Dec 17 '15 at 12:22

1 Answers1

1

I don't think there is a way for ASB to automatically persist the error somewhere along with the dead lettered message. You can do one of the 2 things though:

  • When you call SubscriptionClient.OnMessage, use the overload with OnMessageOptions onMessageOptions parameter, and provide your error handler in onMessageOptionsExceptionReceived. ASB will call that every time an unhandled exception happens on message arrival. Then you can record the exception in your logs, along with message ID, etc, for later troubleshooting.
  • Or rather than having ASB see your unhandled exceptions, use try / catch inside your message call back (first argument in SubscriptionClient.OnMessage), and do the same error logging there.
Slava Asipenko
  • 392
  • 1
  • 3
  • You're speaking of exception handling in the application that consumes the message, which is a fair point, but I'm more concerned with actually manipulating the dead letter to disclose the application's exception within the message itself and whether it's the right thing to do. – MrDeveloper Dec 16 '15 at 09:10
  • I see. We are doing something similar. When the message handling fails after N retries, we collect extra info (stack, code owner info, destination topic path, execution context, etc) and attach it to the message using Label + message properties. Instead of letting it go to dead letter, we are letting the original message Complete on the original topic, and then put the amended copy onto a shared Error queue. We have quite a few topics/subscriptions and queues, so it's far easier to be looking at one place for all failed messages rather than monitor and inspect dozens of dead letter queues. – Slava Asipenko Dec 16 '15 at 13:37
  • That's an interesting way of handling dead letters. I would be very interested in seeing how many topics and subscriptions you have and how they are arranged. I have an unanswered question here from 6 months ago that pretty much asks just that : http://programmers.stackexchange.com/questions/287532/how-many-topics-queues-to-practically-use-in-an-esb – MrDeveloper Dec 17 '15 at 12:20