Re: CASSANDRA-20490 Question about broken forced ephemeral snapshots during repair

Aha! That is interesting, I was completely oblivious to that. That most probably explains why we were using the snapshot name as the parent session id upon SNAPSHOT_MSG so we clean it all in one place when dealing with CLEANUP_MSG. All things considered I think that the patch as is in CASSANDRA-20

Re: CASSANDRA-20490 Question about broken forced ephemeral snapshots during repair

>So if we moved to determanisticId for both branches of if / else and remove force, we should be good? RepairJobDesc#deterministicId is basically unique? The challenge with using RepairJobDesc#deterministicId in the SNAPSHOT_MSG is that it will create N snapshots for N token-splits for a table. How

Re: CASSANDRA-20490 Question about broken forced ephemeral snapshots during repair

That true / false for "force" argument seems to be purely derived from whether it is global repair (force set to false) or not (set to true). https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/repair/RepairMessageVerbHandler.java#L185-L192 On Tue, May 13, 2025 at 5:25 PM

Re: CASSANDRA-20490 Question about broken forced ephemeral snapshots during repair

That method can be backported even if it’s just for this single case. For the vtable I needed something more friendly so made this for that. It’s also used for dedup logic in repair retry works.  I didn’t look closely, what sets force to be true or false? I assumed this was the force flag in repair

Re: CASSANDRA-20490 Question about broken forced ephemeral snapshots during repair

David, that "force" you copied from nodetool, that has nothing to do with "force" in these snapshots but I think you already know that. org.apache.cassandra.repair.RepairJobDesc#determanisticId is only in 4.1+ included, not in 4.0. That's quite a bummer but we could limit the patch for 4.1+ only

Re: CASSANDRA-20490 Question about broken forced ephemeral snapshots during repair

