Re: Welcome Alexandre Dutra, Andrew Tolbert, Bret McGuire, Olivier Michallat as Cassandra Committers

[Tolbert, Andy]

Thanks everyone!

On Thu, Apr 18, 2024 at 8:43 AM Alexander DEJANOVSKI
 wrote:
>
> Congratulations folks! And thanks for all the hard work throughout the years 
> on the Java Driver!
>
> Le jeu. 18 avr. 2024 à 08:39, Jean-Armel Luce  a écrit :
>>
>> Congratulations everyone !!!
>>
>> Le jeu. 18 avr. 2024 à 07:37, Berenguer Blasi  a 
>> écrit :
>>>
>>> Congrats all!
>>>
>>> On 17/4/24 23:23, Jeremiah Jordan wrote:
>>>
>>> Congrats all!
>>>
>>>
>>> On Apr 17, 2024 at 12:10:11 PM, Benjamin Lerer  wrote:

 The Apache Cassandra PMC is pleased to announce that Alexandre Dutra, 
 Andrew Tolbert, Bret McGuire and Olivier Michallat have accepted the 
 invitation to become committers on the java driver sub-project.

 Thanks for your contributions to the Java driver during all those years!
 Congratulations and welcome!

 The Apache Cassandra PMC members

Re: [VOTE] Release Apache Cassandra Java Driver 4.18.1 (2nd attempt)

[Tolbert, Andy]

+1 (nb)

Looks good!   Also sanity checked diffs between the 4.18.0 / 4.18.1
source tars and the deltas lined up with the changes.   With the
artifacts already in nexus I tried pulling them down with a gradle
project and did a little sanity test and it worked great.

Thanks,
Andy

Re: Cassandra PMC Chair Rotation, 2024 Edition

[Tolbert, Andy]

🎉 congrats Dinesh and thank you Josh!


On Thu, Jun 20, 2024 at 11:54 AM Ekaterina Dimitrova 
wrote:

> Thank you, Josh, and congrats, Dinesh! 🥳
>
> On Thu, 20 Jun 2024 at 19:44, Joseph Lynch  wrote:
>
>> This is exciting news!!
>>
>> Congratulations Dinesh and thank you for taking on this role!  Also thank
>> you to Josh for taking the role this year!
>>
>> -Joey
>>
>> On Thu, Jun 20, 2024 at 12:39 PM Rahul Xavier Singh <
>> rahul.xavier.si...@gmail.com> wrote:
>>
>>> Congrats Dinesh!
>>>
>>> On Thu, Jun 20, 2024 at 12:27 PM Francisco Guerrero 
>>> wrote:
>>>
 Thanks Josh for your contributions to the project as PMC Chair.
 Congratulations Dinesh!

 On 2024/06/20 16:25:26 David Capwell wrote:
 > Congrats!
 >
 > > On Jun 20, 2024, at 9:10 AM, Melissa Logan 
 wrote:
 > >
 > > Josh, thank you for your time as chair + congrats Dinesh!
 > >
 > > On Thu, Jun 20, 2024 at 9:08 AM Abe Ratnofsky >>> a...@aber.io>> wrote:
 > >> Congrats Dinesh! Thank you Josh!
 > >>
 > >>> On Jun 20, 2024, at 11:53 AM, Jeremiah Jordan <
 jeremiah.jor...@gmail.com > wrote:
 > >>>
 > >>> Welcome to the Chair role Dinesh!  Congrats!
 > >>>
 > >>> On Jun 20, 2024 at 10:50:37 AM, Josh McKenzie <
 jmcken...@apache.org > wrote:
 >  Another PMC Chair baton pass incoming! On behalf of the Apache
 Cassandra Project Management Committee (PMC) I would like to welcome and
 congratulate our next PMC Chair Dinesh Joshi (djoshi).
 > 
 >  Dinesh has been a member of the PMC for a few years now and many
 of you likely know him from his thoughtful, measured presence on many of
 our collective discussions as we've grown and evolved over the past few
 years.
 > 
 >  I appreciate the project trusting me as liaison with the board
 over the past year and look forward to supporting Dinesh in the role in the
 future.
 > 
 >  Repeating Mick (repeating Paulo's) words from last year: The
 chair is an administrative position that interfaces with the Apache
 Software Foundation Board, by submitting regular reports about project
 status and health. Read more about the PMC chair role on Apache projects:
 >  - https://www.apache.org/foundation/how-it-works.html#pmc
 >  - https://www.apache.org/foundation/how-it-works.html#pmc-chair
 >  -
 https://www.apache.org/foundation/faq.html#why-are-PMC-chairs-officers
 > 
 >  The PMC as a whole is the entity that oversees and leads the
 project and any PMC member can be approached as a representative of the
 committee. A list of Apache Cassandra PMC members can be found on:
 https://cassandra.apache.org/_/community.html
 > >>
 >
 >

>>>

Re: [DISCUSS] Next steps for Kubernetes operator SIG

[Tolbert, Andy]

Hi John,

Thank you for your efforts on getting this bootstrapped!  I have been
meaning to try getting involved for months and appreciate that the SIG
has been recording sessions and taking down notes.

> * Should we continue down the path of trying to build a common operator
> project? If yes, how should we proceed?

I definitely think there is a lot of value having a common operator
project. The path to contributing to an operator will be much clearer
for some if it's an Apache project.

I see on your email back from Aug 5 that you mentioned a goal of:

> Ramp up a project that can eventually be considered for adoption within ASF, 
> presumably as a subproject of Cassandra

Does there need to be much code established before it gets fully
proposed as a subproject and brought under the apache organization?
>From what I recall cassandra-sidecar [1] was established as an apache
project before there was a lot of code written.

I'll be looking to provide feedback to the repository you've set up
soon, and hope I can contribute to getting this accepted as a
subproject in any way that I can.

> * Should we broaden the focus to using and running Cassandra in Kubernetes
> in general?

Not everyone running Cassandra in K8S is using an operator, so that
could be a good idea.  I'm curious if that would increase
participation, but it does seem like there is a large enough
classification of issues/improvements specific to running Cassandra on
Kubernetes that they'd be worth discussing in the SIG.

[1]: https://github.com/apache/cassandra-sidecar

Thanks,
Andy

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Welcome Doug Rohrer as Cassandra Committer

[Tolbert, Andy]

🎉 Congrats Doug! 🎉

On Fri, Aug 23, 2024 at 1:57 PM Dinesh Joshi  wrote:

> The Apache Cassandra PMC is thrilled to announce that Doug Rohrer has
> accepted the invitation to become a committer!
>
> Doug has worked on several aspects of Cassandra, Sidecar, and
> Analytics. Congratulations and welcome!
>
> The Apache Cassandra PMC members
>

Re: Welcome Chris Bannister, James Hartig, Jackson Flemming and João Reis, as cassandra-gocql-driver committers

[Tolbert, Andy]

Congratulations everyone! 🎉

On Thu, Sep 12, 2024 at 6:41 AM Mick Semb Wever  wrote:

> The PMC's members are pleased to announce that Chris Bannister, James
> Hartig, Jackson Flemming and João Reis have accepted invitations to
> become committers on the Drivers subproject.
>
> Thanks a lot for everything you have done with the gocql driver all these
> years.  We are very excited to see the driver now inside the Apache
> Cassandra project.
>
> Congratulations and welcome!!
>
> The Apache Cassandra PMC
>

Re: [Committer/reviewer needed][CASSJAVA-4] UDT codec decode is too restrictive in decoding of unknown fields

[Tolbert, Andy]

Hi Dmitry,

Thanks for the PR, this fell through my radar, but this seems similar to:

https://datastax-oss.atlassian.net/browse/JAVA-3057
https://github.com/apache/cassandra-java-driver/pull/1635

There is some debate about whether this should be allowed.  My opinion is
that since UDT fields are additive, that it should be safe for a client to
parse a UDT even if its codec was missing fields.

Thanks,
Andy

On Wed, Nov 13, 2024 at 12:58 PM Dmitry Konstantinov 
wrote:

> Hello All,
>
> Some time ago I have submitted a patch what makes UDT codec tolerant to
> extra unknown fields at the tail of UDT to support live schema upgrades:
> https://issues.apache.org/jira/browse/CASSJAVA-4
>
> Could someone help with reviewing it?
>
> Thank you for your time!
> --
> Dmitry Konstantinov
>

Re: [VOTE] CEP-37: Repair scheduling inside C*

[Tolbert, Andy]

+1 (nb)

On Tue, Nov 5, 2024 at 9:51 PM Josh McKenzie  wrote:

> +1
>
> On Tue, Nov 5, 2024, at 4:28 PM, Jaydeep Chovatia wrote:
>
> Hi Everyone,
>
> I would like to start the voting for CEP-37 as all the feedback in the
> discussion thread seems to be addressed.
>
> Proposal: CEP-37 Repair Scheduling Inside Cassandra
> 
> Discussion thread:
> https://lists.apache.org/thread/nl8rmsyxxovryl3nnlt4mzrj9t0x66ln
>
> As per the CEP process documentation, this vote will be open for 72 hours
> (longer if needed).
>
> Thanks,
> Jaydeep
>
>

Re: [VOTE] Release Apache Cassandra Java Driver 4.19.0

[Tolbert, Andy]

+1 (nb)

Tried a few things
* Added the maven repository to a project and did some quick sanity testing
w/ 4.19.0 (java-driver-core and java-driver-core-shaded)
* signature matches Bret's from KEYS
 and also verified checksums
from subversion
* built the source tarball with JDK8

Thanks,
Andy

On Thu, Feb 6, 2025 at 4:34 PM Bret McGuire  wrote:

>Greetings all!  I’m proposing the test build of Cassandra Java Driver
> 4.19.0 for release.
>
> sha1: 46444eaabdbd23e9231123198536d070e99aca27
>
> Git:  
> https://github.com/apache/cassandra-java-driver/tree/4.19.0
>
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1364/
>
>The vote will be open for 120 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding +1s
> and no -1's.
>
>Thanks!
>

Re: Re-evaluate compaction defaults in 5.1/trunk

[Tolbert, Andy]

> @Andy - you can set the default compaction strategy in C* yaml now.

Oh, this is very cool and I'm happy to see it!  Looks like that landed as
part of the UCS contribution itself (CASSANDRA-18397 Unified Compaction
Strategy ), great
idea.

> For a very common example, a lot of clusters are now using the k8ssandra
operator in AWS, which needs EBS.  It's incredibly easy to fall behind on
compaction there.

Yeah, this reinforces my feelings that with LCS; you feel it early, you get
to reason about that right away.  Cluster can't keep up with writes, do I
need more capacity?  do I need to tune something?  Not to say the situation
of having thousands of pending compactions and SSTables in L0 is a good
user experience

With STCS, you may not have to reason about this until later where you
might have nodes get out of sync, and now repairs are going to really
punish you; that could be worse when using STCS if you have large
SSTables.  Or if your read performance is really bad because your data is
spread out amount a ton of sstables, or you are touching a ton of
tombstones that aren't going away for some reason.  This is not a trivial
thing for someone to debug or understand why their reads got slow or are
failing suddenly.   There's just a lot of things that I feel can work
better operationally and more predictably with LCS because SSTables have a
capped size and partitions don't overlap many sstables (reads, streaming,
repairs, anticompaction, etc.).

In any case,  I agree that changing the default to LCS would not be best
right now, even if I feel it is generally better.   Hopefully in the future
UCS is viewed as production ready and can be considered as a possible
default, especially if it can address the issues users encounter with STCS
and LCS in a better way.

Thanks,
Andy

On Fri, Dec 6, 2024 at 11:23 PM Jon Haddad  wrote:

> For a very common example, a lot of clusters are now using the k8ssandra
> operator in AWS, which needs EBS.  It's incredibly easy to fall behind on
> compaction there.  It's why I'm so interested in seeing CASSANDRA-15452 get
> merged in.  I've dealt with quite a few of these clusters, in fact I just
> worked on one this week.  They're now happily running UCS on 5.0.
>
> Like it or not, LCS is a poor fit for a non-trivial number of teams.  Not
> saying STCS doesn't have some poor use cases, but read amplification from
> reading lots of SSTables is generally better for the end user than being
> thousands of compactions behind.  I'm trying to do the least amount of harm
> to the fewest number of teams.
>
> @Andy - you can set the default compaction strategy in C* yaml now.
>
> # default_compaction:
> #   class_name: SizeTieredCompactionStrategy
> #   parameters:
> # min_threshold: 4
> # max_threshold: 32
>
> Jon
>
>
> On Fri, Dec 6, 2024 at 8:58 PM Dinesh Joshi  wrote:
>
>> I’m genuinely curious to understand how is defaulting to LCS going to
>> cause a nightmare? I am not sure what the concern is over here.
>>
>> On Fri, Dec 6, 2024 at 8:53 PM Jon Haddad 
>> wrote:
>>
>>> You're ignoring the other side here.  For the folks who *can't* use LCS,
>>> defaulting to it is a nightmare.
>>>
>>> Sorry, but you can't screw over 20% of the community to make life a
>>> little better for the 80%.  This is a terrible tradeoff.
>>>
>>>
>>> Jon
>>>
>>> On Fri, Dec 6, 2024 at 8:36 PM Dinesh Joshi  wrote:
>>>
 I would argue that vast majority of real world workloads are read
 heavy. LCS would therefore be a net benefit for the average user.

 To mitigate the write amplification concern I would make this change
 and make sure it is well documented for operators so they’re not caught off
 guard.

 On Fri, Dec 6, 2024 at 8:06 PM Jeff Jirsa  wrote:

> And it works for that most of the time, so what’s the concern? “You
> lose throughput because iops / write amplification go up, so the perf of
> the default install goes down” ? (But the cost per byte goes way down,
> too)?
>
>
>
> On Dec 6, 2024, at 8:01 PM, Brad  wrote:
>
> > Could you elaborate what you mean by 'disk storage management'?
>
> I often see clusters use LCS as an easy fix to avoid the 50% disk free
> recommendation of STCS without considering the write
> magnification implications.
>
> On Fri, Dec 6, 2024 at 10:46 PM Dinesh Joshi 
> wrote:
>
>> Could you elaborate what you mean by 'disk storage management'?
>>
>> On Fri, Dec 6, 2024 at 7:30 PM Brad  wrote:
>>
>>> I'm -1 on LCS being the default, seen far too many people use it for
>>> disk storage management
>>>
>>> On Fri, Dec 6, 2024 at 10:08 PM Jon Haddad 
>>> wrote:
>>>
 I'm -1 on LCS being the default, since using it in the wrong
 situations renders clusters inoperable.


 On Fri, Dec 6, 2024 at 7:03 PM Paulo Motta 
 wrote:

Re: Re-evaluate compaction defaults in 5.1/trunk

[Tolbert, Andy]

It's also quite easy for STCS to make clusters inoperable, and it can be
quite difficult to dig yourself out of.   It's not hard to find yourself in
a state where you have old 100GB+ SSTables full of expired data that never
get compacted sitting around for months.

Write amplification is a thing, but in the age of fast storage I'd consider
it less of an issue.  The amount of compaction throughput will be felt
rather quickly and its something you can reason with and account for early
on.  Whereas with STCS the impact may not be felt until way later.  There
are sharp edges around large SSTables with repairs and streaming that are
mostly avoided by using LCS as well.

There's also been some really great improvements that have make LCS work
really great generally; such as CASSANDRA-17931
, which while not
LCS-specific, can enable compactions to continue being productive even at
incredibly low disk space.  Single SSTable upleveling (CASSANDRA-12526
) also helps reduce
some of that amplification when the LCS detects an SSTable can be promoted
without rewriting data if it doesn't overlap with SSTables in level its
being promoted to.

If you are running Cassandra as a managed service where customers aren't as
experienced or understand the tradeoffs of the compaction strategies, I
think LCS puts the operators of the Cassandra cluster in a better place.
Read performance is more predictable with LCS with uniform SSTable sizes
(outside of L0) and the levels acting as a way to reduce the number of
SSTables touched per read.  Operationally it is just more predictable.

On the topic of changing the default, I think with the introduction of
UnifiedCompactionStrategy that maybe it's an awkward time to change this.
 Would love to see UCS become proven and production ready where we feel it
could become an accepted default,  until that becomes the case (or not), I
don't think changing the default is right.  I also generally think changing
defaults between releases should be discouraged unless it's generally a no
brainer, and this doesn't feel like one to me.

Maybe a possible approach could be to have a mechanism such that an
operator can declare the default table options for new tables?   This would
allow operators to control what they think the default might be.  This
could extend beyond compaction as I know there are some subjective opinions
about what could have better defaults (compression chunk length,
gc_grace_seconds could be lower (if only_purge_repaired_tombstones
enabled), speculative_retry, etc.).

Thanks,
Andy

On Fri, Dec 6, 2024 at 10:01 PM Brad  wrote:

> > Could you elaborate what you mean by 'disk storage management'?
>
> I often see clusters use LCS as an easy fix to avoid the 50% disk free
> recommendation of STCS without considering the write
> magnification implications.
>
> On Fri, Dec 6, 2024 at 10:46 PM Dinesh Joshi  wrote:
>
>> Could you elaborate what you mean by 'disk storage management'?
>>
>> On Fri, Dec 6, 2024 at 7:30 PM Brad  wrote:
>>
>>> I'm -1 on LCS being the default, seen far too many people use it for
>>> disk storage management
>>>
>>> On Fri, Dec 6, 2024 at 10:08 PM Jon Haddad 
>>> wrote:
>>>
 I'm -1 on LCS being the default, since using it in the wrong situations
 renders clusters inoperable.


 On Fri, Dec 6, 2024 at 7:03 PM Paulo Motta  wrote:

> > I'd prefer to see the default go from STCS to UCS
>
> I’m proposing this for latest unstable (cassandra_latest.yaml) since
> it’s a more recent strategy still being adopted. For latest stable
> (cassandra.yaml) I’d prefer LCS since it does not need tuning to support
> mutable workloads (UPDATE/DELETE) and is battle-tested.
>
> On Fri, 6 Dec 2024 at 21:37 Jon Haddad 
> wrote:
>
>> I'd prefer to see the default go from STCS to UCS, probably with
>> scaling_parameters T4.  That's essentially the same as STCS but without 
>> the
>> ridiculous SSTable growth, allowing us to leverage the fast streaming 
>> path
>> more often.  I don't think there's any valid use cases for STCS anymore 
>> now
>> that we have UCS.
>>
>> That said, many have taken issue with the state of UCS docs, myself
>> included, so that would need to be addressed with any default change.
>>
>> I don't think we should mark TWCS as experimental.  Maybe we prevent
>> repairs to tables using TWCS, or do a better job of encouraging folks to
>> use incremental repair at higher frequencies.  It's definitely not
>> experimental though.
>>
>> Side note: I think experimental has been over-used and has lost all
>> meaning.  How is Java 17 experimental?  Very confusing for the community.
>>
>> I think TWCS should use UCS under the hood which would address
>> streaming performance (and thus node density) or UCS could be updated to

Re: [VOTE] Release Apache Cassandra Java Driver 3.12.0 (2nd attempt)

[Tolbert, Andy]

+1 (nb)

On Wed, Jan 8, 2025 at 8:22 PM Chris Lohfink  wrote:

> +1
>
> On Wed, Jan 8, 2025 at 4:14 PM Bret McGuire 
> wrote:
>
>> Greetings all!
>>
>>I’m proposing the Cassandra Java Driver 3.12.0 for release.  This
>> represents a second attempt at releasing this version; an earlier attempt
>> failed due to a staging issue.
>>
>> sha1: 1a96d27130ea43ed5762c4f7b7cc182eb24f8952
>>
>> git: https://github.com/apache/cassandra-java-driver/tree/3.x
>>
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1354
>>
>>The Source release is available here:
>>
>>
>> https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver/3.12.0/
>>
>>To recap: this is the first release of the 3.x Java driver since its
>> donation.  This release is nearly identical to the last DataStax release (
>> 3.11.5
>> ).
>> The full changelog can be found at
>> https://github.com/apache/cassandra-java-driver/tree/3.x/changelog#3120
>>
>>The vote will be open for 72 hours (longer if needed).  Everyone who
>> has tested the build is invited to vote. Votes by PMC members are
>> considered binding. A vote passes if there are at least three binding +1s
>> and no -1's.
>>
>>Thanks!
>>
>>
>> - Bret -
>>
>>

Re: Checkstyle as style contract for Cassandra

[Tolbert, Andy]

d I suggested that we might explore how to make it the
> part of generate-idea-files. What are we trying to solve by reformatting
> 2k+ files to have braces elsewhere?
> >>
> >> On Fri, Jan 17, 2025 at 3:05 PM Josh McKenzie 
> wrote:
> >>>
> >>> As is tradition, this thread has split off into a few topics; fwiw I
> take this as a very positive sign as it means we all care a lot about the
> project and what we work on, and it's a sign we should maybe talk more
> frequently about discrete topics instead of remembering adjacent topics
> when something like this comes up and piling on. ;)
> >>>
> >>> Let me try and round them up and snapshot any indications of consensus:
> >>>
> >>> Should we automate linting / formatting? Strong no from ay / bes, some
> loose opinions in favor of it. Maybe a compromise would be having a
> checkstyle target that'd include formatting people could optionally run
> locally but not formally integrating it into CI; make it opt-in.
> >>> Are we happy with our bracing style, and would it be too painful to
> change it now? Seems like, in general, we range from -1 to -0 for all but
> one or two outliers who are +1.
> >>>
> >>> Abe pointed out (in a forked thread in my email client /sad) that we
> can use a --ignore-revs-file option in git to switch bracing style in one
> go and keep our history.
> >>> Caleb pointed out we can do that trunk only.
> >>> Mick seconded raised concerns about forks absorbing pain. It'd be a
> post-accord consideration so at least mainline rebase pain would be
> minimized, and if we kept it to trunk-only that'd probably be fine.
> >>>
> >>> Should we put together a review guideline for the project? Worth
> considering for us as a project; Benedict indicated receptivity to us
> having one based on the google one here.
> >>>
> >>> So, Bernardo: hopefully the general "vibes" of what you were shooting
> for on this thread initially are answered in terms of us covering our
> surface area of the status quo. Shall we break out into 3 [DISCUSS] threads
> for each of the above 3 topics and put this thread to rest?
> >>>
> >>> On Fri, Jan 17, 2025, at 6:36 AM, Benedict wrote:
> >>>
> >>>
> >>> I would support adopting a review guide based on this one.
> >>>
> >>> On 16 Jan 2025, at 15:36, Josh McKenzie  wrote:
> >>>
> >>> 
> >>>
> >>> Perhaps a “Review Guide” is what we need to make sure we keep review
> primarily focused on the core contribution, and to help avoid folk getting
> bogged down in style sniping.
> >>>
> >>> I recall reading through / offering this guide in the past as a
> starting point for an org I was managing at the time:
> https://google.github.io/eng-practices/review/reviewer/
> >>>
> >>> Been years; might be worth it to have a skim through that and see if
> it could serve as a reasonable starting point for us if someone has the
> inclination.
> >>>
> >>> On Thu, Jan 16, 2025, at 9:17 AM, Benedict wrote:
> >>>
> >>>
> >>> I can imagine that it might cause some frustrating review interactions
> people would like to avoid, but for solving that I’d prefer we take a more
> social approach.
> >>>
> >>> Review shouldn’t spend much time on minor style points, and these
> should normally be framed as suggestions. Obviously newer contributors may
> need pointing to the style guide as something to familiarise themselves
> with, but it shouldn’t readily be invoked as a “thou shalt do this” tool.
> >>>
> >>> Perhaps a “Review Guide” is what we need to make sure we keep review
> primarily focused on the core contribution, and to help avoid folk getting
> bogged down in style sniping.
> >>>
> >>>
> >>> On 16 Jan 2025, at 14:08, Josh McKenzie  wrote:
> >>>
> >>> 
> >>> Right now our codebase is pretty consistent, especially for not having
> a linter enforcing this kind of thing. Are we trying to solve for codebase
> consistency, education of new contributors, both? Neither?
> >>>
> >>> If just solving for consistency I'd argue we're good. If educating new
> contributors, the Code Style guide seems pretty thorough to me?
> https://cassandra.apache.org/_/development/code_style.html
> >>>
> >>> All of which is to say - it feels like the status quo is fine here for
> me. i.e. it's not clear t

Re: Checkstyle as style contract for Cassandra

[Tolbert, Andy]

Reading back https://issues.apache.org/jira/browse/CASSANDRA-19276 a bit
more, I think I *was* able to make checkstyle bend to the "Code Style"
definition by ignoring lambda tokens.  It's just that there were a lot of
"violations" which defined a method on one line:

public int  getActiveTaskCount(){ return 0; }
public long getCompletedTaskCount() { return 0; }
public int  getPendingTaskCount()   { return 0; }
public int  getCorePoolSize()   { return 0; }
public int  getMaximumPoolSize(){ return 0; }

I felt that this code was perfectly readable and wouldn't be right to
change.  This is what I wanted to make checkstyle consider acceptable.

I think it would be really nice if checkstyle would fail for the more
obvious case we want to avoid that comes up in reviews or sometimes slips
into the codebase if not caught by a reviewer, e.g.:

if {
//...
}

Thanks,
Andy

On Wed, Jan 15, 2025 at 6:21 PM Tolbert, Andy  wrote:

> Hi Bernardo,
>
> Thanks for bringing this up!
>
> Last year I was looking into enforcing curly braces as defined in Code
> Style <https://cassandra.apache.org/_/development/code_style.html> and
> had some thoughts on how to make this work but hit a bit of a brick wall:
>
> https://issues.apache.org/jira/browse/CASSANDRA-19276
>
> I don't think there is an easy way as is to enforce this with checkstyle
> currently:
>
> "{ and } are placed on a new line except when empty or opening a
> multi-line lambda expression. Braces may be elided to a depth of one if the
> condition or loop guards a single expression."
>
> Without making changes to checkstyle itself (e.g.:
> https://github.com/checkstyle/checkstyle/issues/12226).
>
> I think if we were to add a new rule around brackets and newlines, we
> would ideally try to make it match the Code style definition as its
> declared, and hopefully it would not be too require touching a lot of files
> (which maybe the case unfortunately).
>
> Thanks,
> Andy
>
> On Wed, Jan 15, 2025 at 6:10 PM Benedict  wrote:
>
>> Even something as simple as the curly brace rule has sensible exceptions.
>> I’m pretty hard -1 on letting a linter make all our editing decisions.
>> Formatting is a contextual choice about how to best represent information
>> to the reader, and we should not abdicate responsibility. The style guide
>> is exactly that, a guide and that helps us navigate editing choices, and it
>> can be evolved or refined via discussion and experimentation.
>>
>> For example, the second clause in your quote (re: lambdas) came about
>> only because we could break the restrictions of the first clause and
>> demonstrate an improvement to readability.
>>
>> If this is a pain point during review, either some people are too eager
>> to point to the code style guide, or perhaps your IDE defaults need
>> updating. This shouldn’t cause lots of traffic.
>>
>> People should try not to overly nitpick formatting, though of course a
>> balance is to be struck between contributors’ expression of their code and
>> that code sitting neatly in its context in the codebase.
>>
>> > On 15 Jan 2025, at 23:50, Bernardo Botella <
>> conta...@bernardobotella.com> wrote:
>> >
>> > Hi everyone!
>> >
>> > I wanted to raise a question about code style for the project. I've
>> been receiving some feedback on PRs about the need to:
>> > - Have curly braces start on a new line
>> > - Remove curly braces if the condition or loop has only one expression
>> >
>> > Taking a look at the official Code Style stated in the web, I read that:
>> > "{ and } are placed on a new line except when empty or opening a
>> multi-line lambda expression. Braces may be elided to a depth of one if the
>> condition or loop guards a single expression."
>> >
>> > Which addresses the first type of comments I mentioned (curly braces
>> starting in a new line), but leaves open the second type of comments
>> (remove not needed curly braces).
>> >
>> > But, when looking at the checkstyle.xml, I don't see any rule enforcing
>> any of those two types of comments.
>> >
>> > I believe checkstyle.xml should be our contract, so I'm proposing here:
>> >
>> > For "curly braces starting in a new line" rule, add something like what
>> we already have on Sidecar and Analytics projects:
>> > 
>> >
>> >
>> > ...
>> > 
>> >
>> > That way, we can fail fast and not worry about those comments on PRs.
>> This of course may be pa

Re: Checkstyle as style contract for Cassandra

[Tolbert, Andy]

Hi Bernardo,

Thanks for bringing this up!

Last year I was looking into enforcing curly braces as defined in Code Style
 and had some
thoughts on how to make this work but hit a bit of a brick wall:

https://issues.apache.org/jira/browse/CASSANDRA-19276

I don't think there is an easy way as is to enforce this with checkstyle
currently:

"{ and } are placed on a new line except when empty or opening a multi-line
lambda expression. Braces may be elided to a depth of one if the condition
or loop guards a single expression."

Without making changes to checkstyle itself (e.g.:
https://github.com/checkstyle/checkstyle/issues/12226).

I think if we were to add a new rule around brackets and newlines, we would
ideally try to make it match the Code style definition as its declared, and
hopefully it would not be too require touching a lot of files (which maybe
the case unfortunately).

Thanks,
Andy

On Wed, Jan 15, 2025 at 6:10 PM Benedict  wrote:

> Even something as simple as the curly brace rule has sensible exceptions.
> I’m pretty hard -1 on letting a linter make all our editing decisions.
> Formatting is a contextual choice about how to best represent information
> to the reader, and we should not abdicate responsibility. The style guide
> is exactly that, a guide and that helps us navigate editing choices, and it
> can be evolved or refined via discussion and experimentation.
>
> For example, the second clause in your quote (re: lambdas) came about only
> because we could break the restrictions of the first clause and demonstrate
> an improvement to readability.
>
> If this is a pain point during review, either some people are too eager to
> point to the code style guide, or perhaps your IDE defaults need updating.
> This shouldn’t cause lots of traffic.
>
> People should try not to overly nitpick formatting, though of course a
> balance is to be struck between contributors’ expression of their code and
> that code sitting neatly in its context in the codebase.
>
> > On 15 Jan 2025, at 23:50, Bernardo Botella 
> wrote:
> >
> > Hi everyone!
> >
> > I wanted to raise a question about code style for the project. I've been
> receiving some feedback on PRs about the need to:
> > - Have curly braces start on a new line
> > - Remove curly braces if the condition or loop has only one expression
> >
> > Taking a look at the official Code Style stated in the web, I read that:
> > "{ and } are placed on a new line except when empty or opening a
> multi-line lambda expression. Braces may be elided to a depth of one if the
> condition or loop guards a single expression."
> >
> > Which addresses the first type of comments I mentioned (curly braces
> starting in a new line), but leaves open the second type of comments
> (remove not needed curly braces).
> >
> > But, when looking at the checkstyle.xml, I don't see any rule enforcing
> any of those two types of comments.
> >
> > I believe checkstyle.xml should be our contract, so I'm proposing here:
> >
> > For "curly braces starting in a new line" rule, add something like what
> we already have on Sidecar and Analytics projects:
> > 
> >
> >
> > ...
> > 
> >
> > That way, we can fail fast and not worry about those comments on PRs.
> This of course may be painful, as we probably will have to fix a bunch of
> wrongly placed brackets all over the place.
> >
> > If there are no concerns here, I'll be more than happy to bite the
> bullet and add a patch for this.
> >
> >
> >
> > For "remove not needed curly braces", I understand that it tends to be
> the preference on the code, so we either modify the documentation and add a
> rule for that on the checkstyle.xml, or we are fine with that style and
> there is no need to remove them on patches.
> >
> > I wanted to hear the thoughts on the community for this one. My
> preference is to always use brackets, but that's just a preference, so it's
> perfectly fine not to enforce it and leave the documentation as is.
> >
> > Thanks everyone!
> > Bernardo
>

Re: Checkstyle as style contract for Cassandra

[Tolbert, Andy]

cused on the core contribution, and to help avoid folk getting
>> bogged down in style sniping.
>> >>>>
>> >>>> I recall reading through / offering this guide in the past as a
>> starting point for an org I was managing at the time:
>> https://google.github.io/eng-practices/review/reviewer/
>> >>>>
>> >>>> Been years; might be worth it to have a skim through that and see if
>> it could serve as a reasonable starting point for us if someone has the
>> inclination.
>> >>>>
>> >>>> On Thu, Jan 16, 2025, at 9:17 AM, Benedict wrote:
>> >>>>
>> >>>>
>> >>>> I can imagine that it might cause some frustrating review
>> interactions people would like to avoid, but for solving that I’d prefer we
>> take a more social approach.
>> >>>>
>> >>>> Review shouldn’t spend much time on minor style points, and these
>> should normally be framed as suggestions. Obviously newer contributors may
>> need pointing to the style guide as something to familiarise themselves
>> with, but it shouldn’t readily be invoked as a “thou shalt do this” tool.
>> >>>>
>> >>>> Perhaps a “Review Guide” is what we need to make sure we keep review
>> primarily focused on the core contribution, and to help avoid folk getting
>> bogged down in style sniping.
>> >>>>
>> >>>>
>> >>>> On 16 Jan 2025, at 14:08, Josh McKenzie 
>> wrote:
>> >>>>
>> >>>> 
>> >>>> Right now our codebase is pretty consistent, especially for not
>> having a linter enforcing this kind of thing. Are we trying to solve for
>> codebase consistency, education of new contributors, both? Neither?
>> >>>>
>> >>>> If just solving for consistency I'd argue we're good. If educating
>> new contributors, the Code Style guide seems pretty thorough to me?
>> https://cassandra.apache.org/_/development/code_style.html
>> >>>>
>> >>>> All of which is to say - it feels like the status quo is fine here
>> for me. i.e. it's not clear to me what problem we're trying to solve w/a
>> change here.
>> >>>>
>> >>>> On Wed, Jan 15, 2025, at 9:58 PM, guo Maxwell wrote:
>> >>>>
>> >>>> I agree with you for all these two points.
>> >>>>
>> >>>> I think you should open a ticket to solve this if you want to add a
>> rule to checkstyle, as I know there are many old codes that do not comply
>> with this rule.
>> >>>> For point 2, this really feels like personal preference, but I'd
>> probably listen to the reviewer's opinion.😁
>> >>>>
>> >>>> Tolbert, Andy  于2025年1月16日周四 08:47写道：
>> >>>>
>> >>>> Reading back https://issues.apache.org/jira/browse/CASSANDRA-19276
>> a bit more, I think I *was* able to make checkstyle bend to the "Code
>> Style" definition by ignoring lambda tokens.  It's just that there were a
>> lot of "violations" which defined a method on one line:
>> >>>>
>> >>>> public int  getActiveTaskCount(){ return 0; }
>> >>>> public long getCompletedTaskCount() { return 0; }
>> >>>> public int  getPendingTaskCount()   { return 0; }
>> >>>> public int  getCorePoolSize()   { return 0; }
>> >>>> public int  getMaximumPoolSize(){ return 0; }
>> >>>>
>> >>>> I felt that this code was perfectly readable and wouldn't be right
>> to change.  This is what I wanted to make checkstyle consider acceptable.
>> >>>>
>> >>>> I think it would be really nice if checkstyle would fail for the
>> more obvious case we want to avoid that comes up in reviews or sometimes
>> slips into the codebase if not caught by a reviewer, e.g.:
>> >>>>
>> >>>> if {
>> >>>> //...
>> >>>> }
>> >>>>
>> >>>> Thanks,
>> >>>> Andy
>> >>>>
>> >>>> On Wed, Jan 15, 2025 at 6:21 PM Tolbert, Andy 
>> wrote:
>> >>>>
>> >>>> Hi Bernardo,
>> >>>>
>> >>>> Thanks for bringing this up!
>> >>>>
>> >>>> Last year I was looking into enforcing curly braces as defined

Re: Checkstyle as style contract for Cassandra

[Tolbert, Andy]

> Isn't that what ant generate-idea-files does automatically? (that it sets
code style like that)

Unless i'm not doing something right (very possible), I don't think it does
this automatically with generate-idea-files.  I've gotten in the habit of
updating my Checkstyle plugin to pull in .build/checkstyle.xml whenever I
regenerate my project.  The checkstyle plugin is definitely very useful.

It doesn't currently enforce any code style around braces since no rule is
currently being enforced in the checkstyle configuration.

Thanks,
Andy

On Thu, Jan 16, 2025 at 2:16 PM Štefan Miklošovič 
wrote:

> _ The burden shouldn’t be on humans to place or check that every curly
> brace is on its own line._
>
> Who is actually doing this? It is one shortcut in IDEA and it all places
> them correctly. I don't even know what the shortcut is, I never think about
> that consciously anymore.
>
> Isn't that what ant generate-idea-files does automatically? (that it sets
> code style like that)
>
> A committer can just format that upon merge, we do not need to stress
> about that during reviews.
>
> On Thu, Jan 16, 2025 at 8:44 PM Jordan West  wrote:
>
>> IMO the more we can enforce the style guide programmatically the better.
>> It was a big improvement when we got parts of it in IntelliJ. It saves time
>> and reduces friction. The burden shouldn’t be on humans to place or check
>> that every curly brace is on its own line. And if we say don’t check during
>> review or automatically then why have a guide? Sure we can nitpick on the
>> definition of the word “guide” here but I think we all mostly agree a
>> uniform style (with some wiggle room for edge cases) is good for the
>> project. Or again, why have the guide?
>>
>> The challenge is getting these tools to do what we want can be a pain as
>> folks who have explored it have outlined. So then I think it comes back to
>> Josh’s question (to paraphrase) of “is it good enough as is”? And as an
>> aside we might want to ask ourselves “why have we chosen a style guide that
>> is hard to implement in these tools?”
>>
>> If folks see some easy wins and want to volunteer time to make the
>> changes I think we should encourage that.
>>
>> On Thu, Jan 16, 2025 at 07:35 Josh McKenzie  wrote:
>>
>>> Perhaps a “Review Guide” is what we need to make sure we keep review
>>> primarily focused on the core contribution, and to help avoid folk getting
>>> bogged down in style sniping.
>>>
>>> I recall reading through / offering this guide in the past as a starting
>>> point for an org I was managing at the time:
>>> https://google.github.io/eng-practices/review/reviewer/
>>>
>>> Been years; might be worth it to have a skim through that and see if it
>>> could serve as a reasonable starting point for us if someone has the
>>> inclination.
>>>
>>> On Thu, Jan 16, 2025, at 9:17 AM, Benedict wrote:
>>>
>>>
>>> I can imagine that it might cause some frustrating review interactions
>>> people would like to avoid, but for solving that I’d prefer we take a more
>>> social approach.
>>>
>>> Review shouldn’t spend much time on minor style points, and these should
>>> normally be framed as suggestions. Obviously newer contributors may need
>>> pointing to the style guide as something to familiarise themselves with,
>>> but it shouldn’t readily be invoked as a “thou shalt do this” tool.
>>>
>>> Perhaps a “Review Guide” is what we need to make sure we keep review
>>> primarily focused on the core contribution, and to help avoid folk getting
>>> bogged down in style sniping.
>>>
>>>
>>> On 16 Jan 2025, at 14:08, Josh McKenzie  wrote:
>>>
>>> 
>>> Right now our codebase is pretty consistent, especially for not having a
>>> linter enforcing this kind of thing. Are we trying to solve for codebase
>>> consistency, education of new contributors, both? Neither?
>>>
>>> If just solving for consistency I'd argue we're good. If educating new
>>> contributors, the Code Style guide *seems* pretty thorough to me?
>>> https://cassandra.apache.org/_/development/code_style.html
>>>
>>> All of which is to say - it *feels* like the status quo is fine here
>>> for me. i.e. it's not clear to me what problem we're trying to solve w/a
>>> change here.
>>>
>>> On Wed, Jan 15, 2025, at 9:58 PM, guo Maxwell wrote:
>>>
>>> I agree with you for all these two points.
>>>
>

Re: [Discuss] Decoupling java driver dependency from server code; migrate tools and tests to 4.x driver

[Tolbert, Andy]

Jon

> We can probably skip cassandra-stress, since it looks like
easy-cass-stress can be donated.  That does need a driver upgrade to
support a vector workload, but imo there's no point in investing more in
cassandra-stress when we have an alternative with more features available.
Not a hill I'm going to die on, just an opportunity to do less work.

That sounds great!   I think it's likely that we can manage separate
classpaths for the various tools, so we could update the driver dependency
in fqltool and cassandra-loader in the meantime and leave cassandra-stress
as is if it is going to be superseded.

JD,

> For the tests, maybe we can have two test class paths for a while?  One
for driver 3 and one for driver 4?  That way we don’t need to migrate them
all in a giant big bang patch?  They could be moved over a few at a time
making review much easier.

I'll explore if this is possible as I think that could potentially work and
be more manageable.  I can also evaluate whether its possible for the two
drivers to co-exist on the same classpath (I think that may be the case,
but I'm not certain).

Thanks,
Andy


On Wed, Feb 12, 2025 at 6:59 PM J. D. Jordan 
wrote:

> Sounds like a reasonable plan to me. +1
>
> For the tests, maybe we can have two test class paths for a while?  One
> for driver 3 and one for driver 4?  That way we don’t need to migrate them
> all in a giant big bang patch?  They could be moved over a few at a time
> making review much easier.
>
> On Feb 12, 2025, at 6:35 PM, Jon Haddad  wrote:
>
> 
> Hey Andy,
>
> This seems like a reasonable proposal.
>
> We can probably skip cassandra-stress, since it looks like
> easy-cass-stress can be donated.  That does need a driver upgrade to
> support a vector workload, but imo there's no point in investing more in
> cassandra-stress when we have an alternative with more features available.
> Not a hill I'm going to die on, just an opportunity to do less work.
>
> Jon
>
>
>
>
> On Wed, Feb 12, 2025 at 3:06 PM Tolbert, Andy  wrote:
>
>> Hi All,
>>
>> I'd like to propose decoupling the java driver as a dependency from the
>> core
>> Cassandra server code.
>>
>> I also want to propose a path towards eventually migrating test and tools
>> code
>> from Apache Cassandra java driver 3.x to 4.x when the time is right for
>> the
>> project.
>>
>> Refactoring test code to 4.x is likely to be quite invasive, as I count
>> 128 source files utilizing driver code.  We'd want to find a good time to
>> do
>> this to minimize disruption to ongoing development.
>>
>> Java driver 4.x is effectively a rewrite of the 3.x driver.  Its first
>> release
>> was in March of 2019. While it has similar APIs, it is not binary
>> compatible
>> with the 3.x driver [1].
>>
>> While there hasn't been a clear decision on how the 3.x driver will be
>> supported going forward (although we should consider discussing this!), we
>> expect and have seen active development take place mostly exclusively
>> on the 4.x driver.
>>
>> It would be useful to migrate to the 4.x driver to test new and future
>> features
>> of which the 4.x driver will actively support.  For example, the 4.x
>> driver
>> supports Vector types, where the 3.x driver does not.
>>
>> I've iterated the codebase and identified the following uses of the
>> driver:
>>
>> 0. Core code that uses the driver
>>
>> * UntypedResultSet uses CodecUtils.fromUnsignedToSignedInt from the driver
>>   which is just adding Integer.MIN_VALUE to an int so can easily be
>> removed.
>> * PreparedStatementHelper is used only by dtest fuzz tests to validate
>>   Prepared Statements.  Can be moved to test code.
>> * ThreadAwareSecurityManager.checkPermission makes reference to skipping
>>   checking accessDeclaredMembers due to use of CodecUtils, can probably
>> remove
>>   that with its use removed.
>> * sstableloader uses the driver to fetch schema and metadata
>>
>> 1. Tools that use the driver
>>
>> * fqltool replay (replaying queries from captured logs)
>> * cassandra-stress (making queries to generate load)
>>
>> 2. Test code
>>
>> * Understandably, quite a bit of test code uses the driver. This is where
>> I
>>   anticipate the most work would be be needed.
>>
>> I'd like to propose doing the following:
>>
>> Can be done now:
>>
>> * Move sstableloader source into its own tools directly, much like fqltool
>>   and cassandra-stress.  For compatibility, we could retain the existing
>> she

Re: Merging compaction improvements to 5.0

[Tolbert, Andy]

The data captured in https://issues.apache.org/jira/browse/CASSANDRA-15452
is really exciting.   I would also be interested in seeing these changes
brought into 5.0.

Thanks,
Andy

On Wed, Feb 12, 2025 at 8:49 PM Jordan West  wrote:

> Regarding the buffer size, it is configurable. My personal take is that
> we’ve tested this on a variety of hardware (from laptops to large instance
> sizes) already, as well as a few different disk configs (it’s also been run
> internally, in test, at a few places) and that it has been reviewed by four
> committers and another contributor. Always love to see more numbers. if
> folks want to take it for a spin on Alibaba cloud, azure, etc and determine
> the best buffer size that’s awesome. We could document which is suggested
> for the community. I don’t think it’s necessary to block on that however.
>
> Also I am of course +1 to including this in 5.0.
>
> Jordan
>
> On Wed, Feb 12, 2025 at 19:50 guo Maxwell  wrote:
>
>> What I understand is that there will be some differences in block storage
>> among various cloud platforms. More intuitively, the default read-ahead
>> size will be the same. For example, AWS ebs seems to be 256K, and Alibaba
>> Cloud seems to be 512K（If I remember correctly).
>>
>> Just like 19488, give the test method, see who can assist in the test ,
>> and provide the results.
>>
>> Jon Haddad  于2025年2月13日周四 08:30写道：
>>
>>> Can you elaborate why?  This would be several hundred hours of work and
>>> would cost me thousands of $$ to perform.
>>>
>>> Filesystems and block devices are well understood.  Could you give me an
>>> example of what you think might be different here?  This is already one of
>>> the most well tested and documented performance patches ever contributed to
>>> the project.
>>>
>>> On Wed, Feb 12, 2025 at 4:26 PM guo Maxwell 
>>> wrote:
>>>
  I think it should be tested on most cloud platforms（at least
 aws、azure、gcp） before merged into 5.0 . Just like  CASSANDRA-19488.

 Paulo Motta 于2025年2月13日 周四上午6:10写道：

> I'm looking forward to these improvements, compaction needs tlc. :-)
> A couple of questions:
>
> Has this been tested only on EBS, or also EC2/bare-metal/Azure/etc? My
> only concern is if this is an optimization for EBS that can be a
> deoptimization for other environments.
>
> Are there reproducible scripts that anyone can run to verify the
> improvements in their own environments ? This could help alleviate any
> concerns and gain confidence to introduce a perf. improvement in a
> patch release.
>
> I have not read the ticket in detail, so apologies if this was already
> discussed there or elsewhere.
>
> On Wed, Feb 12, 2025 at 3:01 PM Jon Haddad 
> wrote:
> >
> > Hey folks,
> >
> > Over the last 9 months Jordan and I have worked on CASSANDRA-15452
> [1].  The TL;DR is that we're internalizing a read ahead buffer to allow 
> us
> to do fewer requests to disk during compaction and range reads.  This
> results in far fewer system calls (roughly 16x reduction) and on systems
> with higher read latency, a significant improvement in compaction
> throughput.  We've tested several different EBS configurations and found 
> it
> delivers up to a 10x improvement when read ahead is optimized to minimize
> read latency.  I worked with AWS and the EBS team directly on this and the
> Best Practices for C* on EBS [2] I wrote for them.  I've performance 
> tested
> this patch extensively with hundreds of billions of operations across
> several clusters and thousands of compactions.  It has less of an impact 
> on
> local NVMe, since the p99 latency is already 10-30x less than what you see
> on EBS (100micros vs 1-3ms), and you can do hundreds of thousands of IOPS
> vs a max of 16K.
> >
> > Related to this, Branimir wrote CASSANDRA-20092 [3], which
> significantly improves compaction by avoiding reading the partition index.
> CASSANDRA-20092 has been merged to trunk already [4].
> >
> > I think we should merge both of these patches into 5.0, as the perf
> improvement should allow teams to increase density of EBS backed C*
> clusters by 2-5x, driving cost way down.  There's a lot of teams running 
> C*
> on EBS now.  I'm currently working with one that's bottlenecked on maxed
> out EBS GP3 storage.  I propose we merge both, because without
> CASSANDRA-20092, we won't get the performance improvements in
> CASSANDRA-15452 with BTI, only BIG format.  I've tested BTI in other
> situations and found it to be far more performant than BIG.
> >
> > If we were looking at a small win, I wouldn't care much, but since
> these patches, combined with UCS, allows more teams to run C* on EBS at >
> 10TB / node, I think it's worth doing now.
> >
> > Thanks in advance,
> > Jon
> >
> > [1] https://issue

Re: Welcome Jeremiah Jordan to the PMC

[Tolbert, Andy]

Congrats JD!

On Fri, Feb 14, 2025 at 4:13 PM  wrote:

