Re: Welcome Jaydeepkumar Chovatia as Cassandra committer

Thank you, everyone! Jaydeep On Thu, May 1, 2025 at 5:27 AM Marouan REJEB wrote: > Congratulations ! > > On Thu, May 1, 2025 at 1:22 PM Aaron Ploetz wrote: > >> Congratulations Jaydeep! >> >> >> > On Apr 30, 2025, at 8:18 AM, Paulo Motta wrote: >> > >> > Congratulations Jaydeep! >> >

Re: [UPDATE] CEP-37

Zalys, and Jaydeep On Sun, Mar 9, 2025 at 8:53 PM Jaydeep Chovatia wrote: > Thanks a lot, Jon! > This has truly been a team effort, with Andy Tolbert, Chris Lohfink, > Francisco Guerrero, and Kristijonas Zalys all contributing over the past > year. The credit belongs to everyone! &g

Re: [Committer/reviewer needed] Request for Review of Cassandra PRs

One more ticket has been reviewed by one committer and needs another committer to review. - Local Hints are stepping on local mutations [CASSANDRA-19958 ] Jaydeep On Mon, Apr 21, 2025 at 9:39 AM Runtian Liu wrote: > Hi, > A gentle

[UPDATE] CEP-37

Hello Everyone, I wanted to update you on CEP-37 (Jira: CASSANDRA-19918 ) work. Over the last year, some of us (Andy Tolbert, Chris Lohfink

Re: [UPDATE] CEP-37

ing. Getting a built in, orchestrated repair is a > massive achievement. Thank you for your work on this, it's incredibly > valuable to the community!! > > Jon > > On Sun, Mar 9, 2025 at 2:25 PM Jaydeep Chovatia < > chovatia.jayd...@gmail.com> wrote: > >>

Re: [UPDATE] CEP-37

I missed those links in the CEP page. > > Great work and I will continue to follow your progress on this powerful > new feature. > > Thanks! > -Dave > > On Sat, Mar 8, 2025 at 9:36 AM Jaydeep Chovatia < > chovatia.jayd...@gmail.com> wrote: > >> Hi David, &

Re: [UPDATE] CEP-37

ould be optionally > enabled?) > > W.R.T. the repair logging tables in the system_distributed keyspace, will > these tables have a configurable TTL, or must they be periodically > truncated to limit their size? > > Thanks, > -Dave > > David A. Herrington II >

Re: [DISCUSS] Tooling to repair MV through a Spark job

terfere with the production traffic. - YifanOn Fri, Dec 6, 2024 at 8:27 AM Jaydeep Chovatia <chovatia.jayd...@gmail.com> wrote:Hi,NOTE: This email does not promote using Cassandra's Materialized View (MV) but assists those stuck with it for various reasons.The primary issue with MV is that on

Re: [DISCUSS] Tooling to repair MV through a Spark job

seful and - having never really used Materialized > Views - I didn't know it was an issue for some users. I would say the > Cassandra Analytics library (http://github.com/apache/cassandra-analytics/) > could be utilized for much of this, with a specialized Spark job for this > purpo

[DISCUSS] Tooling to repair MV through a Spark job

Hi, *NOTE: *This email does not promote using Cassandra's Materialized View (MV) but assists those stuck with it for various reasons. The primary issue with MV is that once it goes out of sync with the base table, no tooling is available to remediate it. This Spark job aims to fill this gap by lo

Re: [VOTE] CEP-37: Repair scheduling inside C*

>> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> On Wed, Nov 6, 2024 at 11:10 AM Francisco Guerrero < >>>>>> fran...@apache.org> wrote: >>>>>> >>>>>>> +1 (nb) >>>>>>&

[VOTE] CEP-37: Repair scheduling inside C*

Hi Everyone, I would like to start the voting for CEP-37 as all the feedback in the discussion thread seems to be addressed. Proposal: CEP-37 Repair Scheduling Inside Cassandra Discussion threa

Re: [Discuss] Repair inside C*

FYI..I've updated the CEP-37 content to include all the improvements we have discussed over this ML, ongoing work, and future work. I've also tagged JIRAs for each ongoing/future work and assigned to some individuals with a tentative timeline. Thanks, Mick, for suggesting capturing the ML discussio

Re: [Discuss] Repair inside C*

Thanks for the kind words, Mick! Jaydeep On Wed, Oct 30, 2024 at 1:35 AM Mick Semb Wever wrote: > Thanks Jaydeep. I've exhausted my lines on enquiry and am happy that > thought has gone into them. > > > >> On top of the above list, here is my recommendation (this is just a pure >> thought only

Re: [Discuss] Repair inside C*

>Repairs causing a node to OOM is not unusual. I've been working with a customer in this situation the past few weeks. Getting fixes out, or mitigating the problem, is not always as quick as one hopes (see my previous comment about how the repair_session_size setting gets easily clobbered today)

Re: [Discuss] Repair inside C*

 PM Jaydeep Chovatia < chovatia.jayd...@gmail.com> wrote: > >> > That's inaccurate, we can check the replica set for the subrange we're > about to run and see if it overlaps with the replica set of other ranges > which are being processed already. > We c

Re: [Discuss] Repair inside C*

> > > > That's inaccurate, we can check the replica set for the subrange we're about to run and see if it overlaps with the replica set of other ranges which are being processed already. We can definitely check the replicas for the subrange we plan to run and see if they overlap with the ongoing on

Re: [Discuss] Repair inside C*

Thanks, Mick, for the comment, please find my response below. >(1) I think I covered most of the points in my response to Alexander (except one, which I am responding to below separately). Tl;dr is the MVP that can be easily extended to do a table-level schedule; it is just going to be another CQ

Re: [Discuss] Repair inside C*

parate process long >>>> term makes a lot of sense but imo only once we both have a release of >>>> sidecar and a contract figured out between them on communication. I'm >>>> watching CEP-38 there as I think CQL and virtual tables are looking much &

Re: [Discuss] Repair inside C*

ks Jaydeep. > > > > >>> > > > > >>> > > > > > >>> > > > > >>> I would suggest folk take a look at the design doc and the PR in the > CEP. > > A lot is there (that I have completely missed). > > > >

Re: [Discuss] Repair inside C*

Mick, I am highly sorry to mispronounce your name. Indeed, Mick - two additional weeks is not an issue at all. Jaydeep On Fri, Oct 18, 2024 at 1:41 PM Jaydeep Chovatia wrote: > Indeed, Mike - two additional weeks is not an issue at all. > Thanks! > > Jaydeep >

Re: [Discuss] Repair inside C*

Indeed, Mike - two additional weeks is not an issue at all. Thanks! Jaydeep

Re: [Discuss] Repair inside C*

Sorry, there is a typo in the CEP-37 link; here is the correct link <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-37+Apache+Cassandra+Unified+Repair+Solution> On Thu, Oct 17, 2024 at 4:36 PM Jaydeep Chovatia wrote: > First, thank you for your patience while we strengthene

Re: [Discuss] Repair inside C*

rg/confluence/display/CASSANDRA/CEP-37+%28DRAFT%29+Apache+Cassandra+Unified+Repair+Solution > > On Sun, Feb 25, 2024 at 12:25 PM Jaydeep Chovatia < > chovatia.jayd...@gmail.com> wrote: > > Thanks, Josh. I've just updated the CEP > <https://cwiki.apache.org/conflue

[Discuss] Detect+Sync Gossip&StorageService cache to improve the out-of-range tokens issue

Each Cassandra node keeps token ownership in two separate caches. 1) Gossip cache 2) StorageService cache. The first Gossip cache is updated on a node, followed by the storage service cache. In the hot path, ownership is calculated from the storage service cache. Since two separate caches maintain

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

Rejecting/logging the traffic is a significant step forward, but that does not solve the real problem. It still degrades the workload and requires manual operator's involvement. How about we also enhance Cassandra to automatically detect and fix the token ownership mismatch between StorageService

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

19534 <https://issues.apache.org/jira/browse/CASSANDRA-19534> > > On Wed, Apr 10, 2024 at 6:35 PM Jaydeep Chovatia < > chovatia.jayd...@gmail.com> wrote: > >> Just created an official CEP-41 >> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-41+%28DRAFT%29+Apac

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

