I like the idea of adding this to the CQL Grammar, but would like to see it
follow the ReplicationStrategy style of defining a map with a class and
parameters. For example, something like this (names I’m not tied to):
SELECT * FROM table WHERE pk = x WITH ARTIFICIAL LATENCY = { 'class':
'UniformLatencyInjector', 'durationMs': 4 }
If we want to support additional types of latency injection (like between pairs
of DCs, non-uniform, etc) then the grammar will be able to handle those:
SELECT * FROM table WHERE pk = x WITH ARTIFICIAL LATENCY = { 'class':
'WideAreaLatencyInjector', 'fromDc': 'DC1', 'toDc': 'DC2', 'durationMs': 4 }
—
Abe
> On Nov 19, 2021, at 09:30, [email protected] wrote:
>
> To resurrect this discussion briefly, does anyone have a preference for
> either CQL Grammar or Protocol support?
>
> This originally felt to me like something we might want to support at the
> native protocol level, however that creates a dependency on specific clients
> and the feature might ultimately be less flexible. It’s not clear why we
> wouldn’t prefer some kind of CQL change like:
>
> SELECT * FROM table WHERE pk = x WITH ADDITIONAL LATENCY
>
> With queries being able to supply specific latencies if they so choose:
>
> SELECT * FROM table WHERE pk = x WITH ADDITIONAL LATENCY 4ms
>
> That might even support some DC->DC map for additional latencies:
>
> SELECT * FROM table WHERE pk = x WITH ADDITIONAL LATENCY ‘{dc1:{dc2: 4ms}}’
>
> This would leave applications a great deal of flexibility for experimenting
> with latency impacts, and greater ease for evolving this feature over time
> than specifying query eligibility at the protocol level.
>
> Does anyone have any thoughts about this?
>
> From: [email protected] <[email protected]>
> Date: Wednesday, 6 October 2021 at 14:48
> To: [email protected] <[email protected]>
> Subject: Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
> This is a very good point. I forget the reason we settled on consistency
> levels, I assume it was due to simplicity of the solution, as deploying
> support for a new protocol-level change is more involved.
>
> That’s probably not a good reason here, and I agree that overloading
> consistency level feels wrong. I hope we will retire user-provided
> consistency levels over the coming year or two, which is another good reason
> not to begin enhancing it with new meanings.
>
> I will rework the ticket and patches.
>
> From: Paulo Motta <[email protected]>
> Date: Wednesday, 6 October 2021 at 14:37
> To: Cassandra DEV <[email protected]>
> Subject: Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
> This sounds like a great feature!
>
> I wonder if Consistencylevel is the best way to expose this to users
> though, can't we implement this via another driver/protocol option ? Ie.
> "delay_enabled" flag that would be a modifier to an existing CL.
>
> If we decide to go the CL route, I wonder if this isn't a good opportunity
> to introduce pluggable consistency levels (CASSANDRA-8119 <
> https://issues.apache.org/jira/browse/CASSANDRA-8119>)<https://issues.apache.org/jira/browse/CASSANDRA-8119%3e)>
> so these would only
> become available when the feature is enabled.
>
> My concern here is adding niche consistency levels to the default CL table
> which may create confusion to non-power users.
>
>> Em qua., 6 de out. de 2021 às 10:12, [email protected] <
>> [email protected]> escreveu:
>>
>> Hi Everyone,
>>
>> This is a modest user-facing feature that I want to highlight in case
>> anyone has any input. In order to validate if a real cluster may modify its
>> topology or consistency level (e.g. from local to global), this ticket
>> introduces a facility for injecting latency to internode messages. This is
>> particularly helpful for high-availability topologies, and in particular
>> for LWTs (where performance may be unpredictable due to contention), so
>> that real traffic may be modified to experience gradually increasing
>> latency in order to validate a topology (or the impact of a global
>> consistency level) before any transition is undertaken.
>>
>> The user-visible changes include new config parameters, new JMX end points
>> for modifying these parameters, and new consistency levels that may be
>> supplied to mark queries as suitable for latency injection (so that
>> applications may nominate queries for this mechanism)
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
