Re: Welcome Jeremiah Jordan to the PMC

[guo Maxwell]

Congrats！
Tolbert, Andy 于2025年2月15日 周六上午6:22写道：

> 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 Jeremiah Jordan to the PMC

[Dmitry Konstantinov]

Congratulations, Jeremiah!

On Fri, 14 Feb 2025 at 15:32, Enrico Olivelli  wrote:

> Congratulations !
>
> Enrico
>
> Il giorno ven 14 feb 2025 alle ore 16:26 Jacek Lewandowski <
> lewandowski.ja...@gmail.com> ha scritto:
>
>> Congratulations!!!
>>
>> On Fri, Feb 14, 2025, 16:17 Jeremy Hanna 
>> wrote:
>>
>>> Congratulations Jeremiah - well deserved.
>>>
>>> On Feb 14, 2025, at 9:11 AM, Ekaterina Dimitrova 
>>> wrote:
>>>
>>> Congrats!! Well deserved! Thank you for all you do and I really
>>> appreciate how much you always help everyone, sharing your broad knowledge
>>> and expertise!
>>>
>>> Cheers
>>>
>>> On Fri, 14 Feb 2025 at 9:36, Brandon Williams  wrote:
>>>
 Congratulations Jeremiah!

 Kind Regards,
 Brandon

 On Fri, Feb 14, 2025 at 8:32 AM Benedict Elliott Smith
  wrote:
 >
 > The PMC is happy to announce that Jeremiah Jordan has joined its
 membership.
 >
 > Jeremiah has been a member of this community for almost 15 years. I
 hope you will join me in welcoming him to the committee.

>>>
>>>

-- 
Dmitry Konstantinov

Re: Welcome Jeremiah Jordan to the PMC

[Russell Spitzer]

Congratulations!

On Fri, Feb 14, 2025 at 9:50 AM Dmitry Konstantinov 
wrote:

> Congratulations, Jeremiah!
>
> On Fri, 14 Feb 2025 at 15:32, Enrico Olivelli  wrote:
>
>> Congratulations !
>>
>> Enrico
>>
>> Il giorno ven 14 feb 2025 alle ore 16:26 Jacek Lewandowski <
>> lewandowski.ja...@gmail.com> ha scritto:
>>
>>> Congratulations!!!
>>>
>>> On Fri, Feb 14, 2025, 16:17 Jeremy Hanna 
>>> wrote:
>>>
 Congratulations Jeremiah - well deserved.

 On Feb 14, 2025, at 9:11 AM, Ekaterina Dimitrova 
 wrote:

 Congrats!! Well deserved! Thank you for all you do and I really
 appreciate how much you always help everyone, sharing your broad knowledge
 and expertise!

 Cheers

 On Fri, 14 Feb 2025 at 9:36, Brandon Williams  wrote:

> Congratulations Jeremiah!
>
> Kind Regards,
> Brandon
>
> On Fri, Feb 14, 2025 at 8:32 AM Benedict Elliott Smith
>  wrote:
> >
> > The PMC is happy to announce that Jeremiah Jordan has joined its
> membership.
> >
> > Jeremiah has been a member of this community for almost 15 years. I
> hope you will join me in welcoming him to the committee.
>


>
> --
> Dmitry Konstantinov
>

Re: Welcome Jeremiah Jordan to the PMC

[Jacek Lewandowski]

Congratulations!!!

On Fri, Feb 14, 2025, 16:17 Jeremy Hanna  wrote:

> Congratulations Jeremiah - well deserved.
>
> On Feb 14, 2025, at 9:11 AM, Ekaterina Dimitrova 
> wrote:
>
> Congrats!! Well deserved! Thank you for all you do and I really appreciate
> how much you always help everyone, sharing your broad knowledge and
> expertise!
>
> Cheers
>
> On Fri, 14 Feb 2025 at 9:36, Brandon Williams  wrote:
>
>> Congratulations Jeremiah!
>>
>> Kind Regards,
>> Brandon
>>
>> On Fri, Feb 14, 2025 at 8:32 AM Benedict Elliott Smith
>>  wrote:
>> >
>> > The PMC is happy to announce that Jeremiah Jordan has joined its
>> membership.
>> >
>> > Jeremiah has been a member of this community for almost 15 years. I
>> hope you will join me in welcoming him to the committee.
>>
>
>

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

[Bernardo Botella]

Guo: From your name change suggestion, I think I’d be -1 on that. In my head, 
LOOSE_NOT_NULL would imply that there is another NOT_NULL which happens to be 
NOT_NULL. Not the case now after this thread discussion. There are a lot of 
differences between MYSQL and Cassandra, and this constraint behavior being one 
of them I think is also a valid assumption. I don’t think there’s the need of 
being verbose on the naming for the constraint.

Bernardo



> On Feb 11, 2025, at 12:42 AM, guo Maxwell  wrote:
> 
> I think it may be better to use LOOSE_NOT_NULL instead of NOT_NULL.
> The reason is: NOT_NULL can easily make users think that it is a related 
> function of MYSQL, but in fact we are different.
> Changing a different name may avoid users' preconceived feelings.
> 
> Dinesh Joshi mailto:djo...@apache.org>> 于2025年2月11日周二 
> 01:55写道：
>> On Mon, Feb 10, 2025 at 9:05 AM Bernardo Botella 
>> mailto:conta...@bernardobotella.com>> wrote:
>>> We have consensus then. Let’s ditch the non strict version, and rename the 
>>> STRICTLY_NOT_NULL to NOT_NULL.
>> 
>> Can you give this thread at least 24-48 hours to ensure we capture any other 
>> perspectives? 

Re: Welcome Jeremiah Jordan to the PMC

[Alex Petrov]

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 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 Jeremiah Jordan to the PMC

[a . penya . garcia]

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? :DOn 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 JordanOn 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: Merging compaction improvements to 5.0

[Jordan West]

Thanks for the write up Mick. I think its is a great evaluation of 15452. A
few notes below:

* CI links for 15452 might be burried and I may need to link the most
recent run (I’ve been using CircleCI since it’s what I’m familiar with —
happy to have runs on ASf hardware as well).

* 15452 is configurable by YAML property as you mentioned. I’m traveling
but I’m 99% sure I made it a hot property as well (personally I believe you
shouldn’t have to restart a node to disable something like this, so if I
forgot to make it hot I will before merge). I’m traveling without my laptop
so I will double check next week (if someone has time to before then it’s
much appreciated)

 * I think “safe-ish” is a fair description of 15452. The new code is
fairly isolated but it’s in a very critical path with several call paths
leading to it. I think the testing we’ve done (both manual and automated)
as well as finding and fixing several bugs with those tests is what gives
me the confidence. And as you mentioned we have the fail safe of turning it
off otherwise.

Jordan

On Fri, Feb 14, 2025 at 12:42 Mick Semb Wever  wrote:

> Solid write up Jon!
>
> Hoping the committers and PMC members are keeping in mind this (very)
> recent thread:
> https://lists.apache.org/thread/h38g6q9d8h1q92h6qzs5tqdxpn2vmnyy
>
> This thread needs to also be about evaluating the risk these commits
> are to a patch version.
> I'm +1 and here's my thinking over it…
>
> Are the performance benefits clear ?
> Yes (thank you Jon for doing a solid job at demonstrating just how
> awesome this will be).
>
> Do we want this in 5.0 ?
> That's the dumb question :) of course.
>
> Does it fix a bug or a regression, or is an operational improvement ?
> Kinda, Branimir did mention a performance regression when the chunk
> cache was disabled.
>
> How are the patches with unforeseen risks ?
> These patches are medium sized and low-level, though isolated to (and
> creating a better isolation of) the compaction (scan) reader.  15452
> looks safe-ish.  I can't speak to 20092, it would be nice to hear
> Branimir and Sylvain chime in.  Are we confident that if any bugs do
> arise in user's 5.0 production deployments we will be quick to provide
> fixes and releases?  I was thinking it's worth putting in a system
> property that can disable the scan reader, so if anything happens
> folks can just restart the node with the system property to return to
> pre-patch behaviour, but that's already there! :)
>
> How well tested have they been ?
> We have one (or a few) reports of it running in production, that's
> super positive.  Reports of lots of manual testing, super positive
> too.  But there's no CI results available for either patch.  (Even the
> one committed to trunk doesn't have pre-commit CI results available.)
> I think CI results attached to the ticket are a must – I'm working on
> adding them.
>

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

