Resubmit dead-letter message back to the subscription it came from
I often want to re-submit a subscription's dead-letter message back to the subscription without going through the topic. This is required when the other subscriptions shouldn't reprocess the message, but there is currently no way to do this. The cleanest way I can think of is to add send functionality to the SubscriptionClient. class.
Other people have asked for this functionality as well: http://stackoverflow.com/questions/22096262/send-message-directly-to-subscription
We have gotten around this limitation by setting up an auto forward rule to forward messages that arrive on a subscription to an accompanying delivery queue which is set up separately. You are then able to reprocess these isolated DLQ messages without having to go through the topic.
We are very unhappy with Azure Service Bus due to this feature. Not only is it expected in a message brokering platform, but the lack of ability to even interact or view these messages is crippling in the Node.js environment.
Likely we will move back to Amazon, considering this has been on Microsoft's radar for more than 4 years now with no work done to address the issue.
Avi Mualem commented
I truly believe this feature is essential to any message brokering platform.
In modern distributed systems which based upon eventual consistency paradigm various business scenarios use topics with multiple subscriptions often need to assure that each subscription logic will be invoked eventually.
i'm aware to the fact that the dead letter subscriber can send a message to the original topic with a custom filter that will make sure only dedicated subscriber will get invoked but this workaround doesn't feel like an actual solution for the issue.
It depends on how you process the messages and how this works from a business requirements standpoint - but the obvious workaround is to write any messages you're failing to processed to disk or inserting into a database, and then later pushing these messages back into the appropriate ServiceBus queue (or just processing this "backlog" manually).
Prashant Brall commented
Yes this functionality is a must have as we are using Windows Service Bus (On-Premise). We tried filtering messages with custom properties but it doesn't work and it's frustrating that when we submit the dead-letter message back to the topic even the other subscriber get the message and reprocess it again. Imagine if there was a payment and it processing the payments over and over again because some other subscriber dead-lettered the message.
This is supported in every other message brokering platform I've dealt with, where a subscription is usually just another queue, and some configuration or convention is responsible for delivering messages to it from one or more topics. Since in those platforms they are just another queue, there is no issue with putting a message directly to them, whether it came directly from a deadletter or not.