Just my 2 cents Because of the tremendous breaking changes in terms of API as well as public facing classes (QueryBuilder for ex) I have stopped the development of the Achilles framework.
Migrating to the 4.x version would require almost the complete rewrite of the framework, an effort which I cannot afford to dedicate to (the framework is 7 years old now). I also advise many customers of mine to adopt a wait & see strategy with regards to the new drivers because of the amount of application rewrite, due to the aforementioned public-facing classes changes Regards Duy Hai DOAN On Thu, Oct 29, 2020 at 2:06 PM Johnny Miller <joh...@digitalis.io> wrote: > Joshua - thanks for the update, I have found the ASF slack channel > (#cassandra-cep-drivers-donation) and google doc ( > https://docs.google.com/document/d/1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY/edit#). > Will be watching it closely. > > In terms of the functional changes brought into the driver with 4.x the > downgrading CL has always been a controversial feature, but the failover to > remote DC being removed - I am curious to understand why? > > Thanks, > > Johnny > > On Thu, 29 Oct 2020 at 13:53, Joshua McKenzie <jmcken...@apache.org> > wrote: > >> 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 >>> >> >> > > > -- > > 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 >