[Ariel Weisberg]

Hi,

This is already specified in SQL. Columns that aren’t nullable need either to 
have a default value or a value specified in each insert/update.

Unless I am wrong about the standard or there is a persuasive reason to deviate 
from the standard I would argue this is actually a bug.

A persuasive reason to deviate from the standard would be something like the 
standard is just bad and not useful, but in this instance the expectation with 
a not null constraint is that the data is not null.

There is a separate discussion to be had regarding what to do with data that is 
already null, but for now I think it is fine to make that a separate 
enhancement.

Ariel

On Mon, Feb 10, 2025, at 9:49 AM, Bernardo Botella wrote:
> Hi everyone,
>
> Stefan Miklosovic and I have been working on a NOT_NULL 
> (https://github.com/apache/cassandra/pull/3867) constraint to be added 
> to the constraints tool belt, and a really interesting conversation 
> came up.
>
> First, as a problem statement, let's consider this:
>
> -
> CREATE TABLE ks.tb2 (
> id int,
> cl1 int,
> cl2 int,
> val text CHECK NOT_NULL(val),
> PRIMARY KEY (id, cl1, cl2)
> ) 
>
> cassandra@cqlsh> INSERT INTO ks.tb2 (id, cl1, cl2, val) VALUES ( 1, 2, 
> 3, null);
> InvalidRequest: Error from server: code=2200 [Invalid query] 
> message="Column value does not satisfy value constraint for column 
> 'val' as it is null."
>
> cassandra@cqlsh> INSERT INTO ks.tb2 (id, cl1, cl2, val) VALUES ( 1, 2, 
> 3, “text");
> cassandra@cqlsh> select * from ks.tb2;
>
>  id | cl1 | cl2 | val
> +-+-+--
>   1 |   2 |   3 | text
>
> (1 rows)
> cassandra@cqlsh> INSERT INTO ks.tb2 (id, cl1, cl2) VALUES ( 1, 2, 4);
> cassandra@cqlsh> select * from ks.tb2;
>
>  id | cl1 | cl2 | val
> +-+-+--
>   1 |   2 |   3 | text
>   1 |   2 |   4 | null
>
> -
>
> As you see, we have a hole in which a 'null' value is getting written 
> on column val even if we have a NOT_NULL on that particular column 
> whenever the column is NOT specified on the write. That raises the 
> question on how this particular constraint should behave.
>
> If we consider the other constraints (scalar constraint and length 
> constraint so far), this particular behavior is fine. But, if the 
> constraint is NOT_NULL, then it becomes a little bit trickier.
>
> The conclusions we have reached is that the meaning of constraints 
> should be interpreted like: I check whatever you give me as part of the 
> write, ignoring everything else. Let me elaborate:
> If we decide to treat this particular NOT_NULL constraint differently, 
> and check if the value for that column is present in the insert 
> statement, we then open a different can of worms. What happens if the 
> row already exists with a valid value, and that insert statement is 
> only trying to do an update to a different column in the row? If that 
> was the case, we would be forcing the user to specify the 'val' column 
> value for every update, even if it is not needed. 
>
> Mainly for this reason, we think it is better to treat this NOT_NULL 
> constraint just like the other constraints, and execute it ONLY on the 
> values that are present on the insert statement.
>
> The main con is that it may lead to a little bit of confussion (as in, 
> why I just added a null value to the table even if I have a NOT_NULL 
> constraint?). We have thought on aliviating this particular confusion 
> by:
> - Extensive documentation. Let's be upfront on what this constraint 
> does and does not. 
> (https://github.com/apache/cassandra/blob/ed58c404e8c880b69584e71a3690d3d9f73ef9fa/doc/modules/cassandra/pages/developing/cql/constraints.adoc#not_null-constraint)
> - Adding, as part of this patch, yet another constraint 
> (STRICTLY_NOT_NULL), that checks for the actual column value to be 
> present in the insert statement..
>
> If you've made it until here, that means you are really interested in 
> constraints. Thanks! The question for you is, would you have any 
> concern with this approach?
>
> Thanks,
> Bernardo

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

[Ariel Weisberg]

Sorry I didn’t see on my phone this has already been brought up.

On Fri, Feb 14, 2025, at 9:17 PM, Ariel Weisberg wrote:
> Hi,
>
> This is already specified in SQL. Columns that aren’t nullable need 
> either to have a default value or a value specified in each 
> insert/update.
>
> Unless I am wrong about the standard or there is a persuasive reason to 
> deviate from the standard I would argue this is actually a bug.
>
> A persuasive reason to deviate from the standard would be something 
> like the standard is just bad and not useful, but in this instance the 
> expectation with a not null constraint is that the data is not null.
>
> There is a separate discussion to be had regarding what to do with data 
> that is already null, but for now I think it is fine to make that a 
> separate enhancement.
>
> Ariel
>
> On Mon, Feb 10, 2025, at 9:49 AM, Bernardo Botella wrote:
>> Hi everyone,
>>
>> Stefan Miklosovic and I have been working on a NOT_NULL 
>> (https://github.com/apache/cassandra/pull/3867) constraint to be added 
>> to the constraints tool belt, and a really interesting conversation 
>> came up.
>>
>> First, as a problem statement, let's consider this:
>>
>> -
>> CREATE TABLE ks.tb2 (
>> id int,
>> cl1 int,
>> cl2 int,
>> val text CHECK NOT_NULL(val),
>> PRIMARY KEY (id, cl1, cl2)
>> ) 
>>
>> cassandra@cqlsh> INSERT INTO ks.tb2 (id, cl1, cl2, val) VALUES ( 1, 2, 
>> 3, null);
>> InvalidRequest: Error from server: code=2200 [Invalid query] 
>> message="Column value does not satisfy value constraint for column 
>> 'val' as it is null."
>>
>> cassandra@cqlsh> INSERT INTO ks.tb2 (id, cl1, cl2, val) VALUES ( 1, 2, 
>> 3, “text");
>> cassandra@cqlsh> select * from ks.tb2;
>>
>>  id | cl1 | cl2 | val
>> +-+-+--
>>   1 |   2 |   3 | text
>>
>> (1 rows)
>> cassandra@cqlsh> INSERT INTO ks.tb2 (id, cl1, cl2) VALUES ( 1, 2, 4);
>> cassandra@cqlsh> select * from ks.tb2;
>>
>>  id | cl1 | cl2 | val
>> +-+-+--
>>   1 |   2 |   3 | text
>>   1 |   2 |   4 | null
>>
>> -
>>
>> As you see, we have a hole in which a 'null' value is getting written 
>> on column val even if we have a NOT_NULL on that particular column 
>> whenever the column is NOT specified on the write. That raises the 
>> question on how this particular constraint should behave.
>>
>> If we consider the other constraints (scalar constraint and length 
>> constraint so far), this particular behavior is fine. But, if the 
>> constraint is NOT_NULL, then it becomes a little bit trickier.
>>
>> The conclusions we have reached is that the meaning of constraints 
>> should be interpreted like: I check whatever you give me as part of the 
>> write, ignoring everything else. Let me elaborate:
>> If we decide to treat this particular NOT_NULL constraint differently, 
>> and check if the value for that column is present in the insert 
>> statement, we then open a different can of worms. What happens if the 
>> row already exists with a valid value, and that insert statement is 
>> only trying to do an update to a different column in the row? If that 
>> was the case, we would be forcing the user to specify the 'val' column 
>> value for every update, even if it is not needed. 
>>
>> Mainly for this reason, we think it is better to treat this NOT_NULL 
>> constraint just like the other constraints, and execute it ONLY on the 
>> values that are present on the insert statement.
>>
>> The main con is that it may lead to a little bit of confussion (as in, 
>> why I just added a null value to the table even if I have a NOT_NULL 
>> constraint?). We have thought on aliviating this particular confusion 
>> by:
>> - Extensive documentation. Let's be upfront on what this constraint 
>> does and does not. 
>> (https://github.com/apache/cassandra/blob/ed58c404e8c880b69584e71a3690d3d9f73ef9fa/doc/modules/cassandra/pages/developing/cql/constraints.adoc#not_null-constraint)
>> - Adding, as part of this patch, yet another constraint 
>> (STRICTLY_NOT_NULL), that checks for the actual column value to be 
>> present in the insert statement..
>>
>> If you've made it until here, that means you are really interested in 
>> constraints. Thanks! The question for you is, would you have any 
>> concern with this approach?
>>
>> Thanks,
>> Bernardo

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

[Štefan Miklošovič]

Enough time has passed without anybody else stepping in so I think it is
reasonable to go with behaviour of STRICTLY_NOT_NULL renamed as NOT_NULL
and dropping the "weak" NOT_NULL as described in the original e-mail.

On Tue, Feb 11, 2025 at 9:44 AM guo Maxwell  wrote:

> I think it may be better to use LOOSE_NOT_NULL instead of NOT_NULL.
> The reason is: NOT_NULL can easily make users think that it is a related
> function of MYSQL, but in fact we are different.
> Changing a different name may avoid users' preconceived feelings.
>
> Dinesh Joshi  于2025年2月11日周二 01:55写道：
>
>> On Mon, Feb 10, 2025 at 9:05 AM Bernardo Botella <
>> conta...@bernardobotella.com> wrote:
>>
>>> We have consensus then. Let’s ditch the non strict version, and rename
>>> the STRICTLY_NOT_NULL to NOT_NULL.
>>>
>>
>> Can you give this thread at least 24-48 hours to ensure we capture any
>> other perspectives?
>>
>

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

[Benedict Elliott Smith]

One thing to consider in this discussion is integration with dtests, and in 
particular the simulator. It would help to improve coverage if we had a 
“client” that could operate without going over the network (or, going over a 
simulated network), so that it can be controlled by the simulator.

The SimpleClient is going to be a lot easier to achieve this with than the Java 
Driver, I would guess? I would expect that getting the Java Driver 
simulator-compatible would be a non-trivial undertaking in general.

I recognise none of this has happened yet, and I don’t have a timeline for this 
happening in future, but I would hate to make this future test coverage avenue 
harder to explore.


> On 13 Feb 2025, at 20:49, Abe Ratnofsky  wrote:
> 
> 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 where it's 
> appropriate.

Re: Merging compaction improvements to 5.0

[Josh McKenzie]

> If folks want to point to the docs for each cloud provider for the maximum 
> block size per IO request, we can certainly document that somewhere.
Meh, that will probably change on their side over time right? At most I'd say 
we link to their docs, but even then those external links will go stale and 
let's be honest: we're not going to keep up with that.

I think a bread crumb of "hey, check the docs for your infra to see what the 
optimal max block size is" would be just right.

Also: +1 to including in 5.0. Great work on this!

On Thu, Feb 13, 2025, at 8:25 PM, Paulo Motta wrote:
> > 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 for the additional context Jordan.
> 
> I will not be able to test this soon, but it looks like it has broad support 
> and no apparent objections so this seems like a welcome change. +1 to include 
> extraordinarily perf improvement in 5.0 if no objections.
> 
> I will add additional feedback once I have the chance to test this.
> 
> On Wed, 12 Feb 2025 at 21:48 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

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

[Josh McKenzie]

Unifying on latest java driver in the codebase and beefing up SimpleClient to 
be used specifically in the simulator makes sense to me. The more we exercise 
the driver in our testing stack the better, but to your point Benedict, the 
lift to get the driver itself simulator compatible seems like it wouldn't be 
worth it. Doubt we'd find a bunch of subtle threading and scheduling bugs in 
the driver (famous last words...)

On Fri, Feb 14, 2025, at 6:12 AM, Benedict Elliott Smith wrote:
> One thing to consider in this discussion is integration with dtests, and in 
> particular the simulator. It would help to improve coverage if we had a 
> “client” that could operate without going over the network (or, going over a 
> simulated network), so that it can be controlled by the simulator.
> 
> The SimpleClient is going to be a lot easier to achieve this with than the 
> Java Driver, I would guess? I would expect that getting the Java Driver 
> simulator-compatible would be a non-trivial undertaking in general.
> 
> I recognise none of this has happened yet, and I don’t have a timeline for 
> this happening in future, but I would hate to make this future test coverage 
> avenue harder to explore.
> 
> 
> > On 13 Feb 2025, at 20:49, Abe Ratnofsky  wrote:
> > 
> > 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 
> > where it's appropriate.
> 
> 

Re: Welcome Jeremiah Jordan to the PMC

[Jordan West]

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

Welcome Jeremiah Jordan to the PMC

[Benedict Elliott Smith]

The PMC is happy to announce that Jeremiah Jordan has joined its membership.

Jeremiah has been a member of this community for almost 15 years. I hope you 
will join me in welcoming him to the committee.

Re: Welcome Jeremiah Jordan to the PMC

[Brandon Williams]

Congratulations Jeremiah!

Kind Regards,
Brandon

On Fri, Feb 14, 2025 at 8:32 AM Benedict Elliott Smith
 wrote:
>
> The PMC is happy to announce that Jeremiah Jordan has joined its membership.
>
> Jeremiah has been a member of this community for almost 15 years. I hope you 
> will join me in welcoming him to the committee.

Re: Welcome Jeremiah Jordan to the PMC

[Mick Semb Wever]

   .

> I hope you will join me in welcoming him to the committee.


Welcome JD!

Re: Welcome Jeremiah Jordan to the PMC

[Ekaterina Dimitrova]

Congrats!! Well deserved! Thank you for all you do and I really appreciate
how much you always help everyone, sharing your broad knowledge and
expertise!

Cheers

On Fri, 14 Feb 2025 at 9:36, Brandon Williams  wrote:

> Congratulations Jeremiah!
>
> Kind Regards,
> Brandon
>
> On Fri, Feb 14, 2025 at 8:32 AM Benedict Elliott Smith
>  wrote:
> >
> > The PMC is happy to announce that Jeremiah Jordan has joined its
> membership.
> >
> > Jeremiah has been a member of this community for almost 15 years. I hope
> you will join me in welcoming him to the committee.
>

Re: Welcome Jeremiah Jordan to the PMC

[Jeremy Hanna]

Congratulations Jeremiah - well deserved.

> On Feb 14, 2025, at 9:11 AM, Ekaterina Dimitrova  
> wrote:
> 
> Congrats!! Well deserved! Thank you for all you do and I really appreciate 
> how much you always help everyone, sharing your broad knowledge and 
> expertise! 
> 
> Cheers
> 
> On Fri, 14 Feb 2025 at 9:36, Brandon Williams  > wrote:
>> Congratulations Jeremiah!
>> 
>> Kind Regards,
>> Brandon
>> 
>> On Fri, Feb 14, 2025 at 8:32 AM Benedict Elliott Smith
>> mailto:bened...@apache.org>> wrote:
>> >
>> > The PMC is happy to announce that Jeremiah Jordan has joined its 
>> > membership.
>> >
>> > Jeremiah has been a member of this community for almost 15 years. I hope 
>> > you will join me in welcoming him to the committee.

Re: Welcome Jeremiah Jordan to the PMC

[Enrico Olivelli]

Congratulations !

Enrico

Il giorno ven 14 feb 2025 alle ore 16:26 Jacek Lewandowski <
lewandowski.ja...@gmail.com> ha scritto:

> Congratulations!!!
>
> On Fri, Feb 14, 2025, 16:17 Jeremy Hanna 
> wrote:
>
>> Congratulations Jeremiah - well deserved.
>>
>> On Feb 14, 2025, at 9:11 AM, Ekaterina Dimitrova 
>> wrote:
>>
>> Congrats!! Well deserved! Thank you for all you do and I really
>> appreciate how much you always help everyone, sharing your broad knowledge
>> and expertise!
>>
>> Cheers
>>
>> On Fri, 14 Feb 2025 at 9:36, Brandon Williams  wrote:
>>
>>> Congratulations Jeremiah!
>>>
>>> Kind Regards,
>>> Brandon
>>>
>>> On Fri, Feb 14, 2025 at 8:32 AM Benedict Elliott Smith
>>>  wrote:
>>> >
>>> > The PMC is happy to announce that Jeremiah Jordan has joined its
>>> membership.
>>> >
>>> > Jeremiah has been a member of this community for almost 15 years. I
>>> hope you will join me in welcoming him to the committee.
>>>
>>
>>

Re: Welcome Jeremiah Jordan to the PMC

[Josh McKenzie]

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 Jeremiah Jordan to the PMC

[Yifan Cai]

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 Jeremiah Jordan to the PMC

[Francisco Guerrero]

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 Jeremiah Jordan to the PMC

[Jeremiah Jordan]

 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: Merging compaction improvements to 5.0

[Mick Semb Wever]

Solid write up Jon!

Hoping the committers and PMC members are keeping in mind this (very)
recent thread: https://lists.apache.org/thread/h38g6q9d8h1q92h6qzs5tqdxpn2vmnyy

This thread needs to also be about evaluating the risk these commits
are to a patch version.
I'm +1 and here's my thinking over it…

Are the performance benefits clear ?
Yes (thank you Jon for doing a solid job at demonstrating just how
awesome this will be).

Do we want this in 5.0 ?
That's the dumb question :) of course.

Does it fix a bug or a regression, or is an operational improvement ?
Kinda, Branimir did mention a performance regression when the chunk
cache was disabled.

How are the patches with unforeseen risks ?
These patches are medium sized and low-level, though isolated to (and
creating a better isolation of) the compaction (scan) reader.  15452
looks safe-ish.  I can't speak to 20092, it would be nice to hear
Branimir and Sylvain chime in.  Are we confident that if any bugs do
arise in user's 5.0 production deployments we will be quick to provide
fixes and releases?  I was thinking it's worth putting in a system
property that can disable the scan reader, so if anything happens
folks can just restart the node with the system property to return to
pre-patch behaviour, but that's already there! :)

How well tested have they been ?
We have one (or a few) reports of it running in production, that's
super positive.  Reports of lots of manual testing, super positive
too.  But there's no CI results available for either patch.  (Even the
one committed to trunk doesn't have pre-commit CI results available.)
I think CI results attached to the ticket are a must – I'm working on
adding them.

Re: Welcome Jeremiah Jordan to the PMC

[Patrick McFadin]

Congratulations, and don't let Josh be a downer. ;)

On Fri, Feb 14, 2025 at 10:36 AM 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 Jeremiah Jordan to the PMC

[Paulo Motta]

Congrats JD!

On Fri, 14 Feb 2025 at 18:35 guo Maxwell  wrote:

> Congrats！
> Tolbert, Andy 于2025年2月15日 周六上午6:22写道：
>
>> 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!
>>>
>>> >>
>>>
>>> >
>>>
>>>
>>>
>>>
>>>