> Congratulations, well deserved!
>
> El 14 feb 2025, a las 20:40, Alex Petrov  escribió:
>
> 
> Congratulations!
>
> On Fri, Feb 14, 2025, at 7:33 PM, Josh McKenzie wrote:
>
> Congrats Jeremiah!
>
> I know you're excited to have yet another email list to attend to, aren't
> you? :D
>
> On Fri, Feb 14, 2025, at 1:29 PM, Jeremiah Jordan wrote:
>
> Thanks all!  Excited to continue being a part of the project in this new
> role.
>
> -Jeremiah Jordan
>
> On Feb 14, 2025 at 12:23:17 PM, Francisco Guerrero 
> wrote:
>
> Congrats!
>
> On 2025/02/14 18:20:02 Yifan Cai wrote:
>
> Congrats!
>
>
> On Fri, Feb 14, 2025 at 10:16 AM Jordan West  wrote:
>
>
> > Congrats, JD! Welcome aboard!
>
> >
>
> > Jordan
>
> >
>
> > On Fri, Feb 14, 2025 at 11:01 Mick Semb Wever  wrote:
>
> >
>
> >>.
>
> >>
>
> >> > I hope you will join me in welcoming him to the committee.
>
> >>
>
> >>
>
> >> Welcome JD!
>
> >>
>
> >
>
>
>
>
>

Re: Welcome Jaydeepkumar Chovatia as Cassandra committer

[Tolbert, Andy]

Congrats Jaydeep!

On Wed, Apr 30, 2025 at 8:57 AM Chris Lohfink  wrote:

> congratulations!
>
> On Wed, Apr 30, 2025 at 8:24 AM Joseph Lynch 
> wrote:
>
>> Congratulations Jaydeep!
>>
>> On Wed, Apr 30, 2025 at 9:19 AM Bernardo Botella <
>> conta...@bernardobotella.com> wrote:
>>
>>> More great news!
>>>
>>> Congratulations Jaydeep!
>>>
>>> On Apr 30, 2025, at 6:11 AM, Jon Haddad  wrote:
>>>
>>> Congrats!!
>>>
>>>
>>>
>>> On Wed, Apr 30, 2025 at 6:07 AM Mick Semb Wever  wrote:
>>>
 Congrats!

 On Wed, 30 Apr 2025 at 13:44, Josh McKenzie 
 wrote:

> Hey there Cassandra Devs!
>
> The Apache Cassandra PMC is very happy to announce that Jaydeep
> Chovatia has
> accepted the invitation to become a committer!
>
> Jaydeep has been busy on Cassandra for a good while now, most recently
> spearheading the contribution of automated repair scheduling via
> CEP-37
> 
>  and CASSANDRA-19918
> .
>
> Please join us in congratulating and welcoming Jaydeep.
>
> Josh McKenzie on behalf of the Apache Cassandra PMC
>

>>>

Re: Welcome Aaron Ploetz as Cassandra Committer

[Tolbert, Andy]

Congrats Aaron!

On Tue, Mar 4, 2025 at 11:24 AM Francisco Guerrero 
wrote:

> Congratulations Aaron!
>
> On 2025/03/04 00:23:49 Patrick McFadin wrote:
> > The Apache Cassandra PMC is very happy to announce that Aaron Ploetz has
> > accepted the invitation to become a committer!
> >
> > Aaron has been tireless in his mission to help every single Cassandra
> > operator on planet Earth. If you don't believe me, check out his Stack
> > Overflow profile page: https://stackoverflow.com/users/1054558/aaron
> > He's been a continuous speaker on Cassandra topics and is one of the
> > coordinators for the Planet Cassandra meetup. Those are just the
> > recent highlights.
> >
> > Please join us in congratulating and welcoming Aaron.
> >
> > The Apache Cassandra PMC members
> >
>

Re: Welcome Bernardo Botella as Cassandra Committer

[Tolbert, Andy]

Congrats Bernardo!!

On Tue, Mar 4, 2025 at 11:25 AM Francisco Guerrero 
wrote:

> Congratulations Bernardo! Well deserved.
>
> On 2025/03/04 07:30:06 Štefan Miklošovič wrote:
> > The Project Management Committee (PMC) for Apache Cassandra has invited
> > Bernardo Botella to become a committer and we are pleased to announce
> that
> > he has accepted.
> >
> > Please join us in welcoming Bernardo Botella to his new role and
> > responsibility in our project community.
> >
> > Stefan Miklosovic
> >
> > On behalf of the Apache Cassandra PMC
> >
>

Re: Welcome Ekaterina Dimitrova as Cassandra PMC member

[Tolbert, Andy]

Congratulations Ekaterina!!

On Wed, Mar 5, 2025 at 8:52 PM Jordan West  wrote:

> Congratulations!!!
> On Wed, Mar 5, 2025 at 07:01 Abe Ratnofsky  wrote:
>
>> Congratulations Ekaterina! 🎉
>>
>

Re: [Discuss] Decoupling java driver dependency from server code; migrate tools and tests to 4.x driver

[Tolbert, Andy]

Thanks Abe!  I had a bit of a blind spot in checking for prior tickets.  It
was good to look at the discussion on CASSANDRA-15750
.

> Out of curiosity - why do you prefer tests move towards 4.x driver vs.
in-tree SimpleClient

Great call out, I think we should definitely evaluate whether SimpleClient
could be used in place of a full driver implementation.  If its not too
difficult to implement functionality the driver provides that we need for
tests, it may be worth it.

On the other hand, now that the driver is now an Apache project and that it
would no longer be a core server dependency makes it more justifiable to
use if its just for test and tools.

In any case, it's something we should look at before we get to the point of
porting test code to the 4.x driver.

Andy


On Thu, Feb 13, 2025 at 2:06 PM Abe Ratnofsky  wrote:

> Thanks for opening this discussion Andy. I'm also supportive of the plan
> you've proposed.
>
> Pushback from past discussion was mostly due to the 4.0 stabilization
> effort. Since then, cassandra-java-driver has been donated to ASF and
> driver 4.x has had a number of releases, so it feels like the right time to
> update.
>
> CASSANDRA-15750
> CASSANDRA-17231
>
> As far as I know, it's safe for the two drivers to co-exist on the same
> classpath as well.
>
> Out of curiosity - why do you prefer tests move towards 4.x driver vs.
> in-tree SimpleClient? We're already using SimpleClient in tests, and it's
> in-tree so we don't need to be concerned with API compatibility or leakage.
> We'd probably have to add some convenience APIs, like binding to prepared
> statements, to make the transition easier.
>

Re: [Discuss] Decoupling java driver dependency from server code; migrate tools and tests to 4.x driver

[Tolbert, Andy]

Hi All,

I went ahead and started an epic to track the work here:
https://issues.apache.org/jira/browse/CASSANDRA-20326

Initially the focus will be on removing the driver as a dependency of
core server code.  Once that has been achieved we can start working on
migrating tooling and test code to the 4.x driver.

Thanks,
Andy


