Understanding Reconnect frequency for default delay (Exponential delay)

[akk202]

Firstly, thank you for having very detailed documentation and Wiki on Lettuce. They have been very helpful.

I have a question (more of a clarification) related to the reconnect strategy. As I understand, by default Reconnect delay Delay.exponential() uses Exponential power of 2 attempts delay in ms capped at 30s based on documentation. Based on that does the following hold true:
1 ms, 2 ms, 4 ms, 16 ms, ...... 16K ms (16s), 30s, 30s etc..

I have a couple of questions based on that:

1. Is there a limit to the number of attempts? (I couldn't find it mentioned in docs or could identify from source code either)
2. During a redis node failure, lets say if recovery is up to 30s. Is it practical to do so many retries? (I haven't observed any negative impact in my test stacks but wanted additional clarification from a SME)

[mp911de]

Is there a limit to the number of attempts?

The only moment Lettuce stops reconnecting is when you either close the connection or quit the JVM.

During a redis node failure, lets say if recovery is up to 30s. Is it practical to do so many retries?

It boils down to what you're willing to accept as recovery time for your service. After a prolonged time of unavailability, you typically want to recover as soon as your Redis service is available. 30 seconds seems a good middleground. You can customize the delay to use other caps or provide your own strategy to compute backoff.

The defaults serve the typical use-case, yet each application and each environment is different so that is why you should come up with your own configuration if needed.