That's an immense amount of incredibly useful feedback Johnny. Thanks for taking the time and energy to write all this up.
I work with some of the engineers who authored these changes in the driver and have brought this thread to their attention. The authors have offered the driver as a CEP donation to the C* project so we will have one in tree which should give a clear path to fixing some of these API issues as well as the loss of functionality on a major. On Thu, Oct 29, 2020 at 8:37 AM, Johnny Miller <joh...@digitalis.io> wrote: > 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 >
