-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retry backoff rate is a tad ridiculous, or I'm misreading something.... #40
Comments
I agree. I have implemented this sort of logic in this pull request : #43 This pull request has been pending for a long time, I hope it will finally be merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From what I've seen in the code and behaviour after user (correct me if I'm wrong), currently the exponential reconnect backoff rate is a bit overboard.
The current formula is for reconnect wait is
configured_wait * 10^retry_attemps
With defaults:
configured_wait: 5000
max_retry_attemps: 10
You get an a reconnect pattern as such:
As you can see the numbers get pretty high even if only after the 3rd attempt. This potentially locks your process up with no hope of reconnecting in a viable timeframe. IMHO this completely defeats the purpose of the reconnect function.
My suggestion would be to set-up an exponential back-off rate which plateaus towards a maximum wait time. Graph would something like this: https://en.wikipedia.org/wiki/Sigmoid_function
The text was updated successfully, but these errors were encountered: