Retry backoff rate is a tad ridiculous, or I'm misreading something....

[AlmirKadric]

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:

1. 5,000 (5 Seconds)
2. 50,000 (50 seconds)
3. 500,000 (~8 minutes)
4. 5,000,000 (~1 hour)
5. 50,000,000 (~13 hours)
6. 500,000,000 (~5 days)
7. 5,000,000,000 (~57 days)
8. 50,000,000,000 (~1.5 years)
9. 500,000,000,000 (~15.8 years)
10. 5,000,000,000,000 (~158 years)

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

[jaunis]

I agree. I have implemented this sort of logic in this pull request : #43
As you will notice it is not strictly speaking a Sigmoid function, but it has a similar behaviour for positive integers. The waiting time will be limited to five times the configured interval.

This pull request has been pending for a long time, I hope it will finally be merged.