Unexplained stuck memtable flush

[Bowen Song via dev]

Hi all,

We have a cluster running Cassandra 4.1.1. We are seeing the memtable 
flush randomly getting stuck. This has happened twice in the last 10 
days, to two different nodes in the same cluster. This started to happen 
after we enabled CDC, and each time it got stuck, there was at least one 
repair running involving the affected node.


The signs of the stuck memtable flush is most obvious from the 
"StatusLogger" logs.


At the beginning, the MemtablePostFlush and MemtableFlushWriter got 
stuck, they have 1 and 2 active tasks each, and a small number of 
pending tasks.


INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:65 - 
Pool Name   Active   Pending  Completed Blocked  
All Time Blocked
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
ReadStage 0 0   34052333 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
CompactionExecutor 0 0    1019777 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
MutationStage 0 0   14930764 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
MemtableReclaimMemory 0 0  21877 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
PendingRangeCalculator 0 0    177 
0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
Repair#61 0 0   1344 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
GossipStage 0 0 889452 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
SecondaryIndexManagement 0 0  1 
0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
HintsDispatcher 0 0 19 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
Repair-Task 0 0 65 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
RequestResponseStage 0 0   7834 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
Native-Transport-Requests 0 0    8967921 
0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
MigrationStage 0 0  5 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
MemtableFlushWriter 2    10  21781 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
MemtablePostFlush 1    11  47856 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
PerDiskMemtableFlushWriter_0 0 0  21769 
0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
Sampler 0 0  0 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
ValidationExecutor 0 0  36651 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
ViewBuildExecutor 0 0  0 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
InternalResponseStage 0 0    240 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
AntiEntropyStage 1  1773 120067 0 0
INFO  [ScheduledTasks:1] 2024-11-03 03:50:15,224 StatusLogger.java:69 - 
CacheCleanupExecutor 0 0  0 0 0


The number of pending tasks slowly grows larger over time, and the 
number of completed tasks do not increase at all.


INFO  [ScheduledTasks:1] 2024-11-03 16:33:05,941 StatusLogger.java:65 - 
Pool Name   Active   Pending  Completed Blocked  
All Time Blocked
INFO  [ScheduledTasks:1] 2024-11-03 16:33:05,941 StatusLogger.java:69 - 
ReadStage 0 0   39905462 0 0
INFO  [ScheduledTasks:1] 2024-11-03 16:33:05,941 StatusLogger.java:69 - 
CompactionExecutor 0 0    1170100 0 0
INFO  [ScheduledTasks:1] 2024-11-03 16:33:05,941 StatusLogger.java:69 - 
MutationStage 0 0   16976992 0 0
INFO  [ScheduledTasks:1] 2024-11-03 16:33:05,941 StatusLogger.java:69 - 
Repair#76 0 0  0 0 0
INFO  [ScheduledTasks:1] 2024-11-03 16:33:05,941 StatusLogger.java:69 - 
Repair#74 0 0  0 0 0
INFO  [ScheduledTasks:1] 2024-11-03 16:33:05

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[guo Maxwell]

Hello, everyone.
I have a point of view that our CREATE TABLE LIKE grammar should not
support the setting of table options, like :

> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name WITH TRIGGERS
> AND VIEWS AND compaction = { 'class' : 'LeveledCompactionStrategy' } AND
> default_time_to_live = 86400;

If the user wants to copy the table and set the compaction strategy for the
new table, then he can execute the
ALTER TABLE statement after copying the table.

So, I think it’s enough to support the above five cases . The original
intention of copying a table is to copy the table,
and support what is to or not to copy during the copying process. Not
changing the options at the same time.

WDYT ?

guo Maxwell  于2024年11月5日周二 14:07写道：