> "force" can be true / false. When true, then it will not check if a snapshot > exists My mental node for “force” was only to deal with down nodes, and nothing to do with snapshots… so this feels like a weird behavior @Option(title = "force", name = {"-force", "--force"}, description = "Use

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

> breaking it up into several smaller patches. This immediately made me think of poor Blake and the "remove singletons" sisyphean task. That was 700 smaller patches! :D Which to be fair isn't "several" by any measure, but... All of which is to say - it's a continuum between big-banging it in o

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

It looks like there is a potential solution to the indeterministic bytebuffer: https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemoryLayout.html & https://archive.fosdem.org/2020/schedule/event/bytebuffers/ Thanks, Vivekanand K. On Fri, May 9, 2025, 8:59 PM Vivekan

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: 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: 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: 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: Cassandra Java Driver and OpenJDK CRaC

Hey Radim, thanks for bringing this to the list. In general, I'm supportive of the second option you shared ("Exposing neutral methods") but want to make sure I understand how CRaC would work in practice. Could you clarify this part: > Naturally it is possible to close the session object comple

Re: Cassandra Java Driver and OpenJDK CRaC

Just speaking up as a supporter for considering this change. From a userland perspective, I've been reading up on CRaC, and I see this attacking some of the same requirements that Graal and Quarkus are trying to solve. This is a worth direction to pursue. The CqlSession will need to re-connect, an

Re: Cassandra Java Driver and OpenJDK CRaC

Hi Patrick, > attacking some of the same requirements that Graal and Quarkus are trying to solve thanks for the support! Yes, Graal (and Leyden) are kind of competing solutions for the startup problem. We're trying to hit the sweet spot between not requiring significant redesign (as is somet

Re: Cassandra Java Driver and OpenJDK CRaC

Hi Abe, I would expect that if the control connection is terminated, on the next request it would be re-established including the handshake you mention. This shouldn't be different from a connection being broken due to network error. In the POC PR I am calling just `DriverChannel.close()`, th

Re: Cassandra Java Driver and OpenJDK CRaC

Hello Josh, thanks for reaching back; answers inline: On 10. 03. 25 13:03, Josh McKenzie wrote: From skimming the PR on the Spring side and the conversation there, it looks like the argument is to have this live inside the java driver for Cassandra instead of in the spring-boot lib which I c

Re: Cassandra Java Driver and OpenJDK CRaC

Thanks for reaching out to the list Radim; this is interesting stuff. >From skimming the PR on the Spring side and the conversation there, it looks >like the argument is to have this live inside the java driver for Cassandra >instead of in the spring-boot lib which I can see the argument for. I

Re: Cassandra 5 Upgrade - Storage Compatibility Modes

That sounds like a possibility to me on the surface. Kind Regards, Brandon On Fri, Dec 20, 2024 at 8:42 AM Paul Chandler wrote: > > Hi Brandon, > > That sounds good. Will that fix be in 4.1, as it is the old nodes that don’t > transmit the hints? > > Thanks > > Paul > > > On 20 Dec 2024, at 13:

Re: Cassandra 5 Upgrade - Storage Compatibility Modes

Hi Brandon, That sounds good. Will that fix be in 4.1, as it is the old nodes that don’t transmit the hints? Thanks Paul > On 20 Dec 2024, at 13:41, Brandon Williams wrote: > > I think after a discussion on #cassandra-dev yesterday, we are going > to remove the requirement for schema agree

Re: Cassandra 5 Upgrade - Storage Compatibility Modes

I think after a discussion on #cassandra-dev yesterday, we are going to remove the requirement for schema agreement to deliver hints, as suggested by Jeff Jirsa. Kind Regards, Brandon On Thu, Dec 19, 2024 at 7:43 AM Paul Chandler wrote: > > Hi Brandon, > > I am not sure which part changes after

Re: Cassandra 5 Upgrade - Storage Compatibility Modes

Hi Brandon, I am not sure which part changes after CASSANDRA-20118, there is still the system mismatch going to CASSANDRA_4 caused by the change in system.compaction_history, and going to UPGRADING, this is caused by the 2 different sstable formats, so nothing that CASSANDRA-20118 fixes. So w

Re: Cassandra 5 Upgrade - Storage Compatibility Modes

On Thu, Dec 19, 2024 at 4:11 AM Paul Chandler wrote: > C*4 -> CASSANDRA_4 : There is a schema mismatch, and hints are not sent from > C*4 node to C*5 nodes. > CASSANDRA_4 -> UPGRADING: Repairs are not possible and Nodes cannot be added > or replaced. > UPGRADING-> NONE: No issues. I'll note thi

Re: CASSANDRA-19448 and side effects of removal of precision property in commitlog_archiving.properties

I think what was meant by this A timestamp (typically in microseconds since the unix epoch, although this is not enforced) is that the timestamp can be a "logical" timestamp from some source where the clock just "ticks" from 0 etc ... It does not mean that we could once put there milliseconds, an

Re: CASSANDRA-19835 should block 5.0.0

Merged to 5.0.0 > On Aug 14, 2024, at 2:41 PM, Josh McKenzie wrote: > > This looks like a "merge it to 5.0.0 and re-rev rc" to me. > > On Wed, Aug 14, 2024, at 2:21 PM, David Capwell wrote: >> CASSANDRA-19835 fixes a very small bug but one that has big impact: if you >> use trie Memtable and u

Re: CASSANDRA-19835 should block 5.0.0

This looks like a "merge it to 5.0.0 and re-rev rc" to me. On Wed, Aug 14, 2024, at 2:21 PM, David Capwell wrote: > CASSANDRA-19835 fixes a very small bug but one that has big impact: if you > use trie Memtable and unslabbed_heap_buffers_logged Cassandra will crash on > boot! If you use any oth

Re: CASSANDRA-19779 in 5.0-rc

I am done, the ticket needs another committer though. On Fri, Jul 26, 2024 at 7:00 PM Josh McKenzie wrote: > +1 to should block as well. > > On Fri, Jul 26, 2024, at 12:15 PM, Patrick McFadin wrote: > > This is a weird regression but I'm borderline on this being a blocker. On > a brand new node

Re: CASSANDRA-19779 in 5.0-rc

+1 to should block as well. On Fri, Jul 26, 2024, at 12:15 PM, Patrick McFadin wrote: > This is a weird regression but I'm borderline on this being a blocker. On a > brand new node starting, this comes up but goes away on the first reboot of > the node. What I don't get is why directIO is disabl

Re: CASSANDRA-19779 in 5.0-rc

This is a weird regression but I'm borderline on this being a blocker. On a brand new node starting, this comes up but goes away on the first reboot of the node. What I don't get is why directIO is disabled if there is no commit log. What's specific about that? Patrick On Fri, Jul 26, 2024 at 7:4

Re: CASSANDRA-19779 in 5.0-rc

+1 Should block > On Jul 26, 2024, at 8:25 AM, Štefan Miklošovič wrote: > >  > I am formally asking for acknowledging (1) to be a blocker for 5.0-rc. I > think it was introduced in (2) and it behaves like this (3). > > Regards > > (1) https://issues.apache.org/jira/browse/CASSANDRA-19779 >

Re: [CASSANDRA-19651][Review] idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied

Hi, I'll take a look. Thanks! Ariel On Wed, Jul 10, 2024, at 7:18 AM, Dmitry Konstantinov wrote: > Hello All, > > I recently submitted a patch what addresses a bug in idealCLWriteLatency > metric calculation: https://issues.apache.org/jira/browse/CASSANDRA-19651 > > Could someone help with re

Re: Cassandra PMC Chair Rotation, 2024 Edition

Thank you Josh; hearty congratulations Dinesh! On Wed, Jun 26, 2024 at 11:40 AM Vinay Chella via dev < dev@cassandra.apache.org> wrote: > Congratulations Dinesh!! Thank you Josh > Thanks, > Vinay > > > On Wed, Jun 26, 2024 at 10:49 PM Venkata Hari Krishna Nukala < > n.v.harikrishna.apa...@gmail.c

Re: Cassandra PMC Chair Rotation, 2024 Edition

Congratulations Dinesh!! Thank you Josh Thanks, Vinay On Wed, Jun 26, 2024 at 10:49 PM Venkata Hari Krishna Nukala < n.v.harikrishna.apa...@gmail.com> wrote: > Congratulations Dinesh!! > > On Fri, Jun 21, 2024 at 6:47 PM Paulo Motta wrote: > >> Thank you Josh and congratulations Dinesh! >> >> O

Re: Cassandra PMC Chair Rotation, 2024 Edition

Congratulations Dinesh!! On Fri, Jun 21, 2024 at 6:47 PM Paulo Motta wrote: > Thank you Josh and congratulations Dinesh! > > On Thu, 20 Jun 2024 at 11:52 Josh McKenzie wrote: > >> Another PMC Chair baton pass incoming! On behalf of the Apache Cassandra >> Project Management Committee (PMC) I wo

Re: Cassandra PMC Chair Rotation, 2024 Edition

Thank you Josh and congratulations Dinesh! On Thu, 20 Jun 2024 at 11:52 Josh McKenzie 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). > > Di

