Reputation: 389
I'm trying to use the ServiceBus subscriptions's MaxDeliveryCount for implementing retry of message processing. Not sure it's the best idea, but don't want to lose messages.
Scenario:
The first messages ("1") fails to process on B and is marked as abandoned (BrokeredMessage.Abandon())
Reason: for internal reasons, app can't process this message now.
It's not yet BlackLettered since DeliveryCount < MaxDeliveryCount)
Then message "3" is received
Message "3" is also marked as Abandoned since message "1" is
expected
and so on.
It seems, in this scenario, the SB is delivering the messages in a Round Robing manner.
Is this the intended behavior of ServiceBus?
I am aware about the existence of some debates whether SB guarantees ordered delivery or not. For the applications it's really important that messages are processed in the same order they are sent.
Any ideas how reprocessing of message "1" could be performed until DeliveryCount reaches MaxDeliveryCount before processing the message "2"?
Upvotes: 0
Views: 723
Reputation: 27793
Firstly, as Thomas shared in his comment, you could try to specify SupportOrdering property to true for the Topic.
TopicDescription td = new TopicDescription("TopicTest");
td.SupportOrdering = true;
And if subscription client received a message and call Abandon
method to abandon the lock on a peek-locked message, we could call Receive
method again to get it again, like this.
output:
On the other hand, if possible, you could try to combine a complete work steps with a specific order in a single message instead of splitting steps in multiple messages, and then you could control the processing in specific order in your code logic rather than reply on the service bus infrastructure to provide this guarantee.
Upvotes: 0