CODEWITHSUNDEEP
c#servicebusretrypolicy
Miguel Vale
Miguel Vale

Reputation: 69

Microsoft.Azure.ServiceBus - SubscriptionClient ignoring RetryPolicy (RetryExponencial)

I'm trying to implement a retry policy but it keeps getting ignored. Is there properties in SubscriptionClient that overrides the ones I give when I create the client?

Here is the code i tried:

_retryPolicy = new Microsoft.Azure.ServiceBus.RetryExponential(
                       TimeSpan.FromMinutes(2), // MinBackOff
                       TimeSpan.FromMinutes(5), // MaxBackOff
                       3); // Max Retries

_subscriptionClient = new SubscriptionClient(
               serviceBusPersisterConnection.ServiceBusConnectionStringBuilder,
               subscriptionClientName, retryPolicy: _retryPolicy);

So this should make it only retry 3 times with minimun 2min interval. Result from LOG:

28 May 2019 16:34:49.928 MessageId: 1d327c9033de4fc69892766084264
28 May 2019 16:34:49.285 MessageId: 1d327c9033de4fc69892766084264
28 May 2019 16:34:48.718 MessageId: 1d327c9033de4fc69892766084264
28 May 2019 16:34:48.075 MessageId: 1d327c9033de4fc69892766084264
28 May 2019 16:34:47.499 MessageId: 1d327c9033de4fc69892766084264
28 May 2019 16:34:46.965 MessageId: 1d327c9033de4fc69892766084264
28 May 2019 16:34:46.511 MessageId: 1d327c9033de4fc69892766084264
28 May 2019 16:34:45.957 MessageId: 1d327c9033de4fc69892766084264

As you can see it retried 8 times instead of 3 and the time between retries (this is my main problem) has an interval of half second.

To be sure it was not my retry policies i tried this instead:

_subscriptionClient = new SubscriptionClient(
              serviceBusPersisterConnection.ServiceBusConnectionStringBuilder,
              subscriptionClientName, retryPolicy: RetryPolicy.NoRetry);

And result was exactly the same, so i'm sure it's being ignored. Any help would be much appreciated.

Keep up the good work.

Upvotes: 2

Views: 1407

Answers (1)

Mohit Verma
Mohit Verma

Reputation: 5294

RetryExponential is intended to be used by the Service bus client when there are transient errors that are not bubbled up to your code right away. I.e. an internal retry mechanism built into the client to perform retries on your behalf before exception is raised. If there are no exceptions and your callback Abandons the message explicitly, retry policy is not even utilized here and the message just goes through the normal delivery up to MaxDeliveryCount times (50 in your scenario), after which is DQed.

Use retry policy to specify to the Service bus client how to deal with transient errors prior to giving up, not how many times a message can be dequeued.

you can read more about here.

Hope it helps.

Upvotes: 1

Related Questions