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: bened...@apache.org <bened...@apache.org>
Date: Wednesday, 6 October 2021 at 14:48
To: dev@cassandra.apache.org <dev@cassandra.apache.org>
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 <pauloricard...@gmail.com>
Date: Wednesday, 6 October 2021 at 14:37
To: Cassandra DEV <dev@cassandra.apache.org>
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, bened...@apache.org <
bened...@apache.org> 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)
>
>
>
