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, bened...@apache.org 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: 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) >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org