Upgrade to Cassandra driver 4

[mp911de]

The Cassandra 4 driver comes with several changes (in comparison to the 3.x driver). An upgrade requires some coordination as the 4.0 driver comes with:

• An entirely new package structure (Old: com.datastax.driver, new: com.datastax.oss.driver.api) and new maven coordinates (com.datastax.cassandra:cassandra-driver-core vs. new com.datastax.oss:java-driver-core)
• Changed concepts (new driver drops the intermediate Cluster concept in favor of a single CqlSession entry point)
• Several changes to configuration properties

Special attention deserves DriverConfigLoader that is a configuration utility to load driver config from a .conf/.json/.properties file and the fact that although Guava is no longer required as a dependency, the driver still uses a shaded variant of Guava.

It looks as if both drivers could be used side by side until Spring Data for Apache Cassandra and Zipkin are able to catch up.

[mp911de]

Spring Data Cassandra issue to upgrade the driver: DATACASS-656.

[wilkinsona]

I'm not sure that it's worth us offering auto-configuration for the new driver before Spring Data for Apache Cassandra has caught up, particularly with all the other things going on at the moment. I've placed this on hold until the update in Spring Data has been scheduled.

[mp911de]

I'm in the middle of migrating Spring Data to the 4.x driver. I noticed that running both drivers, 3.x and 4.x side-by-side does not work because of netty incompatibilities. Timing-wise it would make sense to synchronize Driver and Spring Data upgrades.

[mp911de]

I summarized the changes for the Cassandra migration (from a Spring Data perspective) at spring-projects/spring-data-cassandra#167. Snapshot builds are available for the 3.0.0.BUILD-SNAPSHOT version.

[adutra]

Hi, DataStax has been working lately on a Spring Boot module for Apache Cassandra and DSE.

It uses the DataStax driver 4.x and offers out-of-the-box driver configuration and injection of session beans. Driver configuration is created by merging info from other Spring beans, Spring configuration sources and driver configuration files. Spring profiles are also honored. It also offers health indicators and metrics (driver metrics are translated into Micrometer metrics).

We would like to donate this code to you. Could you please tell us what is the best way to proceed? Feel free to ping me privately if necessary: alexandre [dot] dutra [at] datastax [dot] com.

[philwebb]

@adutra Is the module currently open source? Can we take a quick look at the code to see what's involved?

[adutra]

@philwebb it's not, it's still in beta preview. I will grant you access to the repo. Anyone else that you would like to be able to browse that repo as well?

[philwebb]

Thanks @adutra. Could you please give access to @wilkinsona and @snicoll as well.

[adutra]

Absolutely! Please feel free to leave comments and/or open issues.

[mp911de]

Spring Data for Apache Cassandra is now available in the Neumann release train. The Spring Data BOM points to version 3.0.0.BUILD-SNAPSHOT.

[snicoll]

The upgrade is taken care of as part of #19588. There are a number of things we can do to ease the upgrade from a user's perspective.

• The port is gone in favour of host:port contact points (vs. host before). If the contact points are still defined without the port, we could build the new format using the port. The property should be deprecated but I am not sure yet if we want to keep that in 2.3 proper
• cluster-name should be renamed to session-name
• The jmx flag is now useless as that support has moved outside of the driver (we introduced this flag to only enable JMX when appropriate). We should deprecate the property with ERROR level
• fetch-size renamed to page-size. There is also a case for a request sub-namespace
• I am not sure what connectTimeout is now. We found CONNECTION_INIT_QUERY_TIMEOUT but I don't think this is equivalent
• readTimeout was mapped to request-timeout. Again, not sure this is accurate
• I didn't find a replacement for poolTimeout
• The maxQueueSize could be mapped to REQUEST_THROTTLER_MAX_QUEUE_SIZE. There is a case there to improve the support in future milestones with additional properties for a request.throttler sub-namespace

@adutra the project you've shared with us was helpful to better understand some of the changes in v4, thank you! Can you please look at the above? Our plan for M1 is to map the existing keys that we current have with v3, deprecating those who are not reflected in the new driver anymore. Future milestone will improve the configuration by offering additional mappings (I've added some suggestions but I am sure we'll have more).

@mp911de thank you so much for the assistance. Upgrading Spring Data was relatively straightforward. I haven't managed to fix the integration tests yet as I don't understand how I should/can create the keyspace. I'll resume work on this next week to make sure the integration tests are green too.

[mp911de]

This snipped translates to what was previously done with Cluster.builder():

private void createTestKeyspaceIfNotExists() {
	try (CqlSession session = CqlSession.builder()
			.addContactPoint(new InetSocketAddress(cassandra.getContainerIpAddress(), cassandra.getFirstMappedPort()))
			.withLocalDatacenter("datacenter1")
			.build()) {

		session.execute("CREATE KEYSPACE IF NOT EXISTS boot_test"
				+ "  WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };");
	}
}

I'm not sure why withLocalDatacenter is required and cannot be inferred, especially in single-node arrangements. I also noticed that contact point configuration via DefaultDriverOption.CONTACT_POINTS tried to use localhost:9042 (in CassandraAutoConfiguration).

[snicoll]

This is now superseded by #19588 and a number of issues that I've just created (see above). We'll continue improving Cassandra v4 support in future 2.3 milestones and welcome feedback.

[wilkinsona]

I think we should keep this in 2.3.0.M1 so that it appears in the release notes.

[adutra]

@snicoll I replied to most of your bullet points above under the respective issues that you created.

If the contact points are still defined without the port, we could build the new format using the port

Beware that the driver uses a colon to separate the address from the port, as in adress:port; if the port is made optional, this could lead to ambiguities when using IPv6 addresses in compact format, that is, a contact point ending with :1234 might be interpreted as address+port or just an address without port.

[snicoll]

@adutra thanks, I thought of that one and was considering doing the replacement only for basic cases (i.e. no presence of : at all). I know this wouldn't cover all advanced use cases but this could be good enough for a start.