is not captured in the CEP-41. Jaydeep On Thu, Feb 22, 2024 at 11:36 AM Jaydeep Chovatia < chovatia.jayd...@gmail.com> wrote: > Thanks, Josh. I will file an official CEP with all the details in a few > days and update this thread with that CEP number. > Thanks a lot everyone for provid

Re: [Discuss] Repair inside C*

nyone's said they'll die on the hill of > implementation details, so that feels like CEP time to me. > > If you were willing and able to get a CEP together for automated repair > based on the above material, given you've done the work and have the proof > points it'

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

ake it there? > > +1 here. > > Synthesizing your gdoc, Caleb's work, and the feedback from this thread > into a draft seems like a solid next step. > > On Wed, Feb 7, 2024, at 12:31 PM, Jaydeep Chovatia wrote: > > I see a lot of great ideas being discussed or propo

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

I see a lot of great ideas being discussed or proposed in the past to cover the most common rate limiter candidate use cases. Do folks think we should file an official CEP and take it there? Jaydeep On Fri, Feb 2, 2024 at 8:30 AM Caleb Rackliffe wrote: > I just remembered the other day that I h

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

pairs, and streaming to ensure >> client requests can be serviced. I think we'd need to define the latency >> targets in order for this to work optimally, b/c you might not want to wait >> for query timeouts before you throttle. I think there's a lot of value in &g

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

t siimilar things > internally 😉 > > Thanks, > German > -- > *From:* Jaydeep Chovatia > *Sent:* Tuesday, January 16, 2024 1:16 PM > *To:* dev@cassandra.apache.org > *Subject:* [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in > Cass

Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

possible that Java driver > would start to see this node as "erroneous" with delayed response time etc > and it would start to prefer other nodes in the cluster when deciding what > node to contact for query coordination? So you would put more load on other > nodes, making th

[Discuss] Generic Purpose Rate Limiter in Cassandra

Hi, Happy New Year! I would like to discuss the following idea: Open-source Cassandra (CASSANDRA-15013 ) has an elementary built-in memory rate limiter based on the incoming payload from user requests. This rate limiter activates if any inco

Re: Need Confluent "Create" permission for filing a CEP

Thank you! On Tue, Oct 10, 2023 at 2:58 AM Brandon Williams wrote: > I've added you, you should have access now. > > Kind Regards, > Brandon > > On Tue, Oct 10, 2023 at 1:24 AM Jaydeep Chovatia > wrote: > > > > Hi, > > > > I want to create

Need Confluent "Create" permission for filing a CEP

Hi, I want to create a new CEP request but do not see the "Create" page permission on Confluent . Could someone permit me? Here is the CEP draft: [DRAFT] CEP - Apache Cassandra Official Repair Solution - Google Docs

Re: [Discuss] Repair inside C*

Is anyone going to file an official CEP for this? As mentioned in this email thread, here is one of the solution's design doc and source code on a private Apache Cassandra patch. Could you

[Discuss] Detecting token-ownership mismatch

Hi, As we know, Cassandra exchanges important topology and token-ownership-related details over Gossip. Cassandra internally maintains the following two separate caches that have the token-ownership information maintained: 1) Gossip cache and 2) Storage Service cache. The first Gossip cache is up

Re: [Discuss] Repair inside C*

ide C* > > As someone who has done a lot of work trying to make repair stable, I > approve of this message ^_^ > > More than glad to help mentor this work > > On Jul 24, 2023, at 6:29 PM, Jaydeep Chovatia > wrote: > > To clarify the repair solution timing, the one we h

Re: [Discuss] Repair inside C*

time about having repairs in the Open Source Cassandra itself. As mentioned in my previous email, any solution getting adopted is fine; the important aspect is to have a repair solution in the OSS Cassandra itself! Yours Faithfully, Jaydeep On Mon, Jul 24, 2023 at 3:46 PM Jaydeep Chovatia wrote

Re: [Discuss] Repair inside C*