Re: Cassandra PMC Chair Rotation, 2024 Edition

Thanks for being willing to serve in this capacity. Thanks also to Josh for doing a lot of this behind the scenes work this past year. > On Jun 20, 2024, at 11:22 PM, Maxim Muzafarov wrote: > > Congratulations Dinesh! > >> On Fri, 21 Jun 2024 at 05:12, Abhijeet Dubey >> wrote: >> >> Thank

Re: Cassandra PMC Chair Rotation, 2024 Edition

Congratulations Dinesh! On Fri, 21 Jun 2024 at 05:12, Abhijeet Dubey wrote: > > Thank you Josh for the amazing work. > > Congrats, Dinesh. Welcome to the new role :) > > Regards, > Abhijeet > > On Fri, Jun 21, 2024 at 4:09 AM Dinesh Joshi wrote: >> >> Thank you everybody. I hope to do my best in

Re: Cassandra PMC Chair Rotation, 2024 Edition

Thank you Josh for the amazing work. Congrats, Dinesh. Welcome to the new role :) Regards, Abhijeet On Fri, Jun 21, 2024 at 4:09 AM Dinesh Joshi wrote: > Thank you everybody. I hope to do my best in this role. A big thanks to > Josh who has been a great PMC Chair! > > On Thu, Jun 20, 2024 at 1

Re: Cassandra PMC Chair Rotation, 2024 Edition

Thank you everybody. I hope to do my best in this role. A big thanks to Josh who has been a great PMC Chair! On Thu, Jun 20, 2024 at 11:40 AM Yifan Cai wrote: > Thank you for the service, Josh! > Congrats, Dinesh! > > On Thu, Jun 20, 2024 at 11:32 AM Jean-Armel Luce > wrote: > >> Josh, thanks f

Re: Cassandra PMC Chair Rotation, 2024 Edition

Thank you Josh for being an amazing VP. The past year has been very transformative for the project and you've done a ton of critical work behind the scenes that few know about. Welcome Dinesh! On Thu, 20 Jun 2024 at 17:53, Josh McKenzie wrote: > Another PMC Chair baton pass incoming! On beha

Re: Cassandra PMC Chair Rotation, 2024 Edition

Congratulations!!! - - -- --- - - Jacek Lewandowski czw., 20 cze 2024 o 21:00 lorinapoland napisał(a): > Congrats, Dinesh! > > > > Sent from my Verizon, Samsung Galaxy smartphone > > > Original message > From: Josh McKenzie > Date: 6/20/24 08:51 (GM

RE: Cassandra PMC Chair Rotation, 2024 Edition

Congrats, Dinesh!Sent from my Verizon, Samsung Galaxy smartphone Original message From: Josh McKenzie Date: 6/20/24 08:51 (GMT-08:00) To: dev Subject: Cassandra PMC Chair Rotation, 2024 Edition Another PMC Chair baton pass incoming! On behalf of the Apache Cassandra Project

Re: Cassandra PMC Chair Rotation, 2024 Edition

Thank you for the service, Josh! Congrats, Dinesh! On Thu, Jun 20, 2024 at 11:32 AM Jean-Armel Luce wrote: > Josh, thanks for the job > Dinesh, congrats!! > > Le jeu. 20 juin 2024 à 19:42, David Capwell a écrit : > >> Congrats! >> >> On Jun 20, 2024, at 9:10 AM, Melissa Logan wrote: >> >> Josh

Re: Cassandra PMC Chair Rotation, 2024 Edition

Josh, thanks for the job Dinesh, congrats!! Le jeu. 20 juin 2024 à 19:42, David Capwell a écrit : > 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 wrote: > >> Congra

Re: Cassandra PMC Chair Rotation, 2024 Edition

🎉 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! A

Re: Cassandra PMC Chair Rotation, 2024 Edition

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 Xav

Re: Cassandra PMC Chair Rotation, 2024 Edition

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 F

Re: Cassandra PMC Chair Rotation, 2024 Edition

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: > >

Re: Cassandra PMC Chair Rotation, 2024 Edition

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, 202

Re: Cassandra PMC Chair Rotation, 2024 Edition

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 > wrote: >> Congrats Dinesh! Thank you Josh! >> >>> On Jun 20, 2024, at 11:53 AM, Jeremiah Jordan

Re: Cassandra PMC Chair Rotation, 2024 Edition

Josh, thank you for your time as chair + congrats Dinesh! On Thu, Jun 20, 2024 at 9:08 AM Abe Ratnofsky wrote: > Congrats Dinesh! Thank you Josh! > > On Jun 20, 2024, at 11:53 AM, Jeremiah Jordan > wrote: > > Welcome to the Chair role Dinesh! Congrats! > > On Jun 20, 2024 at 10:50:37 AM, Josh

Re: Cassandra PMC Chair Rotation, 2024 Edition

Congratulations, Dinesh! On Thu, Jun 20, 2024 at 10:51 AM Josh McKenzie 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

Re: Cassandra PMC Chair Rotation, 2024 Edition

Congrats Dinesh! Thank you Josh! > On Jun 20, 2024, at 11:53 AM, Jeremiah Jordan > wrote: > > Welcome to the Chair role Dinesh! Congrats! > > On Jun 20, 2024 at 10:50:37 AM, Josh McKenzie > wrote: >> Another PMC Chair baton pass incoming! On behalf of the Apache

Re: Cassandra PMC Chair Rotation, 2024 Edition

Welcome to the Chair role Dinesh! Congrats! On Jun 20, 2024 at 10:50:37 AM, Josh McKenzie 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).