> Hi，stefan and Dave,
> I do not intend to implement the BNF of COPY TABLE based on the BNF of
> CREATE TABLE. All table options are indeed copied by default. Therefore,
> the following syntax is not supported:
>
> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name WITH TRIGGERS
>> AND VIEWS AND compaction = { 'class' : 'LeveledCompactionStrategy' } AND
>> default_time_to_live = 86400;
>
>
> We can see that the above statement itself is very complicated because it
> provides too many choices.
> If we support individual settings of table options
> (compaction/compression), what about other TRIGGER/INDEXS ? I tend to treat
> the table, TRIGGER, INDEX, etc. as a whole and copy them uniformly. As for
> their own attributes, such as table options, INDEX attributes, etc., they
> can be copied and then set manually.
>
> So we only going to support :
>
>> 1.CREATE TABLE newks.newtable LIKE oldks.oldtable
>> 2.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH ALL // this means
>> copy indexes and triggers
>> 3.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH INDEXES
>> 4.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH TRIGGERS
>> 5.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH TRIGGERS AND
>> INDEXES // equal to option 2.
>
>
> Štefan Miklošovič  于2024年11月4日周一 23:31写道：
>
>> 1) Just mention that it will not be part of phase 1, I am OK if it will
>> be delivered later.
>>
>> 2) If we had "ALL" introduced, then we would have something like this:
>>
>> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name
>> WITH
>> ALL
>> AND compaction = { 'class' : 'LeveledCompactionStrategy' }
>> AND default_time_to_live = 86400;
>>
>> I think this is a little bit "strange". It would make sense to add ALL if
>> we have not had any "AND"s but mixing ALL and then adding AND with options
>> is a little bit confusing.
>>
>> 3)
>>
>> Do I understand correctly that your CEP will make this possible? I do not
>> want to go into the implementation details for now.
>>
>> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name
>> WITH TRIGGERS
>> AND VIEWS
>> AND compaction = { 'class' : 'LeveledCompactionStrategy' }
>> AND default_time_to_live = 86400;
>>
>> In other words, it will copy all options from "cycling.cyclist_name"
>> while it will be possible to override the options with whatever I want?
>> Basically what Dave suggested.
>>
>>
>> On Mon, Nov 4, 2024 at 4:21 PM guo Maxwell  wrote:
>>
>>> Hi stefan
>>> 1、yes, cross-keyspace copying will be much complicated than copying
>>> under same keyspace , but I think we can support it in the future , and I
>>> think it is under the scope of this CEP , so I add it .Or is it that the
>>> work planned for the next step should not be listed here for the time
>>> being?
>>> I don't know the rules very well here, and I hope if you can help point
>>> out the unreasonable points 😀 , because I do plan to complete this
>>> task, although I have only implemented the same keyspace now.
>>> 2、yes, you are right, I gave up ALL at the first time , But after I
>>> replied to yifan’s email, I communicated with him privately through slack.
>>> In the end, I was not strongly opposed to ALL (Sorry, we communicated in
>>> Chinese,
>>> https://the-asf.slack.com/archives/D07SXB787HN/p1729136909357689), In
>>> addition, I later saw that you were +0, so I added ALL back.
>>> 3、the change to Parse.g will be like :
>>>
 /**
  * CREATE TABLE [IF NOT EXISTS] 
  * LIKE 
  * [ WITH OPTIONS AND INDEXES AND TRIGGERS ]
  */
 copyTableStatement returns  [CopyTableStatement.Raw stmt]
 @init { boolean ifNotExists = false; }
 : K_CREATE K_COLUMNFAMILY newCf=columnFamilyName LIKE 
 oldCf=columnFamilyName
   { $stmt = new CopyTableStatement.Raw(newCf, oldCf); }
   tableLikeOptions[stmt]
 ;

 tableLikeOptions[CopyTableStatement.Raw stmt]
 : ( K_WITH tableLikeSingleOption[stmt] ( K_AND 
 tableLikeSingleOption[stmt] )*)?
 ;

 tableLikeSingleOption[CopyTableStatement.Raw stmt]
 : option=STRING_LITERAL { $stmt.extendWithLikeOptions($option.text); }
 ;

 I don’t plan to reuse the Create table definitio

Re: Backporting CASSANDRA-17812 to 4.x

[Mick Semb Wever]

Can you please put the ticket description in the email.  Saves us having to
follow the link to know what you're talking about.

Yes to backporting this.

On Tue, 5 Nov 2024 at 10:27, Štefan Miklošovič 
wrote:

> Hello,
>
> I want to ask if there are objections for backporting CASSANDRA-17812 (1)
> to 4.0.x and 4.1.x.
>
> There is a question already in that ticket about backporting from another
> person and we keep being asked about this a lot. It seems to me that while
> this is technically an improvement, it is so valuable that we should make
> an exception here.
>
> It is even security related.
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-17812
>
> Regards
>

Re: Backporting CASSANDRA-17812 to 4.x

[Josh McKenzie]

I'm neutral to the backport. In terms of the letter of the law, I can see the 
argument either way of it being an improvement or a bugfix.

Definitely wouldn't -1 a backport.

On Tue, Nov 5, 2024, at 7:23 AM, Mick Semb Wever wrote:
> Can you please put the ticket description in the email.  Saves us having to 
> follow the link to know what you're talking about.
> 
> Yes to backporting this.
> 
> On Tue, 5 Nov 2024 at 10:27, Štefan Miklošovič  wrote:
>> Hello,
>> 
>> I want to ask if there are objections for backporting CASSANDRA-17812 (1) to 
>> 4.0.x and 4.1.x.
>> 
>> There is a question already in that ticket about backporting from another 
>> person and we keep being asked about this a lot. It seems to me that while 
>> this is technically an improvement, it is so valuable that we should make an 
>> exception here. 
>> 
>> It is even security related.
>> 
>> (1) https://issues.apache.org/jira/browse/CASSANDRA-17812
>> 
>> Regards

Re: Backporting CASSANDRA-17812 to 4.x

[J. D. Jordan]

If I read the ticket correctly, this is preventing bcrypt of incoming credentials from causing a DOS?I think that’s reasonable to backport.  If we want to be conservative it could be backported with added code that keeps the current behavior by default?On Nov 5, 2024, at 7:43 AM, Josh McKenzie  wrote:I'm neutral to the backport. In terms of the letter of the law, I can see the argument either way of it being an improvement or a bugfix.Definitely wouldn't -1 a backport.On Tue, Nov 5, 2024, at 7:23 AM, Mick Semb Wever wrote:Can you please put the ticket description in the email.  Saves us having to follow the link to know what you're talking about.Yes to backporting this.On Tue, 5 Nov 2024 at 10:27, Štefan Miklošovič  wrote:Hello,I want to ask if there are objections for backporting CASSANDRA-17812 (1) to 4.0.x and 4.1.x.There is a question already in that ticket about backporting from another person and we keep being asked about this a lot. It seems to me that while this is technically an improvement, it is so valuable that we should make an exception here. It is even security related.(1) https://issues.apache.org/jira/browse/CASSANDRA-17812Regards

Re: Backporting CASSANDRA-17812 to 4.x

[Štefan Miklošovič]

Backporting in such a way that all auth requests will still go to the same
request executor as before is OK for me.

On Tue, Nov 5, 2024 at 3:32 PM J. D. Jordan 
wrote:

> If I read the ticket correctly, this is preventing bcrypt of incoming
> credentials from causing a DOS?
> I think that’s reasonable to backport.  If we want to be conservative it
> could be backported with added code that keeps the current behavior by
> default?
>
> On Nov 5, 2024, at 7:43 AM, Josh McKenzie  wrote:
>
> 
> I'm neutral to the backport. In terms of the letter of the law, I can see
> the argument either way of it being an improvement or a bugfix.
>
> Definitely wouldn't -1 a backport.
>
> On Tue, Nov 5, 2024, at 7:23 AM, Mick Semb Wever wrote:
>
> Can you please put the ticket description in the email.  Saves us having
> to follow the link to know what you're talking about.
>
> Yes to backporting this.
>
> On Tue, 5 Nov 2024 at 10:27, Štefan Miklošovič 
> wrote:
>
> Hello,
>
> I want to ask if there are objections for backporting CASSANDRA-17812 (1)
> to 4.0.x and 4.1.x.
>
> There is a question already in that ticket about backporting from another
> person and we keep being asked about this a lot. It seems to me that while
> this is technically an improvement, it is so valuable that we should make
> an exception here.
>
> It is even security related.
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-17812
>
> Regards
>
>
>

Re: Unexplained stuck memtable flush

[Jeff Jirsa]

> On Nov 5, 2024, at 4:12 AM, Bowen Song via user  
> wrote:
> 
> Writes on this node starts to timeout and fail. But if left untouched, it's 
> only gonna get worse, and eventually lead to JVM OOM and crash.
> 
> By inspecting the heap dump created at OOM, we can see that both of the 
> MemtableFlushWriter threads are stuck on line 1190 
> 
>  in the ColumnFamilyStore.java:
> 
> // mark writes older than the barrier as blocking progress, 
> permitting them to exceed our memory limit
> // if they are stuck waiting on it, then wait for them all to 
> complete
> writeBarrier.markBlocking();
> writeBarrier.await();   // <--- stuck here
> 
> And the MemtablePostFlush thread is stuck on line 1094 
> 
>  in the same file.
> 
> try
> {
> // we wait on the latch for the commitLogUpperBound to be 
> set, and so that waiters
> // on this task can rely on all prior flushes being complete
> latch.await();   // <--- stuck here
> }
> Our top suspect is CDC interacting with repair, since this started to happen 
> shortly after we enabled CDC on the nodes, and each time repair was running. 
> But we have not been able to reproduce this in a testing cluster, and don't 
> know what's the next step to troubleshoot this issue. So I'm posting it in 
> the mailing lists and hoping someone may know something about it or point me 
> to the right direction.
> 

Wouldn’t be completely surprised if  CDC  or repair somehow has a barrier, I’ve 
also seen similar behavior pre-3.0 with “very long running read commands” that 
have a barrier on the memtable that prevent release.

You’ve got the heap (great, way better than most people debugging), are you 
able to navigate through it and look for references to that memtable or other 
things holding a barrier?

Backporting CASSANDRA-17812 to 4.x

[Štefan Miklošovič]

Hello,

I want to ask if there are objections for backporting CASSANDRA-17812 (1)
to 4.0.x and 4.1.x.

There is a question already in that ticket about backporting from another
person and we keep being asked about this a lot. It seems to me that while
this is technically an improvement, it is so valuable that we should make
an exception here.

It is even security related.

(1) https://issues.apache.org/jira/browse/CASSANDRA-17812

Regards

Re: [DISCUSS] Usage of "var" instead of types in the code

[Maxim Muzafarov]

To me, this sounds like the style consistency throughout the project,
so if we just allowed having the "var" keyword we would have a mix of
new and old styles without any distant prospect of a unified style.

We should evolve the code style from one unified form to another, thus
either we use it everywhere and fix all the places where it's
applicable, or forbid it, avoid having "mixed" styles.  If everyone
coded the way they liked, it would be a mess.

I would vote -0.5 to allow it, and +1 to forbid it everywhere.

On Tue, 5 Nov 2024 at 00:02, Štefan Miklošovič  wrote:
>
> People who are OK with vars in tests - are you also the ones who are going to 
> write vars from now on yourself or you just do not mind if you encounter it?
>
> There is a difference between
>
> "keep it in tests, I am going to use this, this is actually a good idea"
>
> and
>
> "keep it in tests if people are going to use it, I do not mind but I am not 
> going to change my style".
>
> If the latter is the case, then who is actually going to write tests on a 
> daily basis with vars? If one or two people then I guess it does not make a 
> lot of sense to keep it around.
>
> On Mon, Nov 4, 2024 at 11:10 PM Ariel Weisberg  wrote:
>>
>> Hi,
>>
>> I don’t like `var` anywhere. Even if IntelliJ could automatically insert the 
>> concrete type it would still be a problem in the GH compare view. GH compare 
>> view is a real problem, because any time something is sufficiently 
>> obfuscated I have to bounce back and forth with an IDE, check out the code 
>> etc or just proceed with a weaker mental model of what is going on.
>>
>> I have finite mental energy to expend every day and I don’t want to spend it 
>> hunting down and then recalling what each instance of var means repeatedly. 
>> It uses almost no energy to read past extra type information (formatting 
>> means I don’t even need to parse it) or do a little extra typing/autocomplete
>>
>> Ariel
>>
>> On Tue, Oct 29, 2024, at 1:13 PM, Štefan Miklošovič wrote:
>>
>> Hello,
>>
>> this should give you an idea
>>
>>  grep --include '*.java' -r 'var ' src/ test/
>>
>> I think this is a new concept here which was introduced recently with 
>> support of Java 11 / Java 17 after we dropped 8.
>>
>> What is your opinion? Are we free to use it wherever we want? I am quite 
>> conservative in this area and I will most probably still use types as we 
>> know them but maybe in tests we might relax it a little bit? Or production 
>> code with "var" is totally fine too without any concerns? I think this 
>> should be covered by the code style.
>>
>> Regards
>>
>>

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

[Jaydeep Chovatia]

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 thread:
https://lists.apache.org/thread/nl8rmsyxxovryl3nnlt4mzrj9t0x66ln

As per the CEP process documentation, this vote will be open for 72 hours
(longer if needed).

Thanks,
Jaydeep

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

[Jon Haddad]

+1

On Tue, Nov 5, 2024 at 2:32 PM Brandon Williams  wrote:

> +1
>
> Kind Regards,
> Brandon
>
> On Tue, Nov 5, 2024 at 3:28 PM Jaydeep Chovatia
>  wrote:
> >
> > 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 thread:
> https://lists.apache.org/thread/nl8rmsyxxovryl3nnlt4mzrj9t0x66ln
> >
> > As per the CEP process documentation, this vote will be open for 72
> hours (longer if needed).
> >
> > Thanks,
> > Jaydeep
>

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

[Bernardo Botella]

+1 (non binding)

> On Nov 5, 2024, at 1:28 PM, Jaydeep Chovatia  
> wrote:
> 
> 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 thread: 
> https://lists.apache.org/thread/nl8rmsyxxovryl3nnlt4mzrj9t0x66ln
> 
> As per the CEP process documentation, this vote will be open for 72 hours 
> (longer if needed).
> 
> Thanks,
> Jaydeep

Re: Backporting CASSANDRA-17812 to 4.x

[Bernardo Botella]

+1 on back porting it

> On Nov 5, 2024, at 8:51 AM, Štefan Miklošovič  wrote:
> 
> Backporting in such a way that all auth requests will still go to the same 
> request executor as before is OK for me.
> 
> On Tue, Nov 5, 2024 at 3:32 PM J. D. Jordan  > wrote:
>> If I read the ticket correctly, this is preventing bcrypt of incoming 
>> credentials from causing a DOS?
>> I think that’s reasonable to backport.  If we want to be conservative it 
>> could be backported with added code that keeps the current behavior by 
>> default?
>> 
>>> On Nov 5, 2024, at 7:43 AM, Josh McKenzie >> > wrote:
>>> 
>>> 
>>> I'm neutral to the backport. In terms of the letter of the law, I can see 
>>> the argument either way of it being an improvement or a bugfix.
>>> 
>>> Definitely wouldn't -1 a backport.
>>> 
>>> On Tue, Nov 5, 2024, at 7:23 AM, Mick Semb Wever wrote:
 Can you please put the ticket description in the email.  Saves us having 
 to follow the link to know what you're talking about.
 
 Yes to backporting this.
 
 On Tue, 5 Nov 2024 at 10:27, Štefan Miklošovič >>> > wrote:
 Hello,
 
 I want to ask if there are objections for backporting CASSANDRA-17812 (1) 
 to 4.0.x and 4.1.x.
 
 There is a question already in that ticket about backporting from another 
 person and we keep being asked about this a lot. It seems to me that while 
 this is technically an improvement, it is so valuable that we should make 
 an exception here. 
 
 It is even security related.
 
 (1) https://issues.apache.org/jira/browse/CASSANDRA-17812
 
 Regards
>>> 

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

[Brandon Williams]

+1

Kind Regards,
Brandon

On Tue, Nov 5, 2024 at 3:28 PM Jaydeep Chovatia
 wrote:
>
> 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 thread: 
> https://lists.apache.org/thread/nl8rmsyxxovryl3nnlt4mzrj9t0x66ln
>
> As per the CEP process documentation, this vote will be open for 72 hours 
> (longer if needed).
>
> Thanks,
> Jaydeep

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

[David Capwell]

+1

> On Nov 5, 2024, at 1:34 PM, Mick Semb Wever  wrote:
> 
>   
> 
>> As per the CEP process documentation, this vote will be open for 72 hours 
>> (longer if needed).
> 
> 
> 
> 
> +1

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

[Dinesh Joshi]

+1

On Tue, Nov 5, 2024 at 1:28 PM Jaydeep Chovatia 
wrote:

> 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 thread:
> https://lists.apache.org/thread/nl8rmsyxxovryl3nnlt4mzrj9t0x66ln
>
> As per the CEP process documentation, this vote will be open for 72 hours
> (longer if needed).
>
> Thanks,
> Jaydeep
>

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

[Mick Semb Wever]

As per the CEP process documentation, this vote will be open for 72 hours
> (longer if needed).
>




+1

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

[Josh McKenzie]

+1

On Tue, Nov 5, 2024, at 4:28 PM, Jaydeep Chovatia wrote:
> 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 thread: 
> https://lists.apache.org/thread/nl8rmsyxxovryl3nnlt4mzrj9t0x66ln
> 
> As per the CEP process documentation, this vote will be open for 72 hours 
> (longer if needed).
> 
> Thanks,
> Jaydeep

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[guo Maxwell]

Any update on this ?If there are no updates, I wonder if we can start a new
update on the VOTE thread.

guo Maxwell  于2024年11月5日周二 19:23写道：

> Hello, everyone.
> I have a point of view that our CREATE TABLE LIKE grammar should not
> support the setting of table options, like :
>
>> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name WITH
>> TRIGGERS AND VIEWS AND compaction = { 'class' : 'LeveledCompactionStrategy'
>> } AND default_time_to_live = 86400;
>
> If the user wants to copy the table and set the compaction strategy for
> the new table, then he can execute the
> ALTER TABLE statement after copying the table.
>
> So, I think it’s enough to support the above five cases . The original
> intention of copying a table is to copy the table,
> and support what is to or not to copy during the copying process. Not
> changing the options at the same time.
>
> WDYT ?
>
> guo Maxwell  于2024年11月5日周二 14:07写道：
>
>> Hi，stefan and Dave,
>> I do not intend to implement the BNF of COPY TABLE based on the BNF of
>> CREATE TABLE. All table options are indeed copied by default. Therefore,
>> the following syntax is not supported:
>>
>> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name WITH
>>> TRIGGERS AND VIEWS AND compaction = { 'class' : 'LeveledCompactionStrategy'
>>> } AND default_time_to_live = 86400;
>>
>>
>> We can see that the above statement itself is very complicated because it
>> provides too many choices.
>> If we support individual settings of table options
>> (compaction/compression), what about other TRIGGER/INDEXS ? I tend to treat
>> the table, TRIGGER, INDEX, etc. as a whole and copy them uniformly. As for
>> their own attributes, such as table options, INDEX attributes, etc., they
>> can be copied and then set manually.
>>
>> So we only going to support :
>>
>>> 1.CREATE TABLE newks.newtable LIKE oldks.oldtable
>>> 2.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH ALL // this means
>>> copy indexes and triggers
>>> 3.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH INDEXES
>>> 4.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH TRIGGERS
>>> 5.CREATE TABLE newks.newtable LIKE oldks.oldtable WITH TRIGGERS AND
>>> INDEXES // equal to option 2.
>>
>>
>> Štefan Miklošovič  于2024年11月4日周一 23:31写道：
>>
>>> 1) Just mention that it will not be part of phase 1, I am OK if it will
>>> be delivered later.
>>>
>>> 2) If we had "ALL" introduced, then we would have something like this:
>>>
>>> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name
>>> WITH
>>> ALL
>>> AND compaction = { 'class' : 'LeveledCompactionStrategy' }
>>> AND default_time_to_live = 86400;
>>>
>>> I think this is a little bit "strange". It would make sense to add ALL
>>> if we have not had any "AND"s but mixing ALL and then adding AND with
>>> options is a little bit confusing.
>>>
>>> 3)
>>>
>>> Do I understand correctly that your CEP will make this possible? I do
>>> not want to go into the implementation details for now.
>>>
>>> CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name
>>> WITH TRIGGERS
>>> AND VIEWS
>>> AND compaction = { 'class' : 'LeveledCompactionStrategy' }
>>> AND default_time_to_live = 86400;
>>>
>>> In other words, it will copy all options from "cycling.cyclist_name"
>>> while it will be possible to override the options with whatever I want?
>>> Basically what Dave suggested.
>>>
>>>
>>> On Mon, Nov 4, 2024 at 4:21 PM guo Maxwell  wrote:
>>>
 Hi stefan
 1、yes, cross-keyspace copying will be much complicated than copying
 under same keyspace , but I think we can support it in the future , and I
 think it is under the scope of this CEP , so I add it .Or is it that the
 work planned for the next step should not be listed here for the time
 being?
 I don't know the rules very well here, and I hope if you can help point
 out the unreasonable points 😀 , because I do plan to complete this
 task, although I have only implemented the same keyspace now.
 2、yes, you are right, I gave up ALL at the first time , But after I
 replied to yifan’s email, I communicated with him privately through slack.
 In the end, I was not strongly opposed to ALL (Sorry, we communicated in
 Chinese,
 https://the-asf.slack.com/archives/D07SXB787HN/p1729136909357689), In
 addition, I later saw that you were +0, so I added ALL back.
 3、the change to Parse.g will be like :

> /**
>  * CREATE TABLE [IF NOT EXISTS] 
>  * LIKE 
>  * [ WITH OPTIONS AND INDEXES AND TRIGGERS ]
>  */
> copyTableStatement returns  [CopyTableStatement.Raw stmt]
> @init { boolean ifNotExists = false; }
> : K_CREATE K_COLUMNFAMILY newCf=columnFamilyName LIKE 
> oldCf=columnFamilyName
>   { $stmt = new CopyTableStatement.Raw(newCf, oldCf); }
>   tableLikeOptions[stmt]
> ;
>
> tableLikeOptions[CopyTableStatement.Raw stmt]
> : ( K_WITH tableLikeSingleOption[stmt