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