[EventHubs] Provide an linear(fixed) backoff option for retry

[annatisch]

Feature Wanted:

We need to add support for Fixed(Linear) retry backoff in EventHubs. EventHub needs to implement its own retry as it's based on amqp protocol so we can't simply reuse the azure-core which is http-based. However, the design of retry is almost the same.

Currently EH only supports exponential back off mode, and it takes three retry related key-word arguments when constructing the EventHubProducerClient/EventHubConsumerClient -- retry_backoff_factor, retry_backoff_max, retry_total.

As per azure-core:

azure-sdk-for-python/sdk/core/azure-core/azure/core/pipeline/policies/_retry.py

Lines 56 to 85 in 1ba7a75

	class RetryPolicy(HTTPPolicy):
	"""A retry policy.
	The retry policy in the pipeline can be configured directly, or tweaked on a per-call basis.
	:keyword int retry_total: Total number of retries to allow. Takes precedence over other counts.
	Default value is 10.
	:keyword int retry_connect: How many connection-related errors to retry on.
	These are errors raised before the request is sent to the remote server,
	which we assume has not triggered the server to process the request. Default value is 3.
	:keyword int retry_read: How many times to retry on read errors.
	These errors are raised after the request was sent to the server, so the
	request may have side-effects. Default value is 3.
	:keyword int retry_status: How many times to retry on bad status codes. Default value is 3.
	:keyword float retry_backoff_factor: A backoff factor to apply between attempts after the second try
	(most errors are resolved immediately by a second try without a delay).
	In fixed mode, retry policy will alwasy sleep for {backoff factor}.
	In 'exponential' mode, retry policy will sleep for: `{backoff factor} * (2 ** ({number of total retries} - 1))`
	seconds. If the backoff_factor is 0.1, then the retry will sleep
	for [0.0s, 0.2s, 0.4s, ...] between retries. The default value is 0.8.
	:keyword int retry_backoff_max: The maximum back off time. Default value is 120 seconds (2 minutes).
	:keyword RetryMode retry_mode: Fixed or exponential delay between attemps, default is exponential.
	:keyword int timeout: Timeout setting for the operation in seconds, default is 604800s (7 days).

Action items:

1. Need to define the enum type RetryMode under azure.eventhub namespace -- azure.eventhub.RetryMode
   https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/core/azure-core/azure/core/pipeline/policies/_retry.py#L52-L54

class RetryMode(str, Enum):
    Exponential = 'exponential'
    Fixed = 'fixed'

2. EventHubProducerClient/EventHubConsumerClient (and async) constructors and the helper method from_connection_string should take "retry_mode" as a key-word argument and the default value shall be Exponential (non-breaking change), see configuration and how the configuration could be used internally.

3. Update the def _backoff and the async version to backoff according to the given retry mode.

4. Test and docstring

[Hanse00]

Can we get some more detail on this? I understand the concept of a backoff option, but if you intend for this to be a good first issue, the contributor will need a bit of background.

[jmonty42]

I see that there is a fixed option and an exponential option for retries. Would a linear option simply be adding the back_off value each time?

[yunhaoling]

hey @jmonty42 , thanks for your help. Fixed retry is equal to liner retry.

sorry about not mentioning any background knowledge before, and I just added more description in the context. Hope it would be clear to you know and feel free to ping me if you need more input.

and apologize to @Hanse00 as well, I truthfully forget the issue here, I wish you were still interested in getting it resolved😊

[Hanse00]

@yunhaoling Not a problem, I'm happy to have been able to highlight an issue that needed some help. The first step to allowing people to help us in open source, is making sure we give them the tools and information they need to help 😄

I might be interested in taking a stab at this myself if nobody else does, I'll need to get around to it when I'm a little less busy at work.

[jmonty42]

@yunhaoling, alright, thanks for the clarification, I will close my PR since it doesn't address the issue now. I'll take a closer look at the updated requirements to see if I could take a crack at that.