Hi German, The goal is always to backport our learnings back to the community. For example, I have already successfully backported the following two enhancements/bug fixes back to the Open Source Cassandra, which are described in the article. I am already currently working on open-source a few mor

Cassandra 3.0.27 - Tombstone disappeared during node replacement

Hi, I am running Cassandra 3.0.27 in my production. In some corner case scenarios, we have tombstones disappearing during bootstrap/decommission. I've outlined a possible theory with the root cause in this ticket: https://issues.apache.org/jira/browse/CASSANDRA-17991 Could someone please help val

Re: Cassandra Token ownership split-brain (3.0.14)

a bug report against a current release of > the database. > > - Scott > > On Sep 6, 2022, at 5:13 PM, Jaydeep Chovatia > wrote: > >  > If anyone has seen this issue and knows a fix, it would be a great help! > Thanks in advance. > > Jaydeep > > On F

Re: Cassandra Token ownership split-brain (3.0.14)

If anyone has seen this issue and knows a fix, it would be a great help! Thanks in advance. Jaydeep On Fri, Sep 2, 2022 at 1:56 PM Jaydeep Chovatia wrote: > Hi, > > We are running a production Cassandra version (3.0.14) with 256 tokens > v-node configuration. Occasionally,

Cassandra Token ownership split-brain (3.0.14)

Hi, We are running a production Cassandra version (3.0.14) with 256 tokens v-node configuration. Occasionally, we see that different nodes show different ownership for the same key. Only a node restart corrects; otherwise, it continues to behave in a split-brain. Say, for example, *NodeA* nodeto

Cassandra 3.0 - A new node is not able to join the cluster

Hi, I've a production Cassandra cluster from 3.0.14 branch. Each node consists of roughly 1.5TB data with a ring size 70+70. I need to add more capacity to meet production demand, but when I add 71st node, then it streams data from other nodes as expected, but after some-time it spends an enormous

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

+1 On Wed, Sep 12, 2018 at 10:00 AM Roopa Tangirala wrote: > +1 > > > *Regards,* > > *Roopa Tangirala* > > Engineering Manager CDE > > *(408) 438-3156 - mobile* > > > > > > > On Wed, Sep 12, 2018 at 8:51 AM Sylvain Lebresne > wrote: > > > -0 > > > > The project seems to have a hard time getting

Re: [VOTE] Branching Change for 4.0 Freeze

+1 On Wed, Jul 11, 2018 at 2:46 PM sankalp kohli wrote: > Hi, > As discussed in the thread[1], we are proposing that we will not branch > on 1st September but will only allow following merges into trunk. > > a. Bug and Perf fixes to 4.0. > b. Critical bugs in any version of C*. > c. Testing

Re: Real time bad query logging framework in C*

ents, CASSANDRA-12944), > which would allow to expose internal events to external processes that > would be able to analyze these events, alert users, or event act on > them. It's a different approach from what you're suggesting, but just > wanted to mention this and maybe

Real time bad query logging framework in C*

Hi, We have worked on developing some common framework to detect/log anti-patterns/bad queries in Cassandra. Target for this effort would be to reduce burden on ops to handle Cassandra at large scale, as well as help beginners to quickly identify performance problems with the Cassandra. Initially

Re: Proposing an Apache Cassandra Management process

In my opinion this will be a great addition to the Cassandra and will take overall Cassandra project to next level. This will also improve user experience especially for new users. Jaydeep On Thu, Apr 12, 2018 at 2:42 PM Dinesh Joshi wrote: > Hey all - > With the uptick in discussion around Cas

Re: Flakey Dtests

y baked.. > Hope this answers your question! There are quite a few dtests currently > failing and as Jeff mentioned I’ve created JIRAs for a lot of them already > so any help (no matter how trivial or annoying it might be or seem) to get > everything green again. > > best, > kj

Re: Flakey Dtests

Is there a way to check which tests are failing in trunk currently? Previously this URL was giving such results but is no longer working. Jaydeep On Wed, Nov 15, 2017 at 5:44 PM, Jeff Jirsa wrote: > In lieu of a weekly wrap-up, here's a pre-Thanksgiving call for he