Closed ViToni closed 2 weeks ago
@MattBrittan This PR is an alternative to #252. This PR uses a simpler approach with a "stateless" backoff which doesn't need a reset.
Thanks very much for this - sorry it's taken so long!
The point I'm trying to make is that one would need to create a custom backoff implementation before encountering one of the issue mentioned above which is not what usual happens.
My aim here is to implement the "delay between connection attempts will be a minimum of ConnectRetryDelay" type rule into the main library (as I believe it's what users would expect). Did not want to ask you to make more modifications than neccessary to get this in as I'm concious it's taken a while.
This PR introduces the ability to use a dynamic backoff for reconnect attempts. Its purpose is just to replace the current constant value with a more versatile option.
As default a backoff strategy is used which returns the same backoff value mimicking the previous behaviour. In addition there is an exponential backoff available which will increase the max value on each attempt up to a configurable limit. The created backoff is a random value between a configured non-zero minimum and the increasing max (up to the configured limit). Using a random value from an increasing range helps spread client reconnect attempts.
Testing
Existing code has been changed to use the same duration as before but now uses the constant backoff implementation instead. All tests pass.
Additionally there are dedicated tests for:
Closing issues
Closes issue #249