Is it possible to backport changes from the CASSANDRA-17666 to the 4.1
branch?
Regards
Nikolai Loginov
There is also a Jira to track pre-merge tasks here:
https://issues.apache.org/jira/browse/CASSANDRA-18196
> On Sep 20, 2024, at 4:09 PM, Josh McKenzie wrote:
>
>
>>
>> This presents an opportune moment for those interested to review the code.
>> ...
>> +88,341 −7,341
>> 1003 Files changed
>
If we have this table
CREATE TABLE ks.tb2 (
id int PRIMARY KEY,
name text
);
I can either specify name of an index on my own like this:
CREATE INDEX name_index ON ks.tb2 (name) ;
or I can let Cassandra to figure that name on its own:
CREATE INDEX ON ks.tb2 (name) ;
in that case it wil
If we’re debating the overall approach, I think we need to define what we want
to achieve before we pursue any specific design.
I think rate limiting is simply a proxy for cluster stability. I think
implicitly we also all want to achieve client fairness. Rate limiting is one
proposal for achiev
I know it is probably too soon to discuss the implementation details in
depth as it is hard to say precisely how it will look like but I want to
highlight for example this (1). Would some parts of that work touch this
logic?
There is also (2) which tries to solve different but somewhat related
pro
> Are those three sufficient to protect against a client that unexpectedly
> comes up with 100x a previous provisioned-for workload? Or 100 clients at
> 100x concurrently? Given that can be 100x in terms of quantity (helped by
> queueing and shedding), but also 100x in terms of *computational an
