Re: Cassandra 5+ JDK Minimum Compatibility Requirement

Made some progress. After adding throughout build.xml and compiling the 5.03 branch with openjdk 17.0.15 2025-04-15 OpenJDK Runtime Environment Temurin-17.0.15+6 (build 17.0.15+6) I got a build Failed error at the same position in exception. Please see: https://github.com/apache/cassandra/pull/415

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

I’ve added a new section on isolation and consistency . In our current design, materialized-view tables stay eventually consistent,

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> The MV repair tool in Cassandra is intended to address inconsistencies that > may occur in materialized views due to various factors. This component is the > most complex and demanding part of the development effort, representing > roughly 70% of the overall work. > but I am very concerned ab

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

We thought we had this figured out when we did the big bang switch to ByteBuffers, then spent years finding subtle bugs that the tests didn't. Kind Regards, Brandon On Fri, May 9, 2025 at 3:24 PM Jon Haddad wrote: > > There’s a pretty simple solution here - breaking it up into several smaller >

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

There’s a pretty simple solution here - breaking it up into several smaller patches. * Any changes should include tests that validate the checks are used correctly. * It should also alleviate any issues with code conflicts and rebasing as the merges would happen slowly over time rather than all at

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> On May 9, 2025, at 12:59 PM, Ariel Weisberg wrote: > > > I am *big* fan of getting repair really working with MVs. It does seem > problematic that the number of merkle trees will be equal to the number of > ranges in the cluster and repair of MVs would become an all node operation. > How

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

Hi, Planning to call a vote on Monday since there don't seem to be any major concerns. Ariel On Tue, May 6, 2025, at 4:32 PM, Bernardo Botella wrote: > +1 (nb) > >> On May 6, 2025, at 1:19 PM, Josh McKenzie wrote: >> >> +1 >> >> On Tue, May 6, 2025, at 4:06 PM, Yifan Cai wrote: >>> +1 (nb)

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

Hi, Great to see MVs getting some attention and it's a good time to start addressing their shortcomings. Looking at the details of the CEP it seems to describe Paxos as PaxosV1, but PaxosV2 works slightly differently (it can read during the prepare phase). I assume that supporting Paxos means

Fwd: Cassandra 5 JDK21 Command Line actions

Hello, I've talked to ZGC members of the OpenJDK community on GC strategies. Wanted to share this information with Cassandra devs. Thanks, Vivekanand -- Forwarded message - From: Stefan Johansson Date: Fri, May 9, 2025, 2:00 AM Subject: Re: Cassandra 5 JDK21 Command Line actions

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

My thinking is most closely aligned with Blake and Benedict’s views here.For the specific refactor in question, I support adoption of the language feature for new code or to cut existing code over to the new syntax as changes are made to the respective areas of the codebase. But I don’t support a s

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

No one is treating the codebase like a house of cards that can’t be touched. In this case I think the cost/risk of doing this change outweighs the potential benefits the project might see from it. Josh counts ~2000 instances where we’re casting objects so we’re talking about a not-insignificant

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

Agreed. This is a change that’s fine to include when editing related (and new) code, but doesn’t come close to warranting a wide scale change.On 9 May 2025, at 18:32, Blake Eggleston wrote:This seems like a cool feature that will be useful in future development work, but not something we should b

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

Why not? Personally, I hate the idea of treating a codebase (any codebase) like a house of cards that can't be touched. It never made sense to me to try to bundle new features / bug fixes with improvements to code quality. Making the code more reliable should be a goal in itself, rather than a s

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

This seems like a cool feature that will be useful in future development work, but not something we should be proactively refactoring the project to make use of. On Fri, May 9, 2025, at 10:18 AM, Vivekanand Koya wrote: > I would say that https://openjdk.org/jeps/394 (instanceOf) aims to provide

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

I can also provide potential examples if you'd like. Thanks, Vivekanand K. On Fri, May 9, 2025 at 10:18 AM Vivekanand Koya <13vivekk...@gmail.com> wrote: > I would say that https://openjdk.org/jeps/394 (instanceOf) aims to > provide safer and less poisoning in the code by default. Instead of hav

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

I would say that https://openjdk.org/jeps/394 (instanceOf) aims to provide safer and less poisoning in the code by default. Instead of having a production server halt/impaired due to a RuntimeException, instead it is verified at compile time. If a new language feature makes code more robust and add

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

> I would like to refactor the codebase (Trunk 5+) to eliminate unsafe explicit > casting with instanceOf. We have a rich history of broad sweeping refactors dying on the rocks of the community's aversion to instability and risk w/out a concrete outcome we're trying to achieve. :) All of which

Re: [DISCUSS] Replace airlift/airline library with Picocli

Hello everyone, The commands have been migrated to picocli and are ready for review, and we need a second committer to review them. Would anyone be able to help? Key points: - All the commands are backwards-compatible with everything we have in the trunk now (including the accord commands); - The

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

Sounds great. I would like to refactor the codebase (Trunk 5+) to eliminate unsafe explicit casting with instanceOf. Thanks, Vivekanand On Fri, May 9, 2025, 5:19 AM Benedict Elliott Smith wrote: > Yep, that approach seems more than sufficient to me. No need for lots of > ceremony, but good to k

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

Yep, that approach seems more than sufficient to me. No need for lots of ceremony, but good to keep everyone in the decision loop. > On 9 May 2025, at 13:10, Josh McKenzie wrote: > >> I think it doesn’t cost us much to briefly discuss new language features >> before using them. > I had that th

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

I think it doesn’t cost us much to briefly discuss new language features before using them. Lambdas, Streams and var all have problems - and even with the guidance we publish some are still misused. The flow scoping improvement to instanceof seems obviously good though. > On 9 May 2025, at 12:3

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

> I think it doesn’t cost us much to briefly discuss new language features > before using them. I had that thought as well but on balance my intuition was there were enough new features that the volume of discussion to do that would be a poor cost/benefit compared to the "lazy consensus, revert"

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

For new feature work on trunk, targeting the highest supported language level featureset (jdk17 right now, jdk21 within the next couple of weeks) makes sense to me. For bugfixing, targeting the oldest supported GA branch and the highest language level that works there would allow maximum flexibi

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

I should add that I’m in favour of this proposal in principle, and support the proposal to utilise Paxos.On 9 May 2025, at 08:21, Benedict Elliott Smith wrote:I’d also like to explore a bit further the isolation guarantees we’re promising with "Strict Consistency Mode” - and the protocol details.

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

I’d also like to explore a bit further the isolation guarantees we’re promising with "Strict Consistency Mode” - and the protocol details. By strict, do we mean linearizable? Either way, we should state the guarantees explicitly so we can evaluate whether the protocol can meet them. Also, if the