ServiceBus Retry Logic

Question

Repost of https://github.com/Azure/azure-sdk-for-python/issues/6731#issuecomment-1028393257

I am testing the retry parameters on ServiceBusClient, it is not clear if/how they work.

Am I doing something wrong, do I not understand how retry works? In below I expect the message would be deliver three times in 30 seconds. Instead is delivered 10 times with about 150 milliseconds between deliveries.

with ServiceBusClient.from_connection_string(
    CONNECTION_STRING, retry_total=2, retry_backoff_factor=10
) as client:
    with client.get_subscription_receiver(
        topic_name="test", subscription_name="andrew_test"
    ) as receiver:
        for message in receiver:
            logger.debug(
                f"message {message.sequence_number}, delivery count {message.delivery_count}"
            )
            receiver.abandon_message(message)

result of running the above for one message -

11:08:02.721 DEBUG    message 40719, delivery count 0
11:08:02.875 DEBUG    message 40719, delivery count 1
11:08:03.029 DEBUG    message 40719, delivery count 2
11:08:03.183 DEBUG    message 40719, delivery count 3
11:08:03.339 DEBUG    message 40719, delivery count 4
11:08:03.644 DEBUG    message 40719, delivery count 5
11:08:03.799 DEBUG    message 40719, delivery count 6
11:08:03.955 DEBUG    message 40719, delivery count 7
11:08:04.111 DEBUG    message 40719, delivery count 8
11:08:04.269 DEBUG    message 40719, delivery count 9

As @ChristianVorhemus discusses in his comment the deferring built into the ServiceBus client does not handle deferring for "business" failures. I filed a https://github.com/Azure/azure-sdk-for-python/issues/22918 bug with the project to add a backoff option the abandon() method. In the meantime - I hacked up a way of finding deferred messages for the subscription @ https://github.com/calcbench/python_api_client/blob/master/calcbench/listener.py#L119. — andrewkittredge, Feb 14 '22 at 16:25

score 0 · Accepted Answer · answered Feb 03 '22 at 22:13

How retry_backoff_factor is interpreted depends on the retry_mode argument. By default it is set to "exponential", set retry_mode="fixed" for a constant retry time.

The retry mechanism in general is only relevant for errors that occur within the SDK, for example connection timeouts. You can simulate this by setting retry_total=1, retry_backoff_factor=10, retry_mode="fixed", turning your Internet connection off and start your code - an exception should be raised after 10 seconds. If you now change that to retry_total=3, retry_backoff_factor=10, retry_mode="fixed" you'll see the exception in 30 seconds, within that time frame the client has tried to receive messages three times.

ServiceBus Retry Logic

1 Answers1