On several applications I contributed to that uses Cassandra, we have to implement a retry mechanism to allow the application to start without waiting for Cassandra to allow connections.
It's a very common need IMHO and it's really unfortunate that we have ReconnectionPolicy but can't use it for initial connection. What would you think about allowing the Cluster to take a ReconnectionPolicy for first connection ?
If it can help, you can find some test cases here : https://github.com/apache/james-project/blob/master/server/container/guice/cassandra-guice/src/test/java/org/apache/james/JamesServerWithRetryConnectionTest.java
Tell me if you think it's a good idea and you would accept a PR about that.
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?
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.