Allow use of ReconnectionPolicy on Cluster init

We've considered that previously ().
I'm not convinced that this should be handled by the driver. I get your use case, but my feeling is that the majority of users don't try to connect to a cluster that is completely down, errors are more likely to be caused by a bad configuration, for which failing fast is a more appropriate response.

Thank you for your answer.
I respect your opinion concerning how many users would make use of such a feature and it's true that as a Cassandra cluster is supposed to be redundant it's actually not supposed to be offline on service start.
My point is that a driver is not supposed to be opinionated about its uses and it's probably why you propose policies for many things : you let the user decide what is the best in its case.
I'm not talking about changing the default behavior, the default ConnectionPolicy could very well be a fail fast policy to keep current behavior. But nonetheless, I think that a policy would not hurt and would be consistent with ReconnectionPolicy.
What do you think ?

I tried to argue for this feature last year.
Now that we deploy our software with k8s, it's even more evident that you either have to implement a complex boot sequence or have drivers handling connection retry. I can't see any good reason not to implement policies for that, so I ask my question again: would you consider the inclusion of that feature if I work on a PR?

Hi,

This is supported out of the box in our upcoming 4.0.0 version (). See the reconnect-on-init option in the configuration. 4.0.0-RC1 is available for testing, and we plan to go GA within a few weeks.

For full disclosure, driver 4 breaks binary compatibility, so for existing applications there will be a bit more work than just upgrading the version. For new applications I would definitely recommend starting with the new version.

would you consider the inclusion of that feature if I work on a PR?

We stay committed to maintaining the 3.x line, but for new features our focus will shift to driver 4. So I'm not sure if a 3.x PR is really worth it at this point. You always have the option of managing this outside of the driver, which is not pretty but can be a good temporary workaround until you can upgrade.

Thank you Olivier for your nice answer. We'll port our software to the 4.0 driver.