Infrastructure | Currently we do not retry failed commands on receive side #199

Closed
manikrish opened this Issue Apr 23, 2012 · 4 comments

Projects

None yet

2 participants

@manikrish
Contributor

#75 states that we do retry. However in the current code base we currently deadletter the messages immediately without doing retries ( checking delivery count etc). Looks like some of the code went missing ( possibly when merge happened?)
Current:
try
{
ProcessMessage(payload);
// TODO: exception between these two?
message.Async(message.BeginComplete, message.EndComplete);
}
catch (Exception)
{
// TODO: retries, retry count, Abandon vs DeadLetter?
// Just: if (args.Message.DeliveryCount > 5) ?
args.Message.Async(args.Message.BeginDeadLetter, args.Message.EndDeadLetter);
}

Expected:
if (args.Message.DeliveryCount > 5)
// dead letter.
}

@kzu kzu was assigned Apr 23, 2012
@manikrish
Contributor

The correct way to do this is to

  1. to abandon the message before the max delivery count is exceeded. ( separate bug on this).
  2. it should be possible to set the MaxDeliveryCount on SubscriptionDescription http://msdn.microsoft.com/en-us/library/windowsazure/hh780763.aspx instead of explicily dead lettering the messages.
@kzu
Contributor
kzu commented Apr 25, 2012

If you never dead-letter the message, then where's an OPs guy going to look
for errors? Dead-lettering the ones you can't process at all is the common
thing to do.

  1. Abandon brings it back to the queue immediately. The point of letting it
    timeout was to give some time between retries of the same failed message.

/kzu

Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
425.329.3471

On Tue, Apr 24, 2012 at 19:00, manikrish <
reply@reply.github.com

wrote:

The correct way to do this is to

  1. to abandon the message before the max delivery count is exceeded. (
    separate bug on this).
  2. it should be possible to set the MaxDeliveryCount on
    SubscriptionDescription
    http://msdn.microsoft.com/en-us/library/windowsazure/hh780763.aspxinstead of explicily dead lettering the messages.

Reply to this email directly or view it on GitHub:
#199 (comment)

@manikrish
Contributor

If we set maxdeliverycount to 5 when we create the subscription, as per the service bus documentation, aftter 5 times the message will be deadlettered by the infrastructure.
Assuming things work the way its documented- the choice of whether to explicity check deliverycount and dead letter the message would depend on whether we want to do some thing extra (like set error description etc on the message before we explicity deadletter the message).
Regarding abandoning the message- just updated the other bug on this.

@kzu
Contributor
kzu commented Apr 25, 2012

If we set maxdeliverycount to 5 when we create the subscription, as per
the service bus documentation, aftter 5 times the message will be
deadlettered by the infrastructure.

But then we can't set the reason and description (which I fixed) :(

Either way sounds good to me, although I think having the error stacktrace
as part of the description will be quite useful in fixing bugs...

/kzu

Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
425.329.3471

On Wed, Apr 25, 2012 at 12:55, manikrish <
reply@reply.github.com

wrote:

If we set maxdeliverycount to 5 when we create the subscription, as per
the service bus documentation, aftter 5 times the message will be
deadlettered by the infrastructure.
Assuming things work the way its documented- the choice of whether to
explicity check deliverycount and dead letter the message would depend on
whether we want to do some thing extra (like set error description etc on
the message before we explicity deadletter the message).
Regarding abandoning the message- just updated the other bug on this.


Reply to this email directly or view it on GitHub:
#199 (comment)

@manikrish manikrish was assigned May 1, 2012
@manikrish manikrish closed this May 1, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment