th
Date: Friday, 19 November 2021 at 17:19
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
Wouldn't modifying the CQL grammar would require updating the
application under test to perform experimentation?
The other thing I was wondering abo
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 any
t;mailto:bened...@apache.org>>
> Date: Wednesday, 6 October 2021 at 14:48
> To: dev@cassandra.apache.org <mailto:dev@cassandra.apache.org>
> mailto:dev@cassandra.apache.org>>
> Subject: Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
> This is a very good
t; than specifying query eligibility at the protocol level.
>
> Does anyone have any thoughts about this?
>
> From: bened...@apache.org
> Date: Wednesday, 6 October 2021 at 14:48
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] CASSANDRA-17024: Artificial Latency In
ing query eligibility at the protocol level.
Does anyone have any thoughts about this?
From: bened...@apache.org
Date: Wednesday, 6 October 2021 at 14:48
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
This is a very good point. I forget the reason
> On Oct 6, 2021, at 8:07 AM, Jonathan Ellis wrote:
>
> I would love to see CLs simplified. Even without user-provided CL we
> almost certainly have too many. Providing a migration path is the hard
> part.
+1 on deprecating consistency levels. Migration path is easy for most
use-cases. Some n
On Wed, Oct 6, 2021 at 8:48 AM bened...@apache.org
wrote:
> 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 enhan
: [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
On Wed, Oct 6, 2021 at 8:37 AM Paulo Motta wrote:
>
> This sounds like a great feature!
I agree, this is going to be very useful.
> 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" fl
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
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
11 matches
Mail list logo
