Re: [EXTERNAL] [Discuss] Generic Purpose Rate Limiter in Cassandra

the queues for each of the >> thread pools >> * reject requests when the queue is full with an OverloadedException. > followed by: >> If you want to follow this up with the ability to dynamically resize thread >> pools that could be interesting. > > Simple is very

Re: [EXTERNAL] [Discuss] Generic Purpose Rate Limiter in Cassandra

> Personally, I’m a bit skeptical that we will come up with a metric based > heuristic that works well in most scenarios and doesn’t require significant > knowledge and tuning. I think past implementations of the dynamic snitch are > good evidence of that. I am more optimistic on that font. I t

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

I agree with folks saying that we absolutely need to reject misplaced writes. It may not preclude coordinator making a local write, or making a write to a local replica, but even reducing probability of a misplaced write shown as success to the client is a substantial win. On Fri, Sep 13, 2024

Re: [VOTE] Release Apache Cassandra 4.1.6

though folks can specify a custom query >>>>>> handler with the -D flag, the number of users impacted by this is going >>>>>> to be incredibly small. On the other hand, the fix helps every single >>>>>> user of 4.1 that puts too much press

Re: [VOTE] Release Apache Cassandra 4.1.6

> On Tue, Jul 30, 2024 at 8:09 AM J. D. Jordan >> wrote: >>> >>> Given we allow a pluggable query handler implementation to be specified for >>> the server with a -D during startup. So I would consider the query handler >>> one of our public interface

Re: [VOTE] Release Apache Cassandra 4.1.6

allow a pluggable query handler implementation to be specified for > the server with a -D during startup. So I would consider the query handler > one of our public interfaces. > >> On Jul 30, 2024, at 9:35 AM, Alex Petrov wrote: >>  >> Hi Tommy, >> >>

Re: [VOTE] Release Apache Cassandra 4.1.6

Hi Tommy, Thank you for spotting this and bringing this to community's attention. I believe our primary interfaces are native and internode protocol, and CLI tools. Most interfaces are used to to abstract implementations internally. Few interfaces, such as DataType, Partitioner, and Triggers ca

Re: [VOTE] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

+1 On Fri, Jun 21, 2024, at 11:13 AM, Venkata Hari Krishna Nukala wrote: > Hi everyone, > > I would like to start the voting for CEP-40 as all the feedback in the > discussion thread seems to be addressed. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-40%3A+Data+Tr

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

it, and have it stated explicitly, for both "source node down" > >and "source node up" cases. > > It is a fair point. It is good to have the understanding of availability and > durability guarantees during migration. I can create a JIRA for it later. >

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

is notified of writes (like any other write node) but does > not participate in the write availability calculation. In this way a node > this is being migrated to could receive writes and have minimal impact on the > current operation of the cluster? > > Claude > >

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

Thank you for submitting this CEP! Wanted to discuss this point from the description: > How to bring up/down Cassandra/Sidecar instances or making/applying config > changes are outside the scope of this document. One advantage of doing migration via sidecar is the fact that we can stream sstab

Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

es in the repo, please reach out to me. > > Thanks, > Lorina > > On 2023/12/21 21:22:54 Alex Petrov wrote: > > Hey folks, > > > > I am mostly done with a patch that brings Harry in-tree [1]. I will trigger > > one more CI run overnight, and my intention was t

Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

Thanks everyone, Harry is now in tree! Of course, that's just a small milestone, hope it'll prove as useful as I expect it to be. https://github.com/apache/cassandra/commit/439d1b122af334bf68c159b82ef4e4879c210bd5 Happy holidays! --Alex On Sat, Dec 23, 2023, at 11:10 AM, Mick Semb Wever wrote:

Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

DE integration was working, and c.) make sure any >> modifications to existing code (rather than direct code movements from >> cassandra-harry) were straightforward. >> >> On Thu, Dec 21, 2023 at 3:23 PM Alex Petrov wrote: >>> __ >>> Hey folks, >>

Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

Hey folks, I am mostly done with a patch that brings Harry in-tree [1]. I will trigger one more CI run overnight, and my intention was to merge it some time soon, but I wanted to give a fair warning here, since this is a relatively large patch. Good news for everyone that it: a) touches no

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

ind out > though. > > >> On 7 Dec 2023, at 15:43, Alex Petrov wrote: >>  >> We have been extensively using simulator for TCM, and I think we have make >> simulator tests more approachable. I think many of the existing tests should >> be ran under simulat

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

gt; nothing happens for ten minutes we assume the simulation has locked up. > > Hitting this is indicative of a bug, and the timeout is so long that no > > realistic system variability could trigger it. > > > >> On 7 Dec 2023, at 14:56, Brandon Williams wrote: > >

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

> We should get rid of long-running unit tests altogether. They should run > faster or be split. I think we just need to evaluate on a case-by-case basis. Some tests are bad and need to go. And we need other/better ones to replace them. I am deliberately not making examples here both to avoid c

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

I will try to resopnd, but please keep in mind that all these terms are somewhat contextual. I think long and burn tests are somewhat synonymous. But most long/burn tests that we have in-tree aren't actually that long. They are just long compared to the unit tests. I personally would call the

Re: [VOTE] Release Harry 0.0.2

With 7 +1s (5 of which PMC), the vote passes. Thanks everyone! On Wed, Nov 29, 2023, at 6:40 PM, Francisco Guerrero wrote: > +1 > > On 2023/11/29 11:14:29 Alex Petrov wrote: > > Even though we would like to bring harry in-tree, this is not an immediate > > priority.

Re: [DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

+1, we definitely need to start releasing jars, and preferrably doing it with some reasonable cadence / on demand. There is a slight problem with the fact we can not cut releases without votes, which, combined with the fact that we need sha-stable snapshots, makes it tricky. Best way to do thi

[VOTE] Release Harry 0.0.2

Even though we would like to bring harry in-tree, this is not an immediate priority. Meanwhile, we need to unblock RPM builds for trunk, which means no custom jars. We will have at least one more Harry release with outstanding features to avoid any blocking. Proposing the test build of cassand

Re: [DISCUSS] Harry in-tree

23 г. Yifan Cai написа: >> +1 >> >> >> *发件人:* Sam Tunnicliffe >> *发送时间:* Tuesday, November 28, 2023 2:43:51 AM >> *收件人:* dev >> *主题:* Re: [DISCUSS] Harry in-tree >> >> Definite +1 to bringing harry-core in tree. >> >>> On 24 No

Re: [DISCUSS] Harry in-tree

x and all involved! > > Jeremy > >> On Nov 24, 2023, at 9:43 AM, Alex Petrov wrote: >> >> Hi everyone, >> >> With TCM landed, there will be way more Harry tests in-tree: we are using it >> for many coordination tests, and there's now a si

Re: [DISCUSS] Harry in-tree

> Yes. Any reason to have releases for users outside of Cassandra ? And is > there any cross-branch/version interaction, like there is with the > jvm-dtest-api ? As of today, Harry tries not to rely on branch versions. Harry-core is completely free of Cassandra dependency (for which I had to

[DISCUSS] Harry in-tree

Hi everyone, With TCM landed, there will be way more Harry tests in-tree: we are using it for many coordination tests, and there's now a simulator test that uses Harry. During development, Harry has allowed us to uncover and resolve numerous elusive edge cases. I had conversations with several

Re: Road to 5.0-GA (was: [VOTE] Release Apache Cassandra 5.0-alpha2)

We were able to narrow it down, and it seems that both issues have been introduced by [1] (both tests pass without this commit). There is a preliminary fix, and we're working on a minimal repro. Please track [2] for more information and latest updates. [1] https://github.com/apache/cassandra/co

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

doesn't, and shouldn't, matter whether individuals on the project who were > interested in collaborating on that work missed one or multiple > announcements, or whether they saw those announcements and just didn't have > the cycles to engage when they wanted to. > &g

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

always improve. We can always try and be proactive, knowing >> each other and our interests and reaching out to specific folks to make sure >> they're aware that work has hit a collaboration point or inflection point. I >> can do (apparently much) better about sending

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

Firstly, when talking about quality, many folks mention the risk of releasing bugs together with TCM and Accord. While I agree this risk is real, I would like to remind that TCM and Accord were extensively tested and simulated, for *many* hours. Just an example, we’ve recently filed an issue we

Re: [DISCUSS] Vector type and empty value

To make sure I understand this right; does that mean there will be a default value for unset fields? Like 0 for numerical values, and an empty vector (I presume) for the vector type? On Fri, Sep 15, 2023, at 11:46 AM, Benjamin Lerer wrote: > Hi everybody, > > I noticed that the new Vector type

Re: [Discuss] disabling io.netty.transport.noNative in tests

I think most of the time people actually use netty _with_ native. This might have been introduced when we were tried to make shaded in-JVM dtest jars. If all tests are passing, and we actually do have a confirmtion that native Netty is being used, I would say +1 to remove `noNative`. Just to m

Re: [VOTE] Release dtest-api 0.0.16

+1 On Thu, Aug 17, 2023, at 4:46 AM, Brandon Williams wrote: > +1 > > Kind Regards, > Brandon > > On Wed, Aug 16, 2023 at 4:34 PM Dinesh Joshi wrote: > > > > Proposing the test build of in-jvm dtest API 0.0.16 for release. > > > > Repository: > > https://gitbox.apache.org/repos/asf?p=cassandra-

Re: [VOTE] Release Apache Cassandra 3.11.16 - SECOND ATTEMPT

+1 On Tue, Aug 15, 2023, at 7:53 PM, Miklosovic, Stefan wrote: > This is the second attempt to pass the vote after [1] is fixed. > > Proposing the test build of Cassandra 3.11.16 for release. > > sha1: 681b6ca103d91d940a9fecb8cd812f58dd2490d0 > Git: https://github.com/apache/cassandra/tree/3.11.

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

rote: >> >>> I would really like us to split out utilities into a common project >> +1 to the sentiment. >> >> Would also advocate strongly for it being more tightly integrated with the >> base project than what we've been doing with our ecosystem (i.e.

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

be possible to > record it as a simple youtube video and publish it so that the detailed > information about how to use Harry is not lost? > > On Thu, May 25, 2023 at 7:36 AM Alex Petrov wrote: >> __ >> While we are at it, we may also want to pull the in-jvm dtest API as a

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

t;>> Agreed. Basically where I've ended up on this topic. >>> >>> > We could go over some interesting examples such as testing 2i (SAI) >>> >>> +100 >>> >>> >>> On Wed, May 24, 2023 at 1:40 PM Alex Petrov wrote: >>>

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

r ecosystem where we could benefit from taking > a page from their book in terms of onboarding and getting started IMO. > > On Wed, May 24, 2023, at 10:31 AM, Alex Petrov wrote: >> > I wonder if a mini-onboarding session would be good as a community session >> > -

Re: [VOTE] Release dtest-api 0.0.15

+1 On Wed, May 24, 2023, at 5:36 PM, Doug Rohrer wrote: > +1 (nb) > > > On May 24, 2023, at 11:32 AM, Brandon Williams wrote: > > > > +1 > > > > Kind Regards, > > Brandon > > > > On Wed, May 24, 2023 at 10:31 AM Dinesh Joshi wrote: > >> > >> Proposing the test build of in-jvm dtest API 0.0.

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

ractive testing / unit tests. We have been doing a lot of that with Transactional Metadata, too. > I'll hold off on this until Alex Petrov chimes in. @Alex -> got any thoughts > here? Yes, sorry for not responding on this thread earlier. I can not understate how excited I am about th

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

that running has been a fair few hours, where we >>> could have cut many manual module releases in that time. >>> >>> David and folks working on accord ? >>> >>> >>> >>> On Tue, 23 May 2023 at 20:09, Josh McKenzie wrote: >>>> _

Re: [VOTE] Release dtest-api 0.0.14

+1 On Tue, May 16, 2023, at 4:45 AM, Doug Rohrer wrote: > +1 (nb) > > Doug Rohrer > > > On May 15, 2023, at 7:17 PM, Brandon Williams wrote: > > > > +1 > > > > Kind Regards, > > Brandon > > > >> On Mon, May 15, 2023 at 5:12 PM Dinesh Joshi wrote: > >> > >> Proposing the test build of in-j

Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 On Tue, Feb 7, 2023, at 11:54 AM, Andrés de la Peña wrote: > +1 > > On Tue, 7 Feb 2023 at 09:52, Jacek Lewandowski > wrote: >> +1 >> >> - - -- --- - - >> Jacek Lewandowski >> >> >> wt., 7 lut 2023 o 10:12 Benjamin Lerer napisał(a): >>> +1 >>> >>> Le mar. 7 févr.

Re: CEP-21 and complete cluster replacement.

adopt new tooling to make most of the operations I describe available. On Thu, Oct 20, 2022, at 4:42 PM, Alex Petrov wrote: > > by default C* does prohibit concurrent bootstraps (behaviour which can be > > overridden with the cassandra.consistent.rangemovement system property). >

Re: CEP-21 and complete cluster replacement.

> by default C* does prohibit concurrent bootstraps (behaviour which can be > overridden with the cassandra.consistent.rangemovement system property). But > there's nothing to stop you fully bootstrapping additional nodes in series, > then removing them in the same way. I think there are multip

Re: Shall 4.2 become 5.0 ?

nation below), > - CEP-21 (once accepted) will be easier without having to support 3.x > compatibility. It is also my understanding that CEP-15 requires CEP-21. At least from my perspective, I would not bump the version just because of UDFs and JDK 8. On Mon, Oct 17, 2022, at 4:08 PM,

Re: Shall 4.2 become 5.0 ?

Could you be more explicit? Are you saying we should release 5.0 instead of 4.2 (which I'm assuming you're advocating for), or are you saying we should release 4.2? I still do not understand the question, really. It can't be more important to be consistent with versioning than for versions to m

Re: Shall 4.2 become 5.0 ?

I'm also a bit confused by the original question: if there's a proposal to release 4.2 as 5.0, let's hear out why and just vote for it (list reasons, and let everyone express their opinions about why this does or does not warrant the version bump). If there are no reasons for us to do, I'm not s

Re: [DISCUSS] CEP-21: Transactional Cluster Metadata

oshi wrote: > On Thu, Sep 1, 2022 at 11:20 AM Alex Petrov wrote: >> __ >> There will be no changes required to our existing Paxos implementation. We >> can just use it. Besides, Paxos is only used as K-sequencer. There is no >> need to use Raft, and both existing LWTs (wi

Re: [DISCUSS] CEP-21: Transactional Cluster Metadata

> I see that implementing a Replicated Log > > needs significant changes, particularly about how two phases of Paxos are > implemented over the entire log. So will it be better to use

Re: dtests to reproduce the schema disagreement

I could not quickly find which test does specifically this, but you could induce schema disagreements with dtests in two ways, from the top of my head: 1. dtests with verb filters; disabling schema mutations 2. by executing schema statements with NODE_LOCAL / executeInternal on the node rather t

Re: [DISCUSS] Change code style guide WRT to @Override in subclasses / interface implementations

dated, just need to fixup the website. On Fri, Jun 3, 2022, at 4:02 PM, Dinesh Joshi wrote: > So your proposal is to always add override annotation? Or are there > situations where you don’t want to add them? > >> >> On Jun 3, 2022, at 6:53 AM, Alex Petrov wrote: >>

[DISCUSS] Change code style guide WRT to @Override in subclasses / interface implementations

Hi everyone, In our style guide [1], we have a following statement: > Avoid redundant `@Override` annotations when implementing abstract or > interface methods. I'd like to suggest we change this. @Override annotation in subclasses might be annoying when you're writing the code for the first

Re: [VOTE] Release dtest-api 0.0.13

>> +1 >>> >>>> On Mar 31, 2022, at 10:04 AM, David Capwell wrote: >>>> >>>> +1 >>>> >>>>> On Mar 31, 2022, at 9:53 AM, Alex Petrov wrote: >>>>> >>>>> Proposing the test build of in-jvm

Re: [DISCUSS] Should we deprecate / freeze python dtests

(bunching up references here) > They use a separate implementation of instance initialization and thus they > test the test server rather than the real node. > What is the real gap between the in-JVM tests server instance and a server as > run by python DTests? > I also have this concern. > I

[VOTE] Release dtest-api 0.0.13

Proposing the test build of in-jvm dtest API 0.0.13 for release. Repository: https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.13 Candidate SHA: https://github.com/apache/cassandra-in-jvm-dtest-api/commit/05f4990e91583c2860356804c6945686968c05b5 tagg

Re: Apache Cassandra fuzz testing

d be encouraging the use of both for large or complex >> pieces of work. >> __ __ >> __ __ >> *From: *Alex Petrov >> *Date: *Wednesday, 16 February 2022 at 11:56 >> *To: *dev@cassandra.apache.org >> *Subject: *Re: Apache Cassandra fuzz testing >>

Re: Apache Cassandra fuzz testing

(apologies for sending an incomplete email) Hi everyone, As you may know, we’ve been actively working on fuzz testing Apache Cassandra for the past several years and made quite a large progress on that front. We’ve cut a 0.0.1 release of Harry [1], a fuzz testing tool for apache Cassandra and

Apache Cassandra fuzz testing

Hi everyone, As you may know, we've been actively working on fuzz testing Apache Cassandra for the past several years and made quite a large progress on that front.

Re: [VOTE] Release Apache Cassandra 4.0.2

Could you elaborate what exactly went wrong so we could asses and potentially fix the build? On Mon, Feb 7, 2022, at 9:50 PM, Dorian ROSSE wrote: > -1 I don't success to install apache cassandra > > > *De :* Mick Semb Wever > *Envoyé :* lundi 7 février 2022 15:14 > *À :* dev > *Objet :* [VOTE

[VOTE] release cassandra-harry 0.0.1

Proposing the test build of cassandra-harry 0.0.1 for release, to start using it in Cassandra tree. Repository: https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.1 Candidate SHA: https://github.com/apache/cassandra-harry/commit/40fb37ec8a4f08dc6a258a50cbdeab92e