Allow use of ReconnectionPolicy on Cluster init

Description

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.

Environment

None

Pull Requests

None

Activity

Show:
Olivier Michallat
May 17, 2017, 4:49 PM

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.

Matthieu Baechler
May 17, 2017, 9:18 PM

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 ?

Matthieu Baechler
March 2, 2019, 3:44 PM

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?

Olivier Michallat
March 3, 2019, 1:49 AM

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.

Matthieu Baechler
March 3, 2019, 12:38 PM

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

Assignee

Unassigned

Reporter

Matthieu Baechler

Labels

None

PM Priority

None

Affects versions

Fix versions

None

Pull Request

None

Doc Impact

None

Size

None

External issue ID

None

External issue ID

None

Priority

Major
Configure