Re: Merging compaction improvements to 5.0

> 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. Thanks f

Re: Merging compaction improvements to 5.0

Yeah, this is how I feel too. This is different from CASSANDRA-19488 in that there aren't any cloud provider specific details that we need to account for with our patch. We're doing normal IO here. The same code works everywhere. The results will vary based on disk latency and quotas, but imo, f

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

SimpleClient is definitely limited - it doesn't manage connection pools, load balancing, or error handling. I'd love to get to the point where we can check a driver release by running C* tests against the latest snapshot as part of qualification, so I'm on board for consolidating on driver 4.x w

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

Given we do not have any end users that use SimpleClient, and now that the java driver is part of the project, I would suggest we focus more on use of the java driver. I think it is important that the end to end integration tests that are using a driver be using one that actual clients will use.

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

Yeah, also I lean strongly towards using the Java driver. Dogfooding the Java driver has real benefits. I don't see any benefit to maintaining the SimpleClient. Jon On Thu, Feb 13, 2025 at 12:25 PM Tolbert, Andy wrote: > Thanks Abe! I had a bit of a blind spot in checking for prior tickets.

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

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,

Re: Merging compaction improvements to 5.0

Another +1 (nb) in favor of merging to 5.0. This patch has been thoroughly tested and reviewed, and will likely be a strong reason for users to upgrade.

Re: Merging compaction improvements to 5.0

+1 - Thanks for doing the work to figure this out and find a good fix. Doug > On Feb 13, 2025, at 11:28 AM, Patrick McFadin wrote: > > I’ve been following this for a while and I think it’s just some solid > engineering based on real-world challenges. Probably one of the best types of > contri

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

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 rig

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

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 th

Re: Merging compaction improvements to 5.0

I’ve been following this for a while and I think it’s just some solid engineering based on real-world challenges. Probably one of the best types of contributions to have. I’m +1 on adding it to 5 Patrick On Thu, Feb 13, 2025 at 7:31 AM Dmitry Konstantinov wrote: > +1 (nb) from my side, I raised

Re: Merging compaction improvements to 5.0

+1 (nb) from my side, I raised a few comments for CASSANDRA-15452 some time ago and Jordan addressed them. I have also backported CASSANDRA-15452 changes to my internal 4.1 fork and got about 15% reduction in compaction time even for a node with a local SSD. On Thu, 13 Feb 2025 at 13:22, Jordan We

Re: Merging compaction improvements to 5.0

For 15452 that’s correct (and I believe also for 20092). For 15452, the trunk and 5.0 patch are basically identical. Jordan On Thu, Feb 13, 2025 at 01:06 C. Scott Andreas wrote: > Checking to confirm the specific patches proposed for backport – is it the > trunk commit for C-20092 and the open

Re: Meaningless emptiness and filtering

On Tue, 11 Feb 2025 at 19:56, Caleb Rackliffe wrote: > When we add IS [NOT] NULL support, that would preferably NOT match EMPTY > values for the types where empty means something, like strings. For > everything else, EMPTY could be equivalent to null and match IS NULL. > Makes sense to me to sa