A cursory look at the Cassandra 5 stuff didn’t indicate any incompatibility. So yeah, I think we are likely pretty safe to use the 4.17 driver Sent from my iPhone
> On Mar 19, 2024, at 3:35 PM, Matt Burgess <[email protected]> wrote: > > Is it likely now (due to the refactor) that we will simply be able to > upgrade the driver when Cassandra 5 is GA? Also does anyone use Netflix's > Astyanax [1]? > > [1] > https://cassandra.apache.org/doc/stable/cassandra/getting_started/drivers.html#java > >> On Tue, Mar 19, 2024 at 3:10 PM Mike Thomsen <[email protected]> wrote: >> >> Realistically, I think we are only likely to see two drivers: >> >> * DataStax >> * ScyllaDB >> >> The latter makes a selling point of being a binary compatible, drop-in >> replacement for the former. >> >> That's why I don't see a need to have an abstraction layer per se. I think >> we only need "DataStaxConnectionProviderImpl" and >> "ScyllaDBConnectionProviderImpl" with the difference being which jar is >> imported by maven. >> >> On Tue, Mar 19, 2024 at 2:59 PM David Handermann < >> [email protected]> wrote: >> >>> Mike, >>> >>> Thanks for the reply and clarification. >>> >>> I agree there is no need to maintain support for the DataStax 3 driver >>> and Java API, any new components should be built on the latest version >>> of the driver. >>> >>> What we do need going forward is to avoid, if at all possible, having >>> a DataStax 4 dependency in the Controller Service API. >>> >>> One example of this is the WebClientServiceProvider interface. That >>> Controller Service API does not have any third-party dependencies. The >>> Controller Service implementation, StandardWebClientServiceProvider, >>> has a dependency on OkHttp to implement HTTP communication. That is >>> the kind of abstraction that would be ideal, and I believe that also >>> aligns with what Matt has described. >>> >>> Regards, >>> David Handermann >>> >>> On Tue, Mar 19, 2024 at 1:45 PM Mike Thomsen <[email protected]> >>> wrote: >>>> >>>> ** we can dump v3 **DRIVER** compatibility, since later 4.X Java >> drivers >>>> are backward compatible with Cassandra 3 >>>> >>>> On Tue, Mar 19, 2024 at 2:43 PM Mike Thomsen <[email protected]> >>> wrote: >>>> >>>>> David, >>>>> >>>>> Before we proceed, I think we should make sure we're all >> understanding >>> the >>>>> same problem here. Starting with this: >>>>> >>>>>> I believe the CQL protocol is backwards compatible but the Java API >>> is >>>>> not. >>>>>> For example "com.datastax.driver.core.Session" is now >>>>>> "com.datastax.oss.driver.api.core.session.Session" and there is no >>> more >>>>>> "Cluster" class. Might be fairly trivial to fix though, if that's >> the >>>>> path >>>>>> of least resistance. >>>>> >>>>> From what I've learned using Cassandra 3 and 4 in my day job and >>> reading >>>>> up on this stuff for the sake of discussion, that all tracks. We used >>> the >>>>> ~4.11 driver in Spring Boot on both v3 and v4 clusters without issue >>> during >>>>> an upgrade. So I don't see any reason to factor in the "changes from >>>>> DataStax 3 to 4" since the changes were likely a one-off decision >>> meant to >>>>> position the driver for better future support and stability. >>>>> >>>>> TL;DR, we can dump v3 compatibility and the only thing our users will >>>>> notice is if we make the controller service totally incompatible with >>> the >>>>> one they're already using which is something we can actively avoid. >>>>> >>>>> On Tue, Mar 19, 2024 at 2:00 PM David Handermann < >>>>> [email protected]> wrote: >>>>> >>>>>> All, >>>>>> >>>>>> I support a Controller Service API abstraction around the Cassandra >>>>>> Driver. The changes from DataStax 3 to 4 already highlight the need >>>>>> for that abstraction. The donation of the DataStax Java driver to >>>>>> Apache [1] also shows the value of providing some level of >> isolation, >>>>>> if at all possible. >>>>>> >>>>>> I have not taken a close look at the Matt's branch, and the details >> of >>>>>> the abstraction are important, but having the abstraction can be >>>>>> useful to avoid getting back to this same situation. >>>>>> >>>>>> Regards, >>>>>> David Handermann >>>>>> >>>>>> [1] https://github.com/apache/cassandra-java-driver/ >>>>>> >>>>>> On Tue, Mar 19, 2024 at 12:37 PM Mike Thomsen < >> [email protected] >>>> >>>>>> wrote: >>>>>>> >>>>>>> Matt, >>>>>>> >>>>>>> I got that. My point was that the Java changes appear to be a one >>> time >>>>>>> thing that DataStax did to make a better driver with a much more >>>>>>> future-proof API. Since Scylla tracks them as closely as >> possible, I >>>>>>> suspect that we don't need to plan for a bunch of abstraction to >>> isolate >>>>>>> Java changes. >>>>>>> >>>>>>> On Tue, Mar 19, 2024 at 11:07 AM Steven Matison < >>>>>> [email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> That was kinda where i got stuck and fell out on my branch/jira. >>>>>> Mike and >>>>>>>> I wanted to make a new controller service , without backward >>>>>> compatibility; >>>>>>>> and remove the duplicate driver/connection properties found in >>> some >>>>>> of the >>>>>>>> processors. >>>>>>>> >>>>>>>> I agree taking out all old stuff and making new controller >> service >>>>>> makes >>>>>>>> most sense. 4.x and 5.x should be mostly backwards compatible >> to >>>>>> 2&3.x >>>>>>>> with how it’s used within current processors. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Mar 19, 2024 at 10:49 AM Matt Burgess < >>> [email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> The abstraction is to isolate Java API changes, not protocol >>>>>>>> compatibility >>>>>>>>> Changing to the java-driver comes with a number of changes to >>> the >>>>>> code >>>>>>>> (see >>>>>>>>> Steven's and my branches), if we can abstract that API it >> should >>>>>> lead to >>>>>>>>> more maintainable code in the future by not having to change >> any >>>>>>>>> processors, just the controller service implementation. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Mar 19, 2024 at 10:14 AM Mike Thomsen < >>>>>> [email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>> >> https://opensource.docs.scylladb.com/stable/using-scylla/drivers/cql-drivers/scylla-java-driver.html >>>>>>>>>> >>>>>>>>>> Directly quoting Scylla docs here: >>>>>>>>>> >>>>>>>>>>> The Scylla Java Driver is a drop-in replacement for the >>>>>> DataStax Java >>>>>>>>>> Driver. As such, no code changes are needed to use this >>> driver. >>>>>>>>>> >>>>>>>>>> On Tue, Mar 19, 2024 at 10:13 AM Mike Thomsen < >>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Matt, >>>>>>>>>>> >>>>>>>>>>> I don't think we need to really "abstract above" the >> drivers >>>>>> because >>>>>>>>> the >>>>>>>>>>> Java DataStax driver appears to support 4.X all the way >>> back to >>>>>> 2.X, >>>>>>>> as >>>>>>>>>>> well as the enterprise versions from DataStax >>>>>>>>>>> >>>>>>>>>>> >>>>>> https://docs.datastax.com/en/driver-matrix/docs/java-drivers.html >>>>>>>>>>> >>>>>>>>>>> Similar situation with Scylla. When I looked at the >> driver, >>> it >>>>>>>> appeared >>>>>>>>>> to >>>>>>>>>>> copy verbatim the entire public API of that driver. So I >>> think >>>>>> before >>>>>>>>> we >>>>>>>>>>> dive into abstractions, it's worth doing a bit more >>> validation >>>>>> of >>>>>>>> these >>>>>>>>>>> details. IMHO, this might be a much lighter lift than >>>>>> anticipated. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Mar 18, 2024 at 4:30 PM Matt Burgess < >>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Totally agree, that's what my branch does (see link in >>> previous >>>>>>>>> email). >>>>>>>>>>>> The >>>>>>>>>>>> more I work with it, the more I think I can abstract it >>>>>> further from >>>>>>>>>> their >>>>>>>>>>>> JDBC-like API but I started with a bunch of delegate >>> classes >>>>>> then I >>>>>>>>>> figure >>>>>>>>>>>> I'll see where I can consolidate to more abstract >>> concepts. If >>>>>> I >>>>>>>> don't >>>>>>>>>>>> have >>>>>>>>>>>> to support Cassandra 3 with the new API, so much the >>> better. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Matt >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 18, 2024 at 4:14 PM David Handermann < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Matt et al, >>>>>>>>>>>>> >>>>>>>>>>>>> It is good to see the background effort on moving >>> Cassandra >>>>>>>>>>>>> capabilities in a supportable direction. >>>>>>>>>>>>> >>>>>>>>>>>>> I think new Cassandra components will require a >>> significant >>>>>>>>> departure >>>>>>>>>>>>> from current Controller Service abstractions. Right >> now, >>> the >>>>>>>>> existing >>>>>>>>>>>>> service interface does not provide a clean abstraction >>> from >>>>>> the >>>>>>>>>>>>> Cassandra library, which is part of the reason for the >>>>>> current >>>>>>>>>>>>> coupling to the legacy driver version. >>>>>>>>>>>>> >>>>>>>>>>>>> Following up from Joe's comments, it seems like the >>> cleanest >>>>>> way >>>>>>>>>>>>> forward is to deprecate the current bundle on the 1.x >>>>>> branch, and >>>>>>>>>>>>> remove the current bundle from the main branch. That >> will >>>>>> provide >>>>>>>> a >>>>>>>>>>>>> clean slate for new Service and Processor >>> implementations, >>>>>> without >>>>>>>>>>>>> concern for uncertain compatibility questions. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> David Handermann >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Mar 18, 2024 at 2:35 PM Matt Burgess < >>>>>>>> [email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> What do y'all think about removing the individual >>>>>> connection >>>>>>>>>>>> properties >>>>>>>>>>>>>> from the Cassandra processors for NiFi 2.0 and >>> requiring a >>>>>>>>>>>>>> CassandraSessionProvider instead? I think we started >>> doing >>>>>> that >>>>>>>>>>>> elsewhere >>>>>>>>>>>>>> (Elasticsearch maybe?), I noticed duplicate code in >> the >>>>>>>>>>>>>> CassandraSessionProvider and >>> AbstractCassandraProcessor, >>>>>> if we >>>>>>>>> keep >>>>>>>>>>>> those >>>>>>>>>>>>>> properties I can refactor them into a utility class. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Matt >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 2:44 PM Steven Matison < >>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I got through quite a bit of work to enable 4.x… >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The 3.x pieces that were not backwards compatible >> is >>>>>> very edge >>>>>>>>> use >>>>>>>>>>>>> case and >>>>>>>>>>>>>>> could have been done slightly differently but with >>> work >>>>>>>> around. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> https://github.com/steven-matison/nifi/tree/nifi-10120-1 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 2:30 PM Matt Burgess < >>>>>>>>>> [email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Oops used the wrong email address so if there >> have >>> been >>>>>>>>>> responses >>>>>>>>>>>> to >>>>>>>>>>>>> the >>>>>>>>>>>>>>>> Cassandra thread since mine I missed them, my >> bad! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 2:00 PM Matt Burgess < >>>>>>>>>> [email protected] >>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I believe the CQL protocol is backwards >>> compatible >>>>>> but the >>>>>>>>>> Java >>>>>>>>>>>>> API is >>>>>>>>>>>>>>>>> not. For example >>> "com.datastax.driver.core.Session" >>>>>> is now >>>>>>>>>>>>>>>>> >>> "com.datastax.oss.driver.api.core.session.Session" >>>>>> and >>>>>>>> there >>>>>>>>>> is >>>>>>>>>>>> no >>>>>>>>>>>>> more >>>>>>>>>>>>>>>>> "Cluster" class. Might be fairly trivial to fix >>>>>> though, if >>>>>>>>>>>> that's >>>>>>>>>>>>> the >>>>>>>>>>>>>>>> path >>>>>>>>>>>>>>>>> of least resistance. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 1:40 PM Joe Witt < >>>>>>>>> [email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Matt >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I dont know a ton about Cassandra but when I >>> looked >>>>>> at >>>>>>>>>>>>> client/driver >>>>>>>>>>>>>>>> notes >>>>>>>>>>>>>>>>>> for 4+ it said it was compatible all the way >>> back >>>>>> to 3.x. >>>>>>>>>> Not >>>>>>>>>>>>> sure >>>>>>>>>>>>>>>> what >>>>>>>>>>>>>>>>>> that means but it surely seems worth >> exploring. >>>>>> Also I >>>>>>>>> dont >>>>>>>>>>>> know >>>>>>>>>>>>> if >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> 4.x drivers get rid of the vulnerable bits. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 10:39 AM Matt Burgess >> < >>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> At the very least we should upgrade to >>> Cassandra >>>>>>>> 3.11.6: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>> >>> https://github.com/apache/cassandra/blob/cassandra-3.11.16/CHANGES.txt >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 1:31 PM Matt >> Burgess < >>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If the community agrees to get rid of >>> Cassandra >>>>>> 3 >>>>>>>>> that'll >>>>>>>>>>>>> save me >>>>>>>>>>>>>>>>>> effort >>>>>>>>>>>>>>>>>>>> on the refactor after I add Cassandra 4 :) >>>>>> Otherwise >>>>>>>>>> those >>>>>>>>>>>>>>>>>>>> vulnerabilities would only be in a "new" >>>>>> Cassandra 3 >>>>>>>>>>>> services >>>>>>>>>>>>> NAR >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>> would not be included in the convenience >>> binary. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 1:28 PM Joe Witt < >>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Mike, Matt, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Happy to hear you both have active >> efforts >>> or >>>>>> are >>>>>>>>>>>> interested >>>>>>>>>>>>> in >>>>>>>>>>>>>>>> doing >>>>>>>>>>>>>>>>>>> so. >>>>>>>>>>>>>>>>>>>>> Can you help me understand more >>> specifically >>>>>> what >>>>>>>> that >>>>>>>>>>>> means >>>>>>>>>>>>> for >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> current set of components? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The CVE hits are concerning and long >>> standing. >>>>>>>>>> Supporting >>>>>>>>>>>>>>>> Cassandra >>>>>>>>>>>>>>>>>> 3 >>>>>>>>>>>>>>>>>>>>> implies the current set of dependencies >>> would >>>>>> remain >>>>>>>>> too >>>>>>>>>>>>> right? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Is the current set of components we have >>> ones >>>>>> we >>>>>>>> want >>>>>>>>> to >>>>>>>>>>>>> retain? >>>>>>>>>>>>>>>> We >>>>>>>>>>>>>>>>>>>>> certainly need Cassandra components - but >>> are >>>>>> the >>>>>>>> ones >>>>>>>>>> we >>>>>>>>>>>>> have >>>>>>>>>>>>>>> now >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> right ones? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 10:25 AM Matt >>> Burgess < >>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'm actively working this, I pushed my >>>>>> branch up >>>>>>>> in >>>>>>>>>> case >>>>>>>>>>>>> anyone >>>>>>>>>>>>>>>>>> wants >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>> take a look [1]. The idea is to >> abstract >>> the >>>>>>>>> Cassandra >>>>>>>>>>>> API >>>>>>>>>>>>> "up >>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>> couple >>>>>>>>>>>>>>>>>>>>>> levels" and provide implementations for >>>>>> Cassandra >>>>>>>> 3, >>>>>>>>>> 4, >>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> eventually >>>>>>>>>>>>>>>>>>>>> 5. >>>>>>>>>>>>>>>>>>>>>> For JDBC-like interfaces this is a PITA >>>>>> because of >>>>>>>>> the >>>>>>>>>>>> API >>>>>>>>>>>>>>>>>> (Statement, >>>>>>>>>>>>>>>>>>>>>> PreparedStatement, BoundStatement, >>> ResultSet, >>>>>>>> etc.) >>>>>>>>>> but >>>>>>>>>>>> I'm >>>>>>>>>>>>>>>> hoping >>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>>>> find a common pattern for abstracting >> the >>>>>>>>> third-party >>>>>>>>>>>>> library >>>>>>>>>>>>>>>>>>>>>> implementation and API from the NiFi >>>>>> component >>>>>>>>>>>> (Processor, >>>>>>>>>>>>>>>>>>>>>> ControllerService, etc.) API. I think >>> we're >>>>>> doing >>>>>>>>>>>> something >>>>>>>>>>>>>>>> similar >>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>> Kafka? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>> Matt >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [1] >>>>>> https://github.com/mattyb149/nifi/tree/cassy4 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 8:43 AM Mike >>> Thomsen >>>>>> < >>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> That’s been on my todo list for a >>> little >>>>>> while >>>>>>>> but >>>>>>>>>>>> things >>>>>>>>>>>>>>> kept >>>>>>>>>>>>>>>>>>> coming >>>>>>>>>>>>>>>>>>>>> up. >>>>>>>>>>>>>>>>>>>>>>> I think I could get started on that >>> now. >>>>>> Based >>>>>>>> on >>>>>>>>> my >>>>>>>>>>>>> initial >>>>>>>>>>>>>>>>>>> research >>>>>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>>>>> appears that scylla uses the exact >> same >>>>>> api as >>>>>>>>>>>> datastax >>>>>>>>>>>>> so >>>>>>>>>>>>>>>>>>> supporting >>>>>>>>>>>>>>>>>>>>>> both >>>>>>>>>>>>>>>>>>>>>>> in a cql bundle should theoretically >> be >>>>>> fairly >>>>>>>>> easy. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mar 14, 2024, at 6:18 PM, Joe >>> Witt < >>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Team, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Cassandra remains a really >> important >>>>>> system to >>>>>>>>> be >>>>>>>>>>>> able >>>>>>>>>>>>> to >>>>>>>>>>>>>>>> send >>>>>>>>>>>>>>>>>>> data >>>>>>>>>>>>>>>>>>>>> to. >>>>>>>>>>>>>>>>>>>>>>>> However, it seems like we've not >>>>>> maintained >>>>>>>>> these >>>>>>>>>>>>> well. We >>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>> what >>>>>>>>>>>>>>>>>>>>>>>> appears to be at least a full >>> generation >>>>>>>> behind >>>>>>>>> on >>>>>>>>>>>>> client >>>>>>>>>>>>>>>>>> versions >>>>>>>>>>>>>>>>>>>>> (we >>>>>>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>>>>> on 3x vs 4x which is the latest >>> stable >>>>>> with 5x >>>>>>>>>>>>> apparently >>>>>>>>>>>>>>>>>> coming >>>>>>>>>>>>>>>>>>>>>>> shortly). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> We have components to send data, >>> query >>>>>> data, >>>>>>>> and >>>>>>>>>> use >>>>>>>>>>>>>>>> Cassandra >>>>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>>>> cache >>>>>>>>>>>>>>>>>>>>>>>> store. We have older mechanisms >> for >>>>>> json/avro >>>>>>>>> and >>>>>>>>>>>>> publish >>>>>>>>>>>>>>>>>>>>> mechanisms >>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>> records. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The libraries we do have depend on >>>>>> outdated >>>>>>>>>>>> versions of >>>>>>>>>>>>>>> Guava >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>> result >>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>> many CVE hits. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I am inclined to think we should >>>>>> deprecate the >>>>>>>>> 1.x >>>>>>>>>>>>>>> components >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>> remove >>>>>>>>>>>>>>>>>>>>>>>> them as-is from the 2.x line. Then >>>>>>>> re-introduce >>>>>>>>>>>> them >>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>> record >>>>>>>>>>>>>>>>>>>>> only >>>>>>>>>>>>>>>>>>>>>>>> interfaces and built against the >>> latest >>>>>> stable >>>>>>>>>>>>>>>>>>>>>>> Cassandra/Datastax/ScyllaDB >>>>>>>>>>>>>>>>>>>>>>>> interfaces. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I'd love to hear thoughts from >> those >>>>>> closer to >>>>>>>>>> this >>>>>>>>>>>>> space >>>>>>>>>>>>>>>> both >>>>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>>>> user >>>>>>>>>>>>>>>>>>>>>>>> and developer so we can make good >>> next >>>>>> steps. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >>