On Wed, Feb 12, 2025 at 8:40 PM Tolbert, Andy  wrote:
>
> Jon
>
> > We can probably skip cassandra-stress, since it looks like easy-cass-stress 
> > can be donated.  That does need a driver upgrade to support a vector 
> > workload, but imo there's no point in investing more in cassandra-stress 
> > when we have an alternative with more features available.  Not a hill I'm 
> > going to die on, just an opportunity to do less work.
>
> That sounds great!   I think it's likely that we can manage separate 
> classpaths for the various tools, so we could update the driver dependency in 
> fqltool and cassandra-loader in the meantime and leave cassandra-stress as is 
> if it is going to be superseded.
>
> JD,
>
> > For the tests, maybe we can have two test class paths for a while?  One for 
> > driver 3 and one for driver 4?  That way we don’t need to migrate them all 
> > in a giant big bang patch?  They could be moved over a few at a time making 
> > review much easier.
>
> I'll explore if this is possible as I think that could potentially work and 
> be more manageable.  I can also evaluate whether its possible for the two 
> drivers to co-exist on the same classpath (I think that may be the case, but 
> I'm not certain).
>
> Thanks,
> Andy
>
>
> On Wed, Feb 12, 2025 at 6:59 PM J. D. Jordan  
> wrote:
>>
>> Sounds like a reasonable plan to me. +1
>>
>> For the tests, maybe we can have two test class paths for a while?  One for 
>> driver 3 and one for driver 4?  That way we don’t need to migrate them all 
>> in a giant big bang patch?  They could be moved over a few at a time making 
>> review much easier.
>>
>> On Feb 12, 2025, at 6:35 PM, Jon Haddad  wrote:
>>
>> 
>> Hey Andy,
>>
>> This seems like a reasonable proposal.
>>
>> We can probably skip cassandra-stress, since it looks like easy-cass-stress 
>> can be donated.  That does need a driver upgrade to support a vector 
>> workload, but imo there's no point in investing more in cassandra-stress 
>> when we have an alternative with more features available.  Not a hill I'm 
>> going to die on, just an opportunity to do less work.
>>
>> Jon
>>
>>
>>
>>
>> On Wed, Feb 12, 2025 at 3:06 PM Tolbert, Andy  wrote:
>>>
>>> Hi All,
>>>
>>> I'd like to propose decoupling the java driver as a dependency from the core
>>> Cassandra server code.
>>>
>>> I also want to propose a path towards eventually migrating test and tools 
>>> code
>>> from Apache Cassandra java driver 3.x to 4.x when the time is right for the
>>> project.
>>>
>>> Refactoring test code to 4.x is likely to be quite invasive, as I count
>>> 128 source files utilizing driver code.  We'd want to find a good time to do
>>> this to minimize disruption to ongoing development.
>>>
>>> Java driver 4.x is effectively a rewrite of the 3.x driver.  Its first 
>>> release
>>> was in March of 2019. While it has similar APIs, it is not binary compatible
>>> with the 3.x driver [1].
>>>
>>> While there hasn't been a clear decision on how the 3.x driver will be
>>> supported going forward (although we should consider discussing this!), we
>>> expect and have seen active development take place mostly exclusively
>>> on the 4.x driver.
>>>
>>> It would be useful to migrate to the 4.x driver to test new and future 
>>> features
>>> of which the 4.x driver will actively support.  For example, the 4.x driver
>>> supports Vector types, where the 3.x driver does not.
>>>
>>> I've iterated the codebase and identified the following uses of the driver:
>>>
>>> 0. Core code that uses the driver
>>>
>>> * UntypedResultSet uses CodecUtils.fromUnsignedToSignedInt from the driver
>>>   which is just adding Integer.MIN_VALUE to an int so can easily be removed.
>>> * PreparedStatementHelper is used only by dtest fuzz tests to validate
>>>   Prepared Statements.  Can be moved to test code.
>>> * ThreadAwareSecurityManager.checkPermission makes reference to skipping
>>>   checking accessDeclaredMembers due to 

[Discuss] Decoupling java driver dependency from server code; migrate tools and tests to 4.x driver

[Tolbert, Andy]

Hi All,

I'd like to propose decoupling the java driver as a dependency from the core
Cassandra server code.

I also want to propose a path towards eventually migrating test and tools code
from Apache Cassandra java driver 3.x to 4.x when the time is right for the
project.

Refactoring test code to 4.x is likely to be quite invasive, as I count
128 source files utilizing driver code.  We'd want to find a good time to do
this to minimize disruption to ongoing development.

Java driver 4.x is effectively a rewrite of the 3.x driver.  Its first release
was in March of 2019. While it has similar APIs, it is not binary compatible
with the 3.x driver [1].

While there hasn't been a clear decision on how the 3.x driver will be
supported going forward (although we should consider discussing this!), we
expect and have seen active development take place mostly exclusively
on the 4.x driver.

It would be useful to migrate to the 4.x driver to test new and future features
of which the 4.x driver will actively support.  For example, the 4.x driver
supports Vector types, where the 3.x driver does not.

I've iterated the codebase and identified the following uses of the driver:

0. Core code that uses the driver

* UntypedResultSet uses CodecUtils.fromUnsignedToSignedInt from the driver
  which is just adding Integer.MIN_VALUE to an int so can easily be removed.
* PreparedStatementHelper is used only by dtest fuzz tests to validate
  Prepared Statements.  Can be moved to test code.
* ThreadAwareSecurityManager.checkPermission makes reference to skipping
  checking accessDeclaredMembers due to use of CodecUtils, can probably remove
  that with its use removed.
* sstableloader uses the driver to fetch schema and metadata

1. Tools that use the driver

* fqltool replay (replaying queries from captured logs)
* cassandra-stress (making queries to generate load)

2. Test code

* Understandably, quite a bit of test code uses the driver. This is where I
  anticipate the most work would be be needed.

I'd like to propose doing the following:

Can be done now:

* Move sstableloader source into its own tools directly, much like fqltool
  and cassandra-stress.  For compatibility, we could retain the existing shell
  script entry point (bin/sstableloader).
* Update remaining core code to remove all use of the driver.  As shown above,
  there is not much to change here and this should be relatively easy to
  accomplish.
* Update the build and scripts to establish separate classpaths for the server
  and the respective tools.  We would exclude the driver and its dependencies
  (that aren't required otherwise) from the server.  The driver would still be
  included in the built package, so this wouldn't reduce the size of the
  binary, but it would remove the driver from the server's classpath, which
  would de-risk upgrading the driver and having it or its dependencies cause
  possible runtime issues.

To be done next:

* Refactor sstableloader, fqltool and cassandra-stress to use the 4.x driver.

To be done when the timing works for the project:

* Refactor tests to use the 4.x driver.

Hopefully this proposed approach makes sense, I'd be eager to hear any
feedback or suggestions!

Thanks,
Andy

[1]: 
https://docs.datastax.com/en/developer/java-driver/4.17/upgrade_guide/index.html#4-0-0

Re: New committers: Maxwell Guo and Dmitry Konstantinov

[Tolbert, Andy]

Congrats Maxwell and Dmitry!!

On Fri, Feb 21, 2025 at 9:11 AM Josh McKenzie  wrote:

> Congratulations to you both; glad to have you as part of the community.
>
> On Fri, Feb 21, 2025, at 1:36 AM, Berenguer Blasi wrote:
>
> Congrats!
> On 20/2/25 21:29, Jeremiah Jordan wrote:
>
> Congrats to both of you!  Thank you for the contributions you have been
> making to the project!
>
> On Feb 20, 2025 at 11:47:05 AM, Štefan Miklošovič 
> wrote:
>
> The Project Management Committee (PMC) for Apache Cassandra
> has invited Maxwell Guo and Dmitry Konstantinov to become committers and
> we are pleased
> to announce that they have accepted.
>
> Please join us in welcoming Maxwell Guo and Dmitry Konstantinov to their
> new role and
> responsibility in our project community.
>
> Stefan Miklosovic
>
> On behalf of the Apache Cassandra PMC
>
>
>

Re: Welcome Caleb Rackliffe to the PMC

[Tolbert, Andy]

Congrats Caleb!

On Fri, Feb 21, 2025 at 9:12 AM Josh McKenzie  wrote:

> Congratulations Caleb!
>
> On Fri, Feb 21, 2025, at 10:02 AM, Jacek Lewandowski wrote:
>
> Congratulations Caleb!!!
>
>
> - - -- --- -  -
> Jacek Lewandowski
>
>
> pt., 21 lut 2025 o 15:56 Jeremy Hanna 
> napisał(a):
>
> Congratulations Caleb.  Thank you for all of your contribution and work on
> the project.
>
> > On Feb 20, 2025, at 4:06 PM, Jon Haddad  wrote:
> >
> > The PMC for Apache Cassandra is delighted to announce that Caleb
> Rackliffe has joined it's membership!
> >
> > Caleb has been a member of the community for 10 years and is one of the
> most active committers on the project.
> >
> > Please join us in welcoming Caleb to his new role!
> >
> > Jon
> > On behalf of the Cassandra PMC
> >
> >
>
>
>

Re: Welcome Abe Ratnofsky as Cassandra committer!

[Tolbert, Andy]

Congratulations Abe!

On Mon, May 12, 2025 at 11:59 AM Dmitry Konstantinov 
wrote:

> Congrats Abe!
>
> On Mon, 12 May 2025 at 17:46, Alex Petrov  wrote:
>
>> Hello folks of the dev list,
>>
>> The Apache Cassandra PMC is very glad to announce that Abe Ratnofsky has
>> accepted our invitation to become a committer!
>>
>> Abe has been actively contributing to Cassandra itself, made outstanding
>> contributions to the Cassandra drivers, played a key role in the recently
>> accepted CEP-45 [1], and has been active in the community — including on
>> this mailing list and on Cassandra conferences and meetups.
>>
>> Please join us in congratulating and welcoming Abe!
>>
>> Alex Petrov
>> on behalf of the Apache Cassandra PMC
>> [1]
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking
>>
>>
>
>
> --
> Dmitry Konstantinov
>