RE: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators

: Dinesh Joshi Sent: Tuesday, January 23, 2024 10:36 PM To: dev@cassandra.apache.org Subject: Re: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators Hi Shylaja, If you'd like we can continue this on the ticket you opened. Here are my concerns - 1. QPL Java

Re: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators

limitation. > > > > Thank you, > > Shylaja > > > > *From:* Dinesh Joshi > *Sent:* Monday, January 22, 2024 11:18 AM > *To:* dev@cassandra.apache.org > *Subject:* Re: CASSANDRA-19268: Improve Cassandra compression performance > using hardware accelerators > >

RE: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators

y to come up with a solution to work around the 4k window limitation. Thank you, Shylaja From: Dinesh Joshi Sent: Monday, January 22, 2024 11:18 AM To: dev@cassandra.apache.org Subject: Re: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators Shylaja, Cassa

Re: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators

Shylaja, Cassandra uses ZStd, LZ4 and other compression libraries via JNI to compress data. The intel hardware accelerator support is integrated into those libraries and we can benefit from it. If there are special parameters that need to be passed in to these libraries we can make those changes o

Re: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators

Hardware acceleration for more things would be great, especially based on the success of ACCP (CASSANDRA-18624 ). But I think it would be ideal to use existing compressor names and use hardware acceleration if a given JAR is present on the

Re: CASSANDRA-18775 (Cassandra supported OSs)

I closed 18775 as it did not seem reasonable after discussions here. I have been working on 16565 and have a pull request [1] and an experimental suite to show the differences. [2] [1] https://github.com/apache/cassandra/pull/2842 [2] https://github.com/Aiven-Labs/compare_oshi_sigar On Wed, Oc

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

Thanks everyone! I have updated CASSANDRA-18941 with PRs to each branch, i.e. cassandra-4.0, cassandra-4.1, cassandra-5.0 and cassandra-trunk. - Yifan On Wed, Oct 25, 2023 at 7:00 AM Doug Rohrer wrote: > +1 (nb) - wiłl be nice for the analytics writer to be able to size > SSTables appropriately

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

+1 (nb) - wiłl be nice for the analytics writer to be able to size SSTables appropriately and efficiently. Doug > On Oct 24, 2023, at 10:36 PM, guo Maxwell wrote: > > 😄 > > Chris Lohfink mailto:clohfin...@gmail.com>> > 于2023年10月25日周三 05:02写道： >> +1 >> >> On Tue, Oct 24, 2023 at 11:24 AM Bra

Re: CASSANDRA-18775 (Cassandra supported OSs)

+1 to drop if we're not using. On Fri, Oct 20, 2023, at 6:58 PM, Ekaterina Dimitrova wrote: > +1 on removal the whole lib if we are sure we don’t need it. Nothing better > than some healthy house cleaning > > -1 on partial removals > > On Fri, 20 Oct 2023 at 17:34, David Capwell wrote: >> +1

Re: CASSANDRA-16565

I ended up posting the code at https://github.com/Aiven-Labs/compare_oshi_sigar if anyone wants to take a look and see if they get differing results on various systems. On Tue, Oct 24, 2023 at 4:59 PM Brandon Williams wrote: > On Tue, Oct 24, 2023 at 7:48 AM Claude Warren, Jr via dev > wrote: >

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

😄 Chris Lohfink 于2023年10月25日周三 05:02写道： > +1 > > On Tue, Oct 24, 2023 at 11:24 AM Brandon Williams > wrote: > >> +1 >> >> Kind Regards, >> Brandon >> >> On Mon, Oct 23, 2023 at 6:22 PM Yifan Cai wrote: >> > >> > Hi, >> > >> > I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

+1 On Tue, Oct 24, 2023 at 11:24 AM Brandon Williams wrote: > +1 > > Kind Regards, > Brandon > > On Mon, Oct 23, 2023 at 6:22 PM Yifan Cai wrote: > > > > Hi, > > > > I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up to > trunk and hope we are all OK with it. > > > > In CASSAN

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

+1 Kind Regards, Brandon On Mon, Oct 23, 2023 at 6:22 PM Yifan Cai wrote: > > Hi, > > I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up to trunk > and hope we are all OK with it. > > In CASSANDRA-18941, I am adding the capability to produce size-bounded > SSTables in CQLSSTa

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

I understood that the intention is for this to land in 4.0 all the way up to trunk (including 4.1 and 5.0). On 2023/10/24 02:19:41 guo Maxwell wrote: > +1, but I want to know why only trunk and 4.0 ? not all the versions > involved, like 4.1 ,5.0 。 > > Francisco Guerrero 于2023年10月24日周二 07:47写道：

Re: CASSANDRA-16565

On Tue, Oct 24, 2023 at 7:48 AM Claude Warren, Jr via dev wrote: > > Is there someplace I can stash the tgz that others can download it from? The > file info is : 6269066 okt 24 12:46 compare_oshi_sigar.tgz Is posting a github branch not sufficient?

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

> to 4.0 and up to trunk Think the proposal is all supported branches from 4.0 up. +1 here. On Mon, Oct 23, 2023, at 10:19 PM, guo Maxwell wrote: > +1, but I want to know why only trunk and 4.0 ? not all the versions > involved, like 4.1 ,5.0 。 > > Francisco Guerrero 于2023年10月24日周二 07:47写道： >>

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

+1, but I want to know why only trunk and 4.0 ? not all the versions involved, like 4.1 ,5.0 。 Francisco Guerrero 于2023年10月24日周二 07:47写道： > +1 (nb). I think this is a great addition to offline tools that use > SSTable writer in general. > > On 2023/10/23 23:21:13 Yifan Cai wrote: > > Hi, > > > >

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

+1 (nb). I think this is a great addition to offline tools that use SSTable writer in general. On 2023/10/23 23:21:13 Yifan Cai wrote: > Hi, > > I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up to > trunk and hope we are all OK with it. > > In CASSANDRA-18941, I am adding th

Re: CASSANDRA-18775 (Cassandra supported OSs)

+1 on removal the whole lib if we are sure we don’t need it. Nothing better than some healthy house cleaning -1 on partial removals On Fri, 20 Oct 2023 at 17:34, David Capwell wrote: > +1 to drop the whole lib… > > > On Oct 20, 2023, at 7:55 AM, Jeremiah Jordan > wrote: > > Agreed. -1 on sel

Re: CASSANDRA-18775 (Cassandra supported OSs)

+1 to drop the whole lib… > On Oct 20, 2023, at 7:55 AM, Jeremiah Jordan > wrote: > > Agreed. -1 on selectively removing any of the libs. But +1 for removing the > whole thing if it is no longer used. > > -Jeremiah > > On Oct 20, 2023 at 9:28:55 AM, Mick Semb Wever

Re: CASSANDRA-18775 (Cassandra supported OSs)

Agreed. -1 on selectively removing any of the libs. But +1 for removing the whole thing if it is no longer used. -Jeremiah On Oct 20, 2023 at 9:28:55 AM, Mick Semb Wever wrote: > Does anyone see any reason _not_ to do this? >> > > > Thanks for bring this to dev@ > > I see reason not to do it

Re: CASSANDRA-18775 (Cassandra supported OSs)

> > Does anyone see any reason _not_ to do this? > Thanks for bring this to dev@ I see reason not to do it, folk do submit patches for other archs despite us not formally maintaining and testing the code for those archs. Some examples are PPC64 Big Endian (CASSANDRA-7476), s390x (CASSANDRA-1772

Re: CASSANDRA-18775 (Cassandra supported OSs)

As noted on CASSANDRA-16565 we don't actually need sigar for anything, so I don't see a reason to keep any of it, especially if that is going to force us to specify OSes. Kind Regards, Brandon On Fri, Oct 20, 2023 at 9:04 AM Claude Warren, Jr via dev wrote: > > I am looking at https://issues.apa

Re: CASSANDRA-18773 compaction speedup

> As mentioned, we plan to merge this to 4.0, 4.1, 5.0 and trunk. > If this is merging up from 4.0, I see no reason not to include it in 5.0.

Re: CASSANDRA-18773 compaction speedup

Hello Stefan, +1 Do we plan to release these changes? I am mostly interested in using 4.0, 4.1 :-) On Tue, 26 Sept 2023 at 17:49, Miklosovic, Stefan wrote: > > Hi list, > > there is CASSANDRA-18773 we want to merge to 4.0 up to trunk (hence it will > be in 5.0 (alpha2)) and I want to be sure we

Re: Cassandra Sidecar CI is now green!

Thanks Francisco, Mick and Yifan for making this happen! > On Jul 20, 2023, at 4:00 PM, Francisco Guerrero wrote: > > Hi list, > > I wanted to bring some visibility into the Cassandra Sidecar CI health [1]. > It seems like it has been broken for quite a while and we have finally fixed > it toda

Re: Cassandra Sidecar CI is now green!

I'm happy to help in any way I can with other subprojects! - Francisco On 2023/07/21 04:59:50 Mick Semb Wever wrote: > Thank you everyone that was involved. > There's a lot to do with sub-projects, I'm sure the folk who will be > working with the drivers subproject will want to learn a lot from y

Re: Cassandra Sidecar CI is now green!

Thank you everyone that was involved. There's a lot to do with sub-projects, I'm sure the folk who will be working with the drivers subproject will want to learn a lot from you. On Fri, 21 Jul 2023 at 01:11, Yifan Cai wrote: > Thank you for fixing the build on ci-cassandra! I am glad that I can

Re: Cassandra Sidecar CI is now green!

Thank you for fixing the build on ci-cassandra! I am glad that I can contribute to the process :D - Yifan On Thu, Jul 20, 2023 at 4:00 PM Francisco Guerrero wrote: > Hi list, > > I wanted to bring some visibility into the Cassandra Sidecar CI health [1]. > It seems like it has been broken for q

Re: CASSANDRA-18554 - mTLS based client and internode authenticators

Does anybody have any questions / comments? Dinesh > On Jul 17, 2023, at 12:37 PM, Dinesh Joshi wrote: > > Hi folks, > > Given the feedback received, we thought it would be best to do a CEP. Here's > the link: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34 > > It incorporates t

Re: CASSANDRA-18554 - mTLS based client and internode authenticators

Hi folks, Given the feedback received, we thought it would be best to do a CEP. Here's the link: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34 It incorporates the feedback we've received. Please let me know if there are any other comments. We'll wait for a bit and start a VOTE th

Re: CASSANDRA-18654 - start publishing CQLSH to PyPI as part of the release process

hurt to have the nuances ironed out. > > > From: Patrick McFadin > Sent: Tuesday, July 11, 2023 2:24 > To: dev@cassandra.apache.org; German Eichberger > Subject: Re: CASSANDRA-18654 - start publishing CQLSH to PyPI as part of > the relea

Re: CASSANDRA-18654 - start publishing CQLSH to PyPI as part of the release process

t;mailto:dev@cassandra.apache.org> mailto:dev@cassandra.apache.org>>; Brad Schoening mailto:bscho...@gmail.com>> Subject: [EXTERNAL] Re: CASSANDRA-18654 - start publishing CQLSH to PyPI as part of the release process You don't often get email from j...@jeffwidman.com<mailto:

Re: CASSANDRA-18554 - mTLS based client and internode authenticators

I can certainly start a VOTE thread for the CQL syntax addition. There hasn't been any feedback that suggests that there is an unaddressed concern to the changes we are making. That said, I'm not sure if there was explicit decision that has resulted in an update to the project's governance to refl

  1   2   3   4   5   6   7   8   9   >