Hi Everybody,
We wanted to reach out to the community around the v4 changes in the DataStax Java driver and gauge people's opinions on some of the changes. DataStax have done a tremendous job over the years on the Cassandra drivers and contributing to this community. However, we are currently struggling to adopt the latest driver due to these changes. We have been working on a project to upgrade an application from v3 to v4.9 of the driver and have encountered major changes between these versions. We have observed the latest version of the driver contains many more DataStax Enterprise (DSE) specific code, and this is not surprising as DataStax have been generous to build it for the Cassandra community. >From our understanding, the DSE specific code must be included even if you are unable to use it or require it. For example, in CqlSessionBuilder class which is the main entry point into the driver, there are APIs relating directly to DataStax Enterprise non-OSS functionality, their cloud DBaaS etc.. e.g. - withApplicationName ( https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String- ) - withApplicationVersion ( https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String- ) - withCloudProxyAddress ( https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withCloudProxyAddress-java.net.InetSocketAddress- ) - withCloudProxyAddress ( https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withCloudSecureConnectBundle-java.io.InputStream- ) plus more. All of these are sitting under the com.datastax.oss package - not the com.datastax.dse package. Additionally the reference.conf for the default driver settings contains a large number of DSE specific options: https://github.com/datastax/java-driver/blob/4.9.0/core/src/main/resources/reference.conf We would like to have seen this implemented in a subclass of the CqlSessionBuilder eg. DataStaxCqlSessionBuilder and the conf split into two separate config files. Additionally, the structure of the library is such that it is bundling all of the DSE driver code with the non-DSE driver code eg. graph, search etc. We would also like to have seen DataStax to have implemented it as separate libs and use a dependency on an OSS only lib in the datastax specific lib for the shared functionality. It would be great to be able to only take in the dependencies and code needed for Apache Cassandra and not the commercial products around it. However, the above observations are trivial compared to the two core features of the driver that seem to have been deprecated and we would like your opinion. 1 - No more failovers to remote-DC Previous versions of the driver allowed the driver to failover to a remote DC (if you wanted) in the event of losing access to the local DC. This is no longer the case. See: https://docs.datastax.com/en/developer/java-driver/4.9/manual/core/load_balancing/#default-policy What this means is either: a - re-implement this - not trivial b - initialise multiple instances of the driver in your JVM - not recommended by DataStax and we have observed some issues when you do this c - Address the problem via infra e.g load balancer fronting a local service connecting to local Cassandra DC along side a passive local service connecting to the remote Cassandra DC d - stop the entire applications/Cassandra stack in the DC if Cassandra becomes unavailable to the applications in this DC for any reason. Not a trivial change to take on, and in our humble opinion undermines one of the greatest benefits of Apache Cassandra where your applications "just keep working". We have seen many situations where this has been one of the core architecture principles for adopting Cassandra and forms part of the signed off and agreed operational acceptance testing on platforms. The latest driver will not be able to retain this architecture and it will be difficult for certain organisations to adopt and be current with the latest driver. https://docs.datastax.com/en/developer/java-driver/4.9/manual/core/load_balancing/ vs https://docs.datastax.com/en/developer/java-driver/3.9/manual/load_balancing/ 2 - No more changing consistency on retries Although this has been a controversial feature, we know quite a few users of this feature. Removing this in v4.9 of the driver essentially breaks those applications and it is not possible to implement this through a custom retry policy as the driver RetryDecision is now a String enum ( https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/retry/RetryDecision.html) vs v3.9 ( https://docs.datastax.com/en/drivers/java/3.9/com/datastax/driver/core/policies/RetryPolicy.RetryDecision.html) where more complex choices could be bubbled up to the driver around the consistency to retry on. We looked into how we could simulate the old retry behaviour using the latest driver and it would require non-trivial code updates within the client application - particularly if the asynchronous features are leveraged. Also, the default settings for the driver has remote connections set to 1 - https://docs.datastax.com/en/developer/java-driver/4.9/manual/core/pooling/#configuration We are not quite certain the reason or think of a scenario when this is utilised as local connections are only possible? https://docs.datastax.com/en/developer/java-driver/4.9/faq/#where-is-downgrading-consistency-retry-policy We look after many DataStax / Cassandra clusters and these changes in the latest driver changes have left us scratching our heads. We would be interested in hearing your thoughts on these observations. Thanks, Johnny -- Johnny Miller Co-Founder & CTO https://digitalis.io <http://digitalis.io/> | Work: +44 20805023721| Mobile: +352 621159920 -- -- The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.digitalis.io <http://www.digitalis.io>
