Add support for reconnect exponential backoff #990
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Like discussed in #989 here the MR for the support for the exponential backoff reconnect delay.
As discussed this adds the additional parameter
reconnect_backoff_max
toWebSocketApp.run_forever
I was not 100% sure where to place the calculation of the reconnect timer, since it it should be called from the normal
run_server
loop and also from the custom dispatcher. I saw 2 possible implementations: A method for theWebSocketApp
class or a function inside therun_forever
method.I chose to implement a simple method for the
WebSocketApp
class. There I could store the retry counter. Passing the retry parameters was ok for me. But overall this functions definitions inside therun_forever
method felt a little strange.Some random notes:
reconnect_backoff_max
is smaller than the original reconnect timer, the value ofreconnect_backoff_max
will be used as reconnect time, but there will be also a warning message.Looking forward to your feedback!
Sören