[jira] [Commented] (CASSANDRA-17466) Shut repair task executor down without interruption to avoid compromising shared channel proxies
[
https://issues.apache.org/jira/browse/CASSANDRA-17466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514440#comment-17514440
]
Berenguer Blasi commented on CASSANDRA-17466:
-
Thx for checking [~maedhroz]!
> Shut repair task executor down without interruption to avoid compromising
> shared channel proxies
>
>
> Key: CASSANDRA-17466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1, 4.0.4
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> If a {{RepairJob}} gets past validation, it builds a list of {{SyncTask}}
> items and fires them off. If any one of those fails, we grab the relevant
> exception and throw it up from {{RepairJob}} to {{RepairSession}}.
> {noformat}
> ERROR 2022-03-09T23:53:36,721
> [Stream-Deserializer-/10.246.3.102:7000-d97958c4]
> org.apache.cassandra.streaming.StreamSession:1110 - [Stream
> #07c55da0-a047-11ec-8122-ab911c7a993f] Remote peer /10.246.3.102:7000 failed
> stream session.
> {noformat}
> {{RepairSession}} then marks itself as being terminated and clears its
> internal maps of active validations and sync tasks, but immediately before it
> does that, it calls {{shutdownNow()}} on the executor that executes those
> tasks. In the case of our failing stream session, we may still have other
> running stream tasks whose threads' interrupt flag has been set, and this can
> have some unintended negative consequences, because any {{ChannelProxy}}
> interrupted in the middle of a blocking operation will both be closed and
> throw a {{ClosedByInterruptException}}. (Keep in mind that we share
> {{ChannelProxy}} instances outside a few specific cases, like those
> introduced in CASSANDRA-15666.)
> We've seen this manifest in production in a couple ways, both of them while
> trying to read from the {{peers_v2}} system table:
> {noformat}
> Exception in thread Thread[RepairJobTask:23,5,main]"^M
> exception="FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-99-big-Data.db
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.getFileDataInput(SSTableReader.java:1628)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.(AbstractSSTableIterator.java:96)
> at
> org.apache.cassandra.db.columniterator.SSTableIterator.(SSTableIterator.java:48)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableReader.iterator(BigTableReader.java:75)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableReader.iterator(BigTableReader.java:67)
> at
> org.apache.cassandra.db.StorageHook$1.makeRowIterator(StorageHook.java:87)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndSSTablesInTimestampOrder(SinglePartitionReadCommand.java:897)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(SinglePartitionReadCommand.java:605)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDisk(SinglePartitionReadCommand.java:578)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryStorage(SinglePartitionReadCommand.java:412)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:414)
> at
> org.apache.cassandra.db.SinglePartitionReadQuery$Group.executeLocally(SinglePartitionReadQuery.java:242)
> at
> org.apache.cassandra.db.SinglePartitionReadQuery$Group.executeInternal(SinglePartitionReadQuery.java:216)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:458)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeLocally(SelectStatement.java:442)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeLocally(SelectStatement.java:96)
> at
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:334)
> at
>
[jira] [Commented] (CASSANDRA-17446) DOC - Update 3.11 Backups page to use nodetool refresh instead of import
[ https://issues.apache.org/jira/browse/CASSANDRA-17446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514411#comment-17514411 ] Erick Ramirez commented on CASSANDRA-17446: --- Thanks, [~chienfuchen32] ! I'll get this merged soon. > DOC - Update 3.11 Backups page to use nodetool refresh instead of import > > > Key: CASSANDRA-17446 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17446 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Chien-Fu Chen >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.12 > > Time Spent: 10m > Remaining Estimate: 0h > > I've found a typo shown in official Cassandra website when I was looking for > Cassandra backup & restore solution. I believe there's no nodetool import > option available. It might be nodetool refresh? > [https://cassandra.apache.org/doc/3.11/cassandra/operating/backups.html] > h2. [Restoring from Incremental Backups and > Snapshots|https://cassandra.apache.org/doc/3.11/cassandra/operating/backups.html#restoring-from-incremental-backups-and-snapshots] > The two main tools/commands for restoring a table after it has been dropped > are: > * sstableloader > * nodetool import > Ref: > [https://cassandra.apache.org/doc/3.11/cassandra/tools/nodetool/refresh.html] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17416) Test Failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testCDCIndexFileWriteOnSync
[ https://issues.apache.org/jira/browse/CASSANDRA-17416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514407#comment-17514407 ] Ekaterina Dimitrova commented on CASSANDRA-17416: - I don't see a reason for this one to stay in triage, I keep on seeing it on trunk > Test Failure: > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testCDCIndexFileWriteOnSync > -- > > Key: CASSANDRA-17416 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17416 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/985/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testCDCIndexFileWriteOnSync_cdc_3/] > h3. Error Message > expected:<1748956> but was:<1749196> > h3. Stacktrace > junit.framework.AssertionFailedError: expected:<1748956> but was:<1749196> at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testCDCIndexFileWriteOnSync(CommitLogSegmentManagerCDCTest.java:160) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > h3. Standard Output > INFO [main] 2022-03-02 15:04:59,516 YamlConfigurationLoader.java:103 - > Configuration location: > file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml DEBUG [main] > 2022-03-02 15:04:59,520 YamlConfigurationLoader.java:124 - Loading settings > from file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml INFO > [main] 2022-03-02 15:04:59,674 Config.java:907 - Node > configuration:[allocate_tokens_for_keyspace=null; > allocate_tokens_for_local_replication_factor=null; allow_extra_insecure_ > ...[truncated 4125855 chars]... -02 15:06:57,491 PathUtils.java:73 - Deleting > file during startup: > /home/cassandra/cassandra/build/test/cassandra/data/system_schema/views-9786ac1cdd583201a7cdad556410c985/nb-11-big-Summary.db > DEBUG [MemtableFlushWriter:2] 2022-03-02 15:06:57,496 > ColumnFamilyStore.java:1207 - Flushed to > [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb-55-big-Data.db')] > (1 sstables, 4.895KiB), biggest 4.895KiB, smallest 4.895KiB -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17416) Test Failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testCDCIndexFileWriteOnSync
[ https://issues.apache.org/jira/browse/CASSANDRA-17416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17416: Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Test Failure: > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testCDCIndexFileWriteOnSync > -- > > Key: CASSANDRA-17416 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17416 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Marcus Eriksson >Priority: Normal > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/985/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testCDCIndexFileWriteOnSync_cdc_3/] > h3. Error Message > expected:<1748956> but was:<1749196> > h3. Stacktrace > junit.framework.AssertionFailedError: expected:<1748956> but was:<1749196> at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testCDCIndexFileWriteOnSync(CommitLogSegmentManagerCDCTest.java:160) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > h3. Standard Output > INFO [main] 2022-03-02 15:04:59,516 YamlConfigurationLoader.java:103 - > Configuration location: > file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml DEBUG [main] > 2022-03-02 15:04:59,520 YamlConfigurationLoader.java:124 - Loading settings > from file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml INFO > [main] 2022-03-02 15:04:59,674 Config.java:907 - Node > configuration:[allocate_tokens_for_keyspace=null; > allocate_tokens_for_local_replication_factor=null; allow_extra_insecure_ > ...[truncated 4125855 chars]... -02 15:06:57,491 PathUtils.java:73 - Deleting > file during startup: > /home/cassandra/cassandra/build/test/cassandra/data/system_schema/views-9786ac1cdd583201a7cdad556410c985/nb-11-big-Summary.db > DEBUG [MemtableFlushWriter:2] 2022-03-02 15:06:57,496 > ColumnFamilyStore.java:1207 - Flushed to > [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb-55-big-Data.db')] > (1 sstables, 4.895KiB), biggest 4.895KiB, smallest 4.895KiB -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17416) Test Failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testCDCIndexFileWriteOnSync
[ https://issues.apache.org/jira/browse/CASSANDRA-17416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17416: Fix Version/s: 4.x > Test Failure: > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testCDCIndexFileWriteOnSync > -- > > Key: CASSANDRA-17416 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17416 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/985/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testCDCIndexFileWriteOnSync_cdc_3/] > h3. Error Message > expected:<1748956> but was:<1749196> > h3. Stacktrace > junit.framework.AssertionFailedError: expected:<1748956> but was:<1749196> at > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testCDCIndexFileWriteOnSync(CommitLogSegmentManagerCDCTest.java:160) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > h3. Standard Output > INFO [main] 2022-03-02 15:04:59,516 YamlConfigurationLoader.java:103 - > Configuration location: > file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml DEBUG [main] > 2022-03-02 15:04:59,520 YamlConfigurationLoader.java:124 - Loading settings > from file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml INFO > [main] 2022-03-02 15:04:59,674 Config.java:907 - Node > configuration:[allocate_tokens_for_keyspace=null; > allocate_tokens_for_local_replication_factor=null; allow_extra_insecure_ > ...[truncated 4125855 chars]... -02 15:06:57,491 PathUtils.java:73 - Deleting > file during startup: > /home/cassandra/cassandra/build/test/cassandra/data/system_schema/views-9786ac1cdd583201a7cdad556410c985/nb-11-big-Summary.db > DEBUG [MemtableFlushWriter:2] 2022-03-02 15:06:57,496 > ColumnFamilyStore.java:1207 - Flushed to > [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb-55-big-Data.db')] > (1 sstables, 4.895KiB), biggest 4.895KiB, smallest 4.895KiB -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
[ https://issues.apache.org/jira/browse/CASSANDRASC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-35: - Fix Version/s: 1.0 Source Control Link: https://github.com/apache/cassandra-sidecar/commit/bc219cbf75bdbfdc7a95b3160ef17332c9274b44 Resolution: Fixed Status: Resolved (was: Ready to Commit) Merged into trunk as [bc219cbf7|https://github.com/apache/cassandra-sidecar/commit/bc219cbf75bdbfdc7a95b3160ef17332c9274b44] > Document the contribution guidelines and best practices for the project > --- > > Key: CASSANDRASC-35 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > Fix For: 1.0 > > > We need a document that lays out the contribution guidelines, source code > best practices, and source code style -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-sidecar] branch trunk updated: Add the CONTRIBUTING.md doc with guidelines and best practices
This is an automated email from the ASF dual-hosted git repository. ycai pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-sidecar.git The following commit(s) were added to refs/heads/trunk by this push: new bc219cb Add the CONTRIBUTING.md doc with guidelines and best practices bc219cb is described below commit bc219cbf75bdbfdc7a95b3160ef17332c9274b44 Author: Francisco Guerrero AuthorDate: Tue Mar 29 12:09:06 2022 -0700 Add the CONTRIBUTING.md doc with guidelines and best practices The document delves into the contribution guidelines, source code best practices and source code style. --- CONTRIBUTING.md | 329 README.md | 9 +- 2 files changed, 336 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000..679eb6b --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,329 @@ +# Contributing to Apache Cassandra Sidecar + +We warmly welcome and appreciate contributions from the community. + +## Table of Contents + +* [How to Contribute](#how-to-contribute) + * [Discuss](#discuss) + * [Create a Ticket](#ticket) +* [Source Code Best Practices](#best-practices) + * [Asynchronous Programming](#async-programming) + * [Thread Pool Model](#thread-pools) + * [One-shot Timers and Periodic Timers](#timers) + * [RestEasy Integration](#resteasy) + * [Dependency Injection](#guice) + * [Handler Chaining](#chaining-handlers) + * [Asynchronous Handlers](#async-handlers) + * [Future Composition](#future-composition) + * [Failure Handling](#failure-handling) +* [Source Code Style](#source-code-style) + +## How to Contribute + +### Discuss + +Find an existing issue on Jira, or start a new discussing in the Apache Cassandra mailing list. + +### Create a Ticket + +Before creating a ticket, please take the time to [research first](#discuss). + +If you are creating a new Jira after a discussion on the Apache Cassandra mailing list, please provide a +self-sufficient description in the ticket. This is certainly extra work, but Jira is the place where we capture +important design discussions and decisions that can often be referenced after the fix version, to understand +the origin of a feature, understand design decisions, and so on. + +When ready create a Jira ticket. + +## Source Code Best Practices + +The Apache Cassandra Sidecar project uses the [vertx](https://vertx.io) toolkit. It uses the asynchronous and +reactive programming paradigm. This allows for Sidecar to scale up as workloads grow, as well as resiliency when +failures arise. + + +In a traditional application server, a pool of threads is used to receive request. Each request is handled by a +distinct thread. This model is well suited for small-medium workloads. As workloads grow, applications need to scale +horizontally because of hardware limits on the number of threads that can be created. + +### Asynchronous Programming + +In the Asynchronous Programming model, the same hardware is able to handle more requests. This model uses fewer threads +to process incoming connections. When blocking I/O operations occur, the thread moves on to the next task (handling +a different request for example), and then once the I/O operation has completed the thread will come back to the +initial task. + +Vertx multiplexes concurrent workloads using event loops. This allows taking advantage of the existing hardware more +effectively to handle more requests. + +Any blocking I/O or CPU intensive processing needs to be handled outside the event loop threads. NEVER BLOCK THE +EVENT LOOP THREAD! + +### Thread Pool Model + +Vertx uses different thread pools for internal processing. By default, vertx will use the event loop thread pool, +the worker thread pool, and the internal worker thread pool. + + The event loop thread pool (i.e. vert.x-eventloop-thread-1) + +The event loop thread pool threads handle events for processing. When the event comes in, it is dispatched to a +handler. It is expected that the processing will be complete quickly per event. If it doesn't you will see log +entries warning you that the event loop thread has been blocked. Vertx provisions a thread to detect blocked threads +in the execution. + +``` +Thread vertx-eventloop-thread-3 has been blocked for 20458 ms +``` + +If you see log entries like the one above, make sure to audit your code to understand your code and what is +causing your code to block the event pool thread. Consider moving the blocking I/O operations or CPU-intensive +operations to a worker thread pool. + + The worker thread pool (i.e. vert.x-worker-thread-1) + +This thread pool is dedicated to handling blocking I/O operations or CPU-intensive operations that might block +event loop threads. By default, the thread pool has 20 threads. The number of worker threads can be configured +when configuring the `DeploymentOptions` for
[jira] [Commented] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
[ https://issues.apache.org/jira/browse/CASSANDRASC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514400#comment-17514400 ] Yifan Cai commented on CASSANDRASC-35: -- +1 Thanks for putting together the contribution doc. > Document the contribution guidelines and best practices for the project > --- > > Key: CASSANDRASC-35 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > We need a document that lays out the contribution guidelines, source code > best practices, and source code style -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17446) DOC - Update 3.11 Backups page to use nodetool refresh instead of import
[ https://issues.apache.org/jira/browse/CASSANDRA-17446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514395#comment-17514395 ] Chien-Fu Chen commented on CASSANDRA-17446: --- Is it okay to update doc like this? thanks https://github.com/apache/cassandra/pull/1504 > DOC - Update 3.11 Backups page to use nodetool refresh instead of import > > > Key: CASSANDRA-17446 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17446 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Chien-Fu Chen >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.12 > > Time Spent: 10m > Remaining Estimate: 0h > > I've found a typo shown in official Cassandra website when I was looking for > Cassandra backup & restore solution. I believe there's no nodetool import > option available. It might be nodetool refresh? > [https://cassandra.apache.org/doc/3.11/cassandra/operating/backups.html] > h2. [Restoring from Incremental Backups and > Snapshots|https://cassandra.apache.org/doc/3.11/cassandra/operating/backups.html#restoring-from-incremental-backups-and-snapshots] > The two main tools/commands for restoring a table after it has been dropped > are: > * sstableloader > * nodetool import > Ref: > [https://cassandra.apache.org/doc/3.11/cassandra/tools/nodetool/refresh.html] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17458) Test Failure: org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
[
https://issues.apache.org/jira/browse/CASSANDRA-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sathyanarayanan Saravanamuthu updated CASSANDRA-17458:
--
Labels: patch-available (was: )
> Test Failure:
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
> ---
>
> Key: CASSANDRA-17458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17458
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Sathyanarayanan Saravanamuthu
>Priority: Normal
> Labels: patch-available
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Intermittent failure on
> {{org.apache.cassandra.db.SinglePartitionSliceCommandTest#testPartitionDeletionRangeDeletionTie}}
> for trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1018/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> {code:java}
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> Error Message
> Expected [Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11]] but got [Marker
> INCL_START_BOUND(1, 1)@10/1647704834, Row[info=[ts=11] ]: c1=1, c2=1 | [v=1
> ts=11], Marker INCL_END_BOUND(1, 1)@10/1647704834] expected:<[[[v=1 ts=11]]]>
> but was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73,
> [[v=1 ts=11]],
> org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> Stacktrace
> junit.framework.AssertionFailedError: Expected [Row[info=[ts=11] ]: c1=1,
> c2=1 | [v=1 ts=11]] but got [Marker INCL_START_BOUND(1, 1)@10/1647704834,
> Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11], Marker INCL_END_BOUND(1,
> 1)@10/1647704834] expected:<[[[v=1 ts=11]]]> but
> was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73, [[v=1
> ts=11]], org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> at
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie(SinglePartitionSliceCommandTest.java:463)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-03-19 15:51:43,646 YamlConfigurationLoader.java:103 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2022-03-19 15:51:43,653 YamlConfigurationLoader.java:124 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> INFO [main] 2022-03-19 15:51:43,971 Config.java:1119 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null;
> allow_extra_insecure_udfs=false; all
> ...[truncated 192995 chars]...
> ome/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-37-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-39-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-38-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-40-big-Data.db:level=0,
> ]
> {code}
> Failures can also be hit with CircleCI test multiplexer:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1387/workflows/0f37a726-1dc2-4584-86f9-e99ecc40f551]
> CircleCI results show failures on three separate assertions, with a ~3%
> flakiness.
> The same test looks ok in 4.0, as suggested by Butler and [this repeated
> Circle
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1388/workflows/6b69d654-3d19-4f2a-aeb9-dc405c6ddd2b].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17458) Test Failure: org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
[
https://issues.apache.org/jira/browse/CASSANDRA-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514386#comment-17514386
]
Sathyanarayanan Saravanamuthu commented on CASSANDRA-17458:
---
Thanks [~brandon.williams] , [~adelapena] , I had triggered 200 iterations. The
tests passed:
https://app.circleci.com/pipelines/github/sathyakplm/cassandra/4/workflows/76f67a54-adb4-41c1-948d-1ebf6d281991/jobs/2/tests
> Test Failure:
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
> ---
>
> Key: CASSANDRA-17458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17458
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Sathyanarayanan Saravanamuthu
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Intermittent failure on
> {{org.apache.cassandra.db.SinglePartitionSliceCommandTest#testPartitionDeletionRangeDeletionTie}}
> for trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1018/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> {code:java}
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> Error Message
> Expected [Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11]] but got [Marker
> INCL_START_BOUND(1, 1)@10/1647704834, Row[info=[ts=11] ]: c1=1, c2=1 | [v=1
> ts=11], Marker INCL_END_BOUND(1, 1)@10/1647704834] expected:<[[[v=1 ts=11]]]>
> but was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73,
> [[v=1 ts=11]],
> org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> Stacktrace
> junit.framework.AssertionFailedError: Expected [Row[info=[ts=11] ]: c1=1,
> c2=1 | [v=1 ts=11]] but got [Marker INCL_START_BOUND(1, 1)@10/1647704834,
> Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11], Marker INCL_END_BOUND(1,
> 1)@10/1647704834] expected:<[[[v=1 ts=11]]]> but
> was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73, [[v=1
> ts=11]], org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> at
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie(SinglePartitionSliceCommandTest.java:463)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-03-19 15:51:43,646 YamlConfigurationLoader.java:103 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2022-03-19 15:51:43,653 YamlConfigurationLoader.java:124 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> INFO [main] 2022-03-19 15:51:43,971 Config.java:1119 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null;
> allow_extra_insecure_udfs=false; all
> ...[truncated 192995 chars]...
> ome/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-37-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-39-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-38-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-40-big-Data.db:level=0,
> ]
> {code}
> Failures can also be hit with CircleCI test multiplexer:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1387/workflows/0f37a726-1dc2-4584-86f9-e99ecc40f551]
> CircleCI results show failures on three separate assertions, with a ~3%
> flakiness.
> The same test looks ok in 4.0, as suggested by Butler and [this repeated
> Circle
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1388/workflows/6b69d654-3d19-4f2a-aeb9-dc405c6ddd2b].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514380#comment-17514380
]
David Capwell commented on CASSANDRA-15399:
---
I am running this code on a cluster to confirm repair tables link and work with
information I have while debugging, so far biggest gap is streaming (will deal
with after this merges).
Think this is finally ready, leaving the cluster running for a few days to make
sure stable as well.
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id) )
> )
> {code}
> repair_tasks - represents RepairJob and participants state. This will show
> if validations are running on participants and the progress they are making;
> this should be called on the coordinator.
> {code:sql}
> CREATE TABLE repair_tasks (
> id uuid,
> session_id uuid,
> keyspace_name text,
> table_name text,
> ranges frozen>,
> coordinator text,
> participant text,
> state text,
> state_description text,
> progress_percentage float, -- between 0.0 and 100.0
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name, participant )
> )
> {code}
> repair_validations - shows the state of the validation task and updated
> periodically while validation is running; this should be called on the
> participants.
> {code:sql}
> CREATE TABLE repair_validations (
> id uuid,
> session_id uuid,
> ranges frozen>,
> keyspace_name text,
> table_name text,
> initiator text,
> state text,
> progress_percentage float,
> queue_duration_ms bigint,
> runtime_duration_ms bigint,
> total_duration_ms bigint,
> estimated_partitions bigint,
> partitions_processed bigint,
> estimated_total_bytes bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name )
> )
> {code}
> The main reason for exposing virtual tables rather than exposing through
> durable tables is to make sure what is exposed is accurate. In cases of
> write failures or node failures, the durable tables could become in-accurate
> and could add edge cases where the repair is not running but the tables say
> it is; by relying on repair's internal in-memory bookkeeping, these problems
> go away.
> This jira does not try to solve the following:
> 1) repair resiliency - there are edge cases where repair hits an error and
> runs forever (at least from nodetool's perspective).
> 2) repair stream tracking - I have not learned the streaming side yet and
> what I see is multiple implementations exist, so seems like high scope. My
> hope is to punt from this jira and tackle separately.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514369#comment-17514369
]
David Capwell edited comment on CASSANDRA-15399 at 3/30/22, 12:38 AM:
--
There are 2 types of tables: *coordinator*, *participate*; here are examples
from both sides
*Participate* (host involved in the repair, this may be the coordinator, but
would include all peers involved in the repair)
{code}
cqlsh> SELECT * FROM system_views.repair_participates WHERE tables CONTAINS
'tlp_stress.clusteringslicing' ALLOW FILTERING;
@ Row 1
-+
id | 584eca30-afb6-11ec-9bff-cd38a4d988d3
duration_millis | 14773
failure_cause | null
global | True
incremental | False
last_updated_at | 2022-03-29 23:17:18.993000+
preview_kind| NONE
ranges | ['(-3074457345618258603,0]']
repaired_at | null
state_failure_timestamp | null
state_init_timestamp| 2022-03-29 23:17:04.22+
state_skipped_timestamp | null
state_success_timestamp | 2022-03-29 23:17:18.993000+
success_message | Cleanup message recieved
tables | {'tlp_stress.clusteringslicing'}
validations | {0034e064-b54a-384f-99d0-af1bf42844a4}
(1 rows)
cqlsh> SELECT * FROM system_views.repair_validations WJERE
id=0034e064-b54a-384f-99d0-af1bf42844a4; -- id from validations field above
@ Row 1
---+--
id| 0034e064-b54a-384f-99d0-af1bf42844a4
duration_millis | 14688
estimated_partitions | 897
estimated_total_bytes | 2321697131
failure_cause | null
initiator | /127.0.0.1:7000
keyspace_name | tlp_stress
last_updated_at | 2022-03-29 23:17:18.916000+
partitions_processed | 181
progress_percentage | 100
ranges| ['(-3074457345618258603,0]']
repair_id | 584eca30-afb6-11ec-9bff-cd38a4d988d3
session_id| 58509ef0-afb6-11ec-9bff-cd38a4d988d3
state_failure_timestamp | null
state_init_timestamp | 2022-03-29 23:17:04.228000+
state_sending_trees_timestamp | 2022-03-29 23:17:18.916000+
state_skipped_timestamp | null
state_start_timestamp | 2022-03-29 23:17:04.299000+
state_success_timestamp | 2022-03-29 23:17:18.916000+
status| success
success_message | null
table_name| clusteringslicing
(1 rows)
{code}
Missing
* Linking with system_views.streaming, my plan is to update repair/streaming to
support deep linking after this patch is merged (need to modify network
messages for remote repair + streaming, so repair knows stream ids, and stream
knows repair id)
* initiator in participates (updated patch to include this)
*Coordinator*
{code}
cqlsh> SELECT * FROM system_views.repairs WHERE table_names CONTAINS
'clusteringslicing' ALLOW FILTERING;
@ Row 1
---+--
id| 34424630-afb6-11ec-ab62-fb846f906c0a
command_id| 2
duration_millis | 7799
failure_cause | null
keyspace_name | tlp_stress
last_updated_at | 2022-03-29 23:16:11.53+
options_column_families | {}
options_data_centers | {}
options_force_repair | False
options_hosts | {}
options_ignore_unreplicated_keyspaces | False
options_incremental | null
options_job_threads | 1
options_optimise_streams | False
options_parallelism | PARALLEL
options_preview_kind | NONE
options_primary_range | True
options_pull_repair | False
options_ranges|
{'(6148914691236517205,-9223372036854775808]'}
options_subrange_repair | False
options_trace | False
participants | ['/127.0.0.1:7000', '/127.0.0.2:7000']
ranges|
[['(6148914691236517205,-9223372036854775808]']]
sessions | {34441af0-afb6-11ec-ab62-fb846f906c0a}
state_failure_timestamp | null
state_init_timestamp | 2022-03-29 23:16:03.731000+
state_prepare_complete_timestamp | 2022-03-29 23:16:03.741000+
state_prepare_start_timestamp | 2022-03-29 23:16:03.737000+
[jira] [Comment Edited] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514369#comment-17514369
]
David Capwell edited comment on CASSANDRA-15399 at 3/30/22, 12:11 AM:
--
There are 2 types of tables: *coordinator*, *participate*; here are examples
from both sides
*Participate* (host involved in the repair, this may be the coordinator, but
would include all peers involved in the repair)
{code}
cqlsh> SELECT * FROM system_views.repair_participates WHERE tables CONTAINS
'tlp_stress.clusteringslicing' ALLOW FILTERING;
@ Row 1
-+
id | 584eca30-afb6-11ec-9bff-cd38a4d988d3
duration_millis | 14773
failure_cause | null
global | True
incremental | False
last_updated_at | 2022-03-29 23:17:18.993000+
preview_kind| NONE
ranges | ['(-3074457345618258603,0]']
repaired_at | null
state_failure_timestamp | null
state_init_timestamp| 2022-03-29 23:17:04.22+
state_skipped_timestamp | null
state_success_timestamp | 2022-03-29 23:17:18.993000+
success_message | Cleanup message recieved
tables | {'tlp_stress.clusteringslicing'}
validations | {0034e064-b54a-384f-99d0-af1bf42844a4}
(1 rows)
cqlsh> SELECT * FROM system_views.repair_validations WJERE
id=0034e064-b54a-384f-99d0-af1bf42844a4; -- id from validations field above
@ Row 1
---+--
id| 0034e064-b54a-384f-99d0-af1bf42844a4
duration_millis | 14688
estimated_partitions | 897
estimated_total_bytes | 2321697131
failure_cause | null
initiator | /127.0.0.1:7000
keyspace_name | tlp_stress
last_updated_at | 2022-03-29 23:17:18.916000+
partitions_processed | 181
progress_percentage | 100
ranges| ['(-3074457345618258603,0]']
repair_id | 584eca30-afb6-11ec-9bff-cd38a4d988d3
session_id| 58509ef0-afb6-11ec-9bff-cd38a4d988d3
state_failure_timestamp | null
state_init_timestamp | 2022-03-29 23:17:04.228000+
state_sending_trees_timestamp | 2022-03-29 23:17:18.916000+
state_skipped_timestamp | null
state_start_timestamp | 2022-03-29 23:17:04.299000+
state_success_timestamp | 2022-03-29 23:17:18.916000+
status| success
success_message | null
table_name| clusteringslicing
(1 rows)
{code}
Missing
* Linking with system_views.streaming, my plan is to update repair/streaming to
support deep linking after this patch is merged (need to modify network
messages for remote repair + streaming, so repair knows stream ids, and stream
knows repair id)
* initiator in participates (updated patch to include this)
*Coordinator*
{code}
cqlsh> SELECT * FROM system_views.repairs WHERE table_names CONTAINS
'clusteringslicing' ALLOW FILTERING;
@ Row 1
---+--
id| 34424630-afb6-11ec-ab62-fb846f906c0a
command_id| 2
duration_millis | 7799
failure_cause | null
keyspace_name | tlp_stress
last_updated_at | 2022-03-29 23:16:11.53+
options_column_families | {}
options_data_centers | {}
options_force_repair | False
options_hosts | {}
options_ignore_unreplicated_keyspaces | False
options_incremental | null
options_job_threads | 1
options_optimise_streams | False
options_parallelism | PARALLEL
options_preview_kind | NONE
options_primary_range | True
options_pull_repair | False
options_ranges|
{'(6148914691236517205,-9223372036854775808]'}
options_subrange_repair | False
options_trace | False
participants | ['/127.0.0.1:7000', '/127.0.0.2:7000']
ranges|
[['(6148914691236517205,-9223372036854775808]']]
sessions | {34441af0-afb6-11ec-ab62-fb846f906c0a}
state_failure_timestamp | null
state_init_timestamp | 2022-03-29 23:16:03.731000+
state_prepare_complete_timestamp | 2022-03-29 23:16:03.741000+
state_prepare_start_timestamp | 2022-03-29 23:16:03.737000+
[jira] [Comment Edited] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514369#comment-17514369
]
David Capwell edited comment on CASSANDRA-15399 at 3/29/22, 11:58 PM:
--
There are 2 types of tables: *coordinator*, *participate*; here are examples
from both sides
*Participate* (host involved in the repair, this may be the coordinator, but
would include all peers involved in the repair)
{code}
cqlsh> SELECT * FROM system_views.repair_participates WHERE tables CONTAINS
'tlp_stress.clusteringslicing' ALLOW FILTERING;
@ Row 1
-+
id | 584eca30-afb6-11ec-9bff-cd38a4d988d3
duration_millis | 14773
failure_cause | null
global | True
incremental | False
last_updated_at | 2022-03-29 23:17:18.993000+
preview_kind| NONE
ranges | ['(-3074457345618258603,0]']
repaired_at | null
state_failure_timestamp | null
state_init_timestamp| 2022-03-29 23:17:04.22+
state_skipped_timestamp | null
state_success_timestamp | 2022-03-29 23:17:18.993000+
success_message | Cleanup message recieved
tables | {'tlp_stress.clusteringslicing'}
validations | {0034e064-b54a-384f-99d0-af1bf42844a4}
(1 rows)
cqlsh> SELECT * FROM system_views.repair_validations WJERE
id=0034e064-b54a-384f-99d0-af1bf42844a4; -- id from validations field above
@ Row 1
---+--
id| 0034e064-b54a-384f-99d0-af1bf42844a4
duration_millis | 14688
estimated_partitions | 897
estimated_total_bytes | 2321697131
failure_cause | null
initiator | /127.0.0.1:7000
keyspace_name | tlp_stress
last_updated_at | 2022-03-29 23:17:18.916000+
partitions_processed | 181
progress_percentage | 100
ranges| ['(-3074457345618258603,0]']
repair_id | 584eca30-afb6-11ec-9bff-cd38a4d988d3
session_id| 58509ef0-afb6-11ec-9bff-cd38a4d988d3
state_failure_timestamp | null
state_init_timestamp | 2022-03-29 23:17:04.228000+
state_sending_trees_timestamp | 2022-03-29 23:17:18.916000+
state_skipped_timestamp | null
state_start_timestamp | 2022-03-29 23:17:04.299000+
state_success_timestamp | 2022-03-29 23:17:18.916000+
status| success
success_message | null
table_name| clusteringslicing
(1 rows)
{code}
Missing
* Linking with system_views.streaming, my plan is to update repair/streaming to
support deep linking after this patch is merged (need to modify network
messages for remote repair + streaming, so repair knows stream ids, and stream
knows repair id)
* initiator in participates
*Coordinator*
{code}
cqlsh> SELECT * FROM system_views.repairs WHERE table_names CONTAINS
'clusteringslicing' ALLOW FILTERING;
@ Row 1
---+--
id| 34424630-afb6-11ec-ab62-fb846f906c0a
command_id| 2
duration_millis | 7799
failure_cause | null
keyspace_name | tlp_stress
last_updated_at | 2022-03-29 23:16:11.53+
options_column_families | {}
options_data_centers | {}
options_force_repair | False
options_hosts | {}
options_ignore_unreplicated_keyspaces | False
options_incremental | null
options_job_threads | 1
options_optimise_streams | False
options_parallelism | PARALLEL
options_preview_kind | NONE
options_primary_range | True
options_pull_repair | False
options_ranges|
{'(6148914691236517205,-9223372036854775808]'}
options_subrange_repair | False
options_trace | False
participants | ['/127.0.0.1:7000', '/127.0.0.2:7000']
ranges|
[['(6148914691236517205,-9223372036854775808]']]
sessions | {34441af0-afb6-11ec-ab62-fb846f906c0a}
state_failure_timestamp | null
state_init_timestamp | 2022-03-29 23:16:03.731000+
state_prepare_complete_timestamp | 2022-03-29 23:16:03.741000+
state_prepare_start_timestamp | 2022-03-29 23:16:03.737000+
state_repair_complete_timestamp | 2022-03-29
[jira] [Commented] (CASSANDRA-17499) Remove global Guardrails Enable flag
[ https://issues.apache.org/jira/browse/CASSANDRA-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514371#comment-17514371 ] Paulo Motta commented on CASSANDRA-17499: - Can you elaborate on why we need to remove the ability of globally disabling guardrails? If someone choses to disable guardrails, then it would also disable the maximum replication factor settings. Why is this a problem? > Remove global Guardrails Enable flag > > > Key: CASSANDRA-17499 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17499 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > This ticket removes the global Guardrails enable flag. Currently the flag > turns all Guardrails on and off regardless of the individual setting of the > guardrail property. This presents a problem for maximum replication factor > and minimum replication factor configurations which will soon be moved to > guardrails. Those configurations will always need to be enabled so no > problems arise as Cassandra users create keyspaces. This ensures all > Guardrail properties follow the same enable / disable procedure. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514369#comment-17514369
]
David Capwell edited comment on CASSANDRA-15399 at 3/29/22, 11:51 PM:
--
There are 2 types of tables: *coordinator*, *participate*; here are examples
from both sides
*Participate* (host involved in the repair, this may be the coordinator, but
would include all peers involved in the repair)
{code}
cqlsh> SELECT * FROM system_views.repair_participates WHERE tables CONTAINS
'tlp_stress.clusteringslicing' ALLOW FILTERING;
@ Row 1
-+
id | 584eca30-afb6-11ec-9bff-cd38a4d988d3
duration_millis | 14773
failure_cause | null
global | True
incremental | False
last_updated_at | 2022-03-29 23:17:18.993000+
preview_kind| NONE
ranges | ['(-3074457345618258603,0]']
repaired_at | null
state_failure_timestamp | null
state_init_timestamp| 2022-03-29 23:17:04.22+
state_skipped_timestamp | null
state_success_timestamp | 2022-03-29 23:17:18.993000+
success_message | Cleanup message recieved
tables | {'tlp_stress.clusteringslicing'}
validations | {0034e064-b54a-384f-99d0-af1bf42844a4}
(1 rows)
cqlsh> SELECT * FROM system_views.repair_validations WJERE
id=0034e064-b54a-384f-99d0-af1bf42844a4; -- id from validations field above
@ Row 1
---+--
id| 0034e064-b54a-384f-99d0-af1bf42844a4
duration_millis | 14688
estimated_partitions | 897
estimated_total_bytes | 2321697131
failure_cause | null
initiator | /127.0.0.1:7000
keyspace_name | tlp_stress
last_updated_at | 2022-03-29 23:17:18.916000+
partitions_processed | 181
progress_percentage | 100
ranges| ['(-3074457345618258603,0]']
repair_id | 584eca30-afb6-11ec-9bff-cd38a4d988d3
session_id| 58509ef0-afb6-11ec-9bff-cd38a4d988d3
state_failure_timestamp | null
state_init_timestamp | 2022-03-29 23:17:04.228000+
state_sending_trees_timestamp | 2022-03-29 23:17:18.916000+
state_skipped_timestamp | null
state_start_timestamp | 2022-03-29 23:17:04.299000+
state_success_timestamp | 2022-03-29 23:17:18.916000+
status| success
success_message | null
table_name| clusteringslicing
(1 rows)
{code}
What is lacking? Linking with system_views.streaming, my plan is to update
repair/streaming to support deep linking after this patch is merged (need to
modify network messages for remote repair + streaming, so repair knows stream
ids, and stream knows repair id)
*Coordinator*
{code}
cqlsh> SELECT * FROM system_views.repairs WHERE table_names CONTAINS
'clusteringslicing' ALLOW FILTERING;
@ Row 1
---+--
id| 34424630-afb6-11ec-ab62-fb846f906c0a
command_id| 2
duration_millis | 7799
failure_cause | null
keyspace_name | tlp_stress
last_updated_at | 2022-03-29 23:16:11.53+
options_column_families | {}
options_data_centers | {}
options_force_repair | False
options_hosts | {}
options_ignore_unreplicated_keyspaces | False
options_incremental | null
options_job_threads | 1
options_optimise_streams | False
options_parallelism | PARALLEL
options_preview_kind | NONE
options_primary_range | True
options_pull_repair | False
options_ranges|
{'(6148914691236517205,-9223372036854775808]'}
options_subrange_repair | False
options_trace | False
participants | ['/127.0.0.1:7000', '/127.0.0.2:7000']
ranges|
[['(6148914691236517205,-9223372036854775808]']]
sessions | {34441af0-afb6-11ec-ab62-fb846f906c0a}
state_failure_timestamp | null
state_init_timestamp | 2022-03-29 23:16:03.731000+
state_prepare_complete_timestamp | 2022-03-29 23:16:03.741000+
state_prepare_start_timestamp | 2022-03-29 23:16:03.737000+
state_repair_complete_timestamp | 2022-03-29 23:16:11.529000+
[jira] [Commented] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514369#comment-17514369
]
David Capwell commented on CASSANDRA-15399:
---
There are 2 types of tables: coordinator, participate; here are examples from
both sides
*Participate* (host involved in the repair, this may be the coordinator, but
would include all peers involved in the repair)
{code}
cqlsh> SELECT * FROM system_views.repair_participates WHERE tables CONTAINS
'tlp_stress.clusteringslicing' ALLOW FILTERING;
@ Row 1
-+
id | 584eca30-afb6-11ec-9bff-cd38a4d988d3
duration_millis | 14773
failure_cause | null
global | True
incremental | False
last_updated_at | 2022-03-29 23:17:18.993000+
preview_kind| NONE
ranges | ['(-3074457345618258603,0]']
repaired_at | null
state_failure_timestamp | null
state_init_timestamp| 2022-03-29 23:17:04.22+
state_skipped_timestamp | null
state_success_timestamp | 2022-03-29 23:17:18.993000+
success_message | Cleanup message recieved
tables | {'tlp_stress.clusteringslicing'}
validations | {0034e064-b54a-384f-99d0-af1bf42844a4}
(1 rows)
cqlsh> SELECT * FROM system_views.repair_validations WJERE
id=0034e064-b54a-384f-99d0-af1bf42844a4; -- id from validations field above
@ Row 1
---+--
id| 0034e064-b54a-384f-99d0-af1bf42844a4
duration_millis | 14688
estimated_partitions | 897
estimated_total_bytes | 2321697131
failure_cause | null
initiator | /127.0.0.1:7000
keyspace_name | tlp_stress
last_updated_at | 2022-03-29 23:17:18.916000+
partitions_processed | 181
progress_percentage | 100
ranges| ['(-3074457345618258603,0]']
repair_id | 584eca30-afb6-11ec-9bff-cd38a4d988d3
session_id| 58509ef0-afb6-11ec-9bff-cd38a4d988d3
state_failure_timestamp | null
state_init_timestamp | 2022-03-29 23:17:04.228000+
state_sending_trees_timestamp | 2022-03-29 23:17:18.916000+
state_skipped_timestamp | null
state_start_timestamp | 2022-03-29 23:17:04.299000+
state_success_timestamp | 2022-03-29 23:17:18.916000+
status| success
success_message | null
table_name| clusteringslicing
(1 rows)
{code}
What is lacking? Linking with system_views.streaming, my plan is to update
repair/streaming to support deep linking after this patch is merged (need to
modify network messages for remote repair + streaming, so repair knows stream
ids, and stream knows repair id)
*Coordinator*
{code}
cqlsh> SELECT * FROM system_views.repairs WHERE table_names CONTAINS
'clusteringslicing' ALLOW FILTERING;
@ Row 1
---+--
id| 34424630-afb6-11ec-ab62-fb846f906c0a
command_id| 2
duration_millis | 7799
failure_cause | null
keyspace_name | tlp_stress
last_updated_at | 2022-03-29 23:16:11.53+
options_column_families | {}
options_data_centers | {}
options_force_repair | False
options_hosts | {}
options_ignore_unreplicated_keyspaces | False
options_incremental | null
options_job_threads | 1
options_optimise_streams | False
options_parallelism | PARALLEL
options_preview_kind | NONE
options_primary_range | True
options_pull_repair | False
options_ranges|
{'(6148914691236517205,-9223372036854775808]'}
options_subrange_repair | False
options_trace | False
participants | ['/127.0.0.1:7000', '/127.0.0.2:7000']
ranges|
[['(6148914691236517205,-9223372036854775808]']]
sessions | {34441af0-afb6-11ec-ab62-fb846f906c0a}
state_failure_timestamp | null
state_init_timestamp | 2022-03-29 23:16:03.731000+
state_prepare_complete_timestamp | 2022-03-29 23:16:03.741000+
state_prepare_start_timestamp | 2022-03-29 23:16:03.737000+
state_repair_complete_timestamp | 2022-03-29 23:16:11.529000+
state_repair_start_timestamp | 2022-03-29
[jira] [Updated] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17497: -- Source Control Link: (was: https://github.com/apache/cassandra-website/pull/119/commits/ca2a23cbc2a0600887c416dd9effe0b08f4c1759) > WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver > workflow automation solution" > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17500) Create Maximum Data Center Replication Factor Guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-17500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Savni Nagarkar reassigned CASSANDRA-17500: -- Assignee: Savni Nagarkar > Create Maximum Data Center Replication Factor Guardrail > > > Key: CASSANDRA-17500 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17500 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > > This ticket adds a maximum replication factor guardrail to ensure safety when > creating or altering key spaces. The replication factor will be applied per > data center. The ticket was prompted as a user set the replication factor > equal to the number of nodes in the cluster. The property will be added to > guardrails to ensure consistency. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17500) Create Maximum Data Center Replication Factor Guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-17500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Savni Nagarkar updated CASSANDRA-17500: --- Change Category: Operability Complexity: Low Hanging Fruit Component/s: Feature/Guardrails Fix Version/s: 4.x Reviewers: Andres de la Peña, David Capwell, Josh McKenzie Status: Open (was: Triage Needed) > Create Maximum Data Center Replication Factor Guardrail > > > Key: CASSANDRA-17500 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17500 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > > This ticket adds a maximum replication factor guardrail to ensure safety when > creating or altering key spaces. The replication factor will be applied per > data center. The ticket was prompted as a user set the replication factor > equal to the number of nodes in the cluster. The property will be added to > guardrails to ensure consistency. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17500) Create Maximum Data Center Replication Factor Guardrail
Savni Nagarkar created CASSANDRA-17500: -- Summary: Create Maximum Data Center Replication Factor Guardrail Key: CASSANDRA-17500 URL: https://issues.apache.org/jira/browse/CASSANDRA-17500 Project: Cassandra Issue Type: Improvement Reporter: Savni Nagarkar This ticket adds a maximum replication factor guardrail to ensure safety when creating or altering key spaces. The replication factor will be applied per data center. The ticket was prompted as a user set the replication factor equal to the number of nodes in the cluster. The property will be added to guardrails to ensure consistency. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514322#comment-17514322 ] Stefan Miklosovic edited comment on CASSANDRA-17495 at 3/29/22, 8:50 PM: - I was looking at this PR in GH and I was wondering how is this different from GRANT ALTER ON TABLE ks1.tb1 TO ... and REVOKE ALTER ON ks1.tb1 FROM ? I think you can grant / revoke dropping too. For RENAME we have GRANT / REVOKE MODIFY. More to it, if this is needed for some "bulk operation" to cover all users, all it requires to have all these users in the same role: 1) CREATE ROLE somerole; 2) GRANT somerole TO someuser; 3) REVOKE ALTER ON ks1.tb1 FROM solerole; Even for all keyspaces for all such users in that role: 4) REVOKE ALTER ON ALL KEYSPACES FROM developers; I just dont see the justification why we need this (yet). was (Author: smiklosovic): I was looking at this PR in GH and I was wondering how is this different from GRANT ALTER ON TABLE ks1.tb1 TO ... and REVOKE ALTER ON ks1.tb1 FROM ? I think you can grant / revoke dropping too. For RENAME we have GRANT / REVOKE MODIFY. > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17498) Add Guardrail to disallow creation of secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie reassigned CASSANDRA-17498: - Assignee: Josh McKenzie > Add Guardrail to disallow creation of secondary indexes > --- > > Key: CASSANDRA-17498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17498 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Rather than just a min/max on secondary indexes, we should also have the > ability to completely enable or disable creation of secondary indexes via > guardrails. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514322#comment-17514322 ] Stefan Miklosovic edited comment on CASSANDRA-17495 at 3/29/22, 8:39 PM: - I was looking at this PR in GH and I was wondering how is this different from GRANT ALTER ON TABLE ks1.tb1 TO ... and REVOKE ALTER ON ks1.tb1 FROM ? I think you can grant / revoke dropping too. For RENAME we have GRANT / REVOKE MODIFY. was (Author: smiklosovic): I was looking at this PR in GH and I was wondering how is this different from GRANT ALTER ON TABLE ks1.tb1 TO ... and REVOKE ALTER ON ks1.tb1 FROM ? > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514322#comment-17514322 ] Stefan Miklosovic edited comment on CASSANDRA-17495 at 3/29/22, 8:36 PM: - I was looking at this PR in GH and I was wondering how is this different from GRANT ALTER ON TABLE ks1.tb1 TO ... and REVOKE ALTER ON ks1.tb1 FROM ? was (Author: smiklosovic): I was looking at this PR in GH and I was wondering how is this different from GRANT ALTER ON TABLE ks1.tb1 TO ... ? > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514322#comment-17514322 ] Stefan Miklosovic commented on CASSANDRA-17495: --- I was looking at this PR in GH and I was wondering how is this different from GRANT ALTER ON TABLE ks1.tb1 TO ... ? > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
[ https://issues.apache.org/jira/browse/CASSANDRASC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-35: Reviewers: Dinesh Joshi, Yifan Cai (was: Dinesh Joshi) > Document the contribution guidelines and best practices for the project > --- > > Key: CASSANDRASC-35 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > We need a document that lays out the contribution guidelines, source code > best practices, and source code style -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17498) Add Guardrail to disallow creation of secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514312#comment-17514312 ] Josh McKenzie edited comment on CASSANDRA-17498 at 3/29/22, 8:08 PM: - Technically yes. The UX of "max of 0" is slightly less clear than "is this feature enabled or disabled", and the overhead of adding another guardrail in terms of complexity in the codebase is quite small so I'm in favor of adding the formal toggle personally. edit: I'd also add - secondary indexes are one of those features we've said for a long time are "only use this if you really know what you're doing and aren't going to need to scale". So that's another check in the box of making it a formal parameter that people can straight disable across the board I think. Open to alternative viewpoints as always though. was (Author: jmckenzie): Technically yes. The UX of "max of 0" is slightly less clear than "is this feature enabled or disabled", and the overhead of adding another guardrail in terms of complexity in the codebase is quite small so I'm in favor of adding the formal toggle personally. > Add Guardrail to disallow creation of secondary indexes > --- > > Key: CASSANDRA-17498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17498 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Priority: Normal > > Rather than just a min/max on secondary indexes, we should also have the > ability to completely enable or disable creation of secondary indexes via > guardrails. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17499) Remove global Guardrails Enable flag
[ https://issues.apache.org/jira/browse/CASSANDRA-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514313#comment-17514313 ] Savni Nagarkar commented on CASSANDRA-17499: https://github.com/apache/cassandra/pull/1533 > Remove global Guardrails Enable flag > > > Key: CASSANDRA-17499 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17499 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > > This ticket removes the global Guardrails enable flag. Currently the flag > turns all Guardrails on and off regardless of the individual setting of the > guardrail property. This presents a problem for maximum replication factor > and minimum replication factor configurations which will soon be moved to > guardrails. Those configurations will always need to be enabled so no > problems arise as Cassandra users create keyspaces. This ensures all > Guardrail properties follow the same enable / disable procedure. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17498) Add Guardrail to disallow creation of secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514312#comment-17514312 ] Josh McKenzie commented on CASSANDRA-17498: --- Technically yes. The UX of "max of 0" is slightly less clear than "is this feature enabled or disabled", and the overhead of adding another guardrail in terms of complexity in the codebase is quite small so I'm in favor of adding the formal toggle personally. > Add Guardrail to disallow creation of secondary indexes > --- > > Key: CASSANDRA-17498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17498 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Priority: Normal > > Rather than just a min/max on secondary indexes, we should also have the > ability to completely enable or disable creation of secondary indexes via > guardrails. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17474) Failed to instantiate SLF4J LoggerFactory in Cassandra 3.11.12
[
https://issues.apache.org/jira/browse/CASSANDRA-17474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514310#comment-17514310
]
Brandon Williams edited comment on CASSANDRA-17474 at 3/29/22, 7:58 PM:
Interestingly when I manually recreate a test (these are so much fun to do that
way) it produces:
{noformat}
Digest mismatch: {} [Native-Transport-Requests-1]
{noformat}
in the trace, indicating it's swallowing the exception... which only deepens
the mystery. I confirmed this is the case by modifying the dtest to only look
for that part and indeed it passes.
was (Author: brandon.williams):
Interestingly when I manually recreate a test (these are a so much fun to do
that way) it produces:
{noformat}
Digest mismatch: {} [Native-Transport-Requests-1]
{noformat}
in the trace, indicating it's swallowing the exception... which only deepens
the mystery. I confirmed this is the case by modifying the dtest to only look
for that part and indeed it passes.
> Failed to instantiate SLF4J LoggerFactory in Cassandra 3.11.12
> --
>
> Key: CASSANDRA-17474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17474
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Tobias Gustafsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.13
>
> Attachments: logback.xml
>
>
> After upgrading to 3.11.12, Cassandra crashes on startup because of a class
> that cannot be found in slf4j.
> {code}
> Failed to instantiate SLF4J LoggerFactory
> Reported exception:
> java.lang.NoClassDefFoundError: org/slf4j/event/LoggingEvent
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetPublicMethods(Class.java:2902)
> at java.lang.Class.getMethods(Class.java:1615)
> at
> ch.qos.logback.core.joran.util.beans.BeanDescriptionFactory.create(BeanDescriptionFactory.java:35)
> at
> ch.qos.logback.core.joran.util.beans.BeanDescriptionCache.getBeanDescription(BeanDescriptionCache.java:47)
> at
> ch.qos.logback.core.joran.util.PropertySetter.(PropertySetter.java:68)
> at
> ch.qos.logback.core.joran.action.NestedComplexPropertyIA.isApplicable(NestedComplexPropertyIA.java:65)
> at
> ch.qos.logback.core.joran.spi.Interpreter.lookupImplicitAction(Interpreter.java:233)
> at
> ch.qos.logback.core.joran.spi.Interpreter.getApplicableActionList(Interpreter.java:252)
> at
> ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:142)
> at
> ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:128)
> at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:165)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:152)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:110)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53)
> at
> ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:65)
> at
> ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:140)
> at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84)
> at org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:55)
> at org.slf4j.LoggerFactory.bind(LoggerFactory.java:129)
> at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108)
> at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:302)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288)
> at
> org.apache.cassandra.service.CassandraDaemon.(CassandraDaemon.java:117)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.event.LoggingEvent
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
> ... 27 more
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/slf4j/event/LoggingEvent
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetPublicMethods(Class.java:2902)
> at java.lang.Class.getMethods(Class.java:1615)
> at
> ch.qos.logback.core.joran.util.beans.BeanDescriptionFactory.create(BeanDescriptionFactory.java:35)
> at
>
[jira] [Commented] (CASSANDRA-17474) Failed to instantiate SLF4J LoggerFactory in Cassandra 3.11.12
[
https://issues.apache.org/jira/browse/CASSANDRA-17474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514310#comment-17514310
]
Brandon Williams commented on CASSANDRA-17474:
--
Interestingly when I manually recreate a test (these are a so much fun to do
that way) it produces:
{noformat}
Digest mismatch: {} [Native-Transport-Requests-1]
{noformat}
in the trace, indicating it's swallowing the exception... which only deepens
the mystery. I confirmed this is the case by modifying the dtest to only look
for that part and indeed it passes.
> Failed to instantiate SLF4J LoggerFactory in Cassandra 3.11.12
> --
>
> Key: CASSANDRA-17474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17474
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Tobias Gustafsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.13
>
> Attachments: logback.xml
>
>
> After upgrading to 3.11.12, Cassandra crashes on startup because of a class
> that cannot be found in slf4j.
> {code}
> Failed to instantiate SLF4J LoggerFactory
> Reported exception:
> java.lang.NoClassDefFoundError: org/slf4j/event/LoggingEvent
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetPublicMethods(Class.java:2902)
> at java.lang.Class.getMethods(Class.java:1615)
> at
> ch.qos.logback.core.joran.util.beans.BeanDescriptionFactory.create(BeanDescriptionFactory.java:35)
> at
> ch.qos.logback.core.joran.util.beans.BeanDescriptionCache.getBeanDescription(BeanDescriptionCache.java:47)
> at
> ch.qos.logback.core.joran.util.PropertySetter.(PropertySetter.java:68)
> at
> ch.qos.logback.core.joran.action.NestedComplexPropertyIA.isApplicable(NestedComplexPropertyIA.java:65)
> at
> ch.qos.logback.core.joran.spi.Interpreter.lookupImplicitAction(Interpreter.java:233)
> at
> ch.qos.logback.core.joran.spi.Interpreter.getApplicableActionList(Interpreter.java:252)
> at
> ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:142)
> at
> ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:128)
> at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:165)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:152)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:110)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53)
> at
> ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:65)
> at
> ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:140)
> at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84)
> at org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:55)
> at org.slf4j.LoggerFactory.bind(LoggerFactory.java:129)
> at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108)
> at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:302)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288)
> at
> org.apache.cassandra.service.CassandraDaemon.(CassandraDaemon.java:117)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.event.LoggingEvent
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
> ... 27 more
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/slf4j/event/LoggingEvent
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetPublicMethods(Class.java:2902)
> at java.lang.Class.getMethods(Class.java:1615)
> at
> ch.qos.logback.core.joran.util.beans.BeanDescriptionFactory.create(BeanDescriptionFactory.java:35)
> at
> ch.qos.logback.core.joran.util.beans.BeanDescriptionCache.getBeanDescription(BeanDescriptionCache.java:47)
> at
> ch.qos.logback.core.joran.util.PropertySetter.(PropertySetter.java:68)
> at
> ch.qos.logback.core.joran.action.NestedComplexPropertyIA.isApplicable(NestedComplexPropertyIA.java:65)
> at
> ch.qos.logback.core.joran.spi.Interpreter.lookupImplicitAction(Interpreter.java:233)
> at
>
[jira] [Updated] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
[ https://issues.apache.org/jira/browse/CASSANDRASC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-35: Reviewers: Dinesh Joshi Status: Review In Progress (was: Patch Available) > Document the contribution guidelines and best practices for the project > --- > > Key: CASSANDRASC-35 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > We need a document that lays out the contribution guidelines, source code > best practices, and source code style -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
[ https://issues.apache.org/jira/browse/CASSANDRASC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-35: Status: Ready to Commit (was: Review In Progress) +1 > Document the contribution guidelines and best practices for the project > --- > > Key: CASSANDRASC-35 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > We need a document that lays out the contribution guidelines, source code > best practices, and source code style -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
[ https://issues.apache.org/jira/browse/CASSANDRASC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-35: -- Authors: Francisco Guerrero Test and Documentation Plan: Documentation is provided for contribution guidelines Status: Patch Available (was: Open) PR: https://github.com/apache/cassandra-sidecar/pull/27/files > Document the contribution guidelines and best practices for the project > --- > > Key: CASSANDRASC-35 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > We need a document that lays out the contribution guidelines, source code > best practices, and source code style -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
[ https://issues.apache.org/jira/browse/CASSANDRASC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-35: -- Labels: pull-request-available (was: ) > Document the contribution guidelines and best practices for the project > --- > > Key: CASSANDRASC-35 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > We need a document that lays out the contribution guidelines, source code > best practices, and source code style -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
[ https://issues.apache.org/jira/browse/CASSANDRASC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-35: -- Change Category: Semantic Complexity: Normal Component/s: Documentation Assignee: Francisco Guerrero Status: Open (was: Triage Needed) > Document the contribution guidelines and best practices for the project > --- > > Key: CASSANDRASC-35 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > > We need a document that lays out the contribution guidelines, source code > best practices, and source code style -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
Francisco Guerrero created CASSANDRASC-35: - Summary: Document the contribution guidelines and best practices for the project Key: CASSANDRASC-35 URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 Project: Sidecar for Apache Cassandra Issue Type: Task Reporter: Francisco Guerrero We need a document that lays out the contribution guidelines, source code best practices, and source code style -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17499) Remove global Guardrails Enable flag
[ https://issues.apache.org/jira/browse/CASSANDRA-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Savni Nagarkar updated CASSANDRA-17499: --- Change Category: Operability Complexity: Low Hanging Fruit Component/s: Feature/Guardrails Fix Version/s: 4.x Reviewers: Andres de la Peña, David Capwell, Josh McKenzie Assignee: Savni Nagarkar Status: Open (was: Triage Needed) > Remove global Guardrails Enable flag > > > Key: CASSANDRA-17499 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17499 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > > This ticket removes the global Guardrails enable flag. Currently the flag > turns all Guardrails on and off regardless of the individual setting of the > guardrail property. This presents a problem for maximum replication factor > and minimum replication factor configurations which will soon be moved to > guardrails. Those configurations will always need to be enabled so no > problems arise as Cassandra users create keyspaces. This ensures all > Guardrail properties follow the same enable / disable procedure. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17499) Remove global Guardrails Enable flag
Savni Nagarkar created CASSANDRA-17499: -- Summary: Remove global Guardrails Enable flag Key: CASSANDRA-17499 URL: https://issues.apache.org/jira/browse/CASSANDRA-17499 Project: Cassandra Issue Type: Improvement Reporter: Savni Nagarkar This ticket removes the global Guardrails enable flag. Currently the flag turns all Guardrails on and off regardless of the individual setting of the guardrail property. This presents a problem for maximum replication factor and minimum replication factor configurations which will soon be moved to guardrails. Those configurations will always need to be enabled so no problems arise as Cassandra users create keyspaces. This ensures all Guardrail properties follow the same enable / disable procedure. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17497: - Source Control Link: https://github.com/apache/cassandra-website/pull/119/commits/ca2a23cbc2a0600887c416dd9effe0b08f4c1759 > WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver > workflow automation solution" > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17497: - Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/119 > WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver > workflow automation solution" > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Fix For: NA > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17497: --- Labels: pull-request-available (was: ) > WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver > workflow automation solution" > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17497: - Status: Open (was: Triage Needed) > WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver > workflow automation solution" > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Fix For: NA > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17497: - Summary: WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution" (was: WEBSITE - add blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution" March 2022) > WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver > workflow automation solution" > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Fix For: NA > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17498) Add Guardrail to disallow creation of secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514276#comment-17514276 ] Brendan Cicchi commented on CASSANDRA-17498: If you are allowed to specify a maximum of 0, wouldn't that solve this without adding an additional yaml config? > Add Guardrail to disallow creation of secondary indexes > --- > > Key: CASSANDRA-17498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17498 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Priority: Normal > > Rather than just a min/max on secondary indexes, we should also have the > ability to completely enable or disable creation of secondary indexes via > guardrails. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Ninja: CASSANDRA-17478 added UpdateSystemAuthAfterDCExpansionTest to the wrong directory which broke CI, moved it to the right directory
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new b9d9f9c Ninja: CASSANDRA-17478 added
UpdateSystemAuthAfterDCExpansionTest to the wrong directory which broke CI,
moved it to the right directory
b9d9f9c is described below
commit b9d9f9c7dab9b39fb27a4be0b6d9ce2a8718167e
Author: David Capwell
AuthorDate: Tue Mar 29 11:40:33 2022 -0700
Ninja: CASSANDRA-17478 added UpdateSystemAuthAfterDCExpansionTest to the
wrong directory which broke CI, moved it to the right directory
---
.../distributed/{ => test}/UpdateSystemAuthAfterDCExpansionTest.java | 0
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git
a/test/distributed/org/apache/cassandra/distributed/UpdateSystemAuthAfterDCExpansionTest.java
b/test/distributed/org/apache/cassandra/distributed/test/UpdateSystemAuthAfterDCExpansionTest.java
similarity index 100%
rename from
test/distributed/org/apache/cassandra/distributed/UpdateSystemAuthAfterDCExpansionTest.java
rename to
test/distributed/org/apache/cassandra/distributed/test/UpdateSystemAuthAfterDCExpansionTest.java
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17498) Add Guardrail to disallow creation of secondary indexes
Josh McKenzie created CASSANDRA-17498: - Summary: Add Guardrail to disallow creation of secondary indexes Key: CASSANDRA-17498 URL: https://issues.apache.org/jira/browse/CASSANDRA-17498 Project: Cassandra Issue Type: New Feature Components: Feature/Guardrails Reporter: Josh McKenzie Rather than just a min/max on secondary indexes, we should also have the ability to completely enable or disable creation of secondary indexes via guardrails. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17497) WEBSITE - add blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution" March 2022
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17497: - Authors: Diogenese Topper Change Category: Semantic Complexity: Normal Fix Version/s: NA Impacts: Docs (was: None) Test and Documentation Plan: * Add blog post titled "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution" * Modify blog index page * Add image for blog: "kinetic-data-chooses-apache-cassandra-to-deliver-workflow-automation-solution-unsplash-lukas-tennie.jpg" > WEBSITE - add blog "Kinetic Data chooses Apache Cassandra to deliver workflow > automation solution" March 2022 > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Fix For: NA > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17217) LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-17217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-17217:
--
Reviewers: Yifan Cai (was: Yifan Cai, Yifan Cai)
> LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
> --
>
> Key: CASSANDRA-17217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17217
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The test
> {{org.apache.cassandra.distributed.test.trackwarnings.LocalReadSizeWarningTest#failThresholdSinglePartition}}
> seems to be flaky.
> It was discovered during CASSANDRA-17195 with [this CI
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1217/workflows/b366e352-0862-485a-acdc-5b75fe1ef575/jobs/11188].
> The failure can be reproduced running the test repeatedly for trunk, as it
> can be seen
> [here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1219/workflows/a0c1fb7f-8a07-4fcf-97a4-7caf207dad78].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17497) WEBSITE - add blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution" March 2022
Diogenese Topper created CASSANDRA-17497: Summary: WEBSITE - add blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution" March 2022 Key: CASSANDRA-17497 URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 Project: Cassandra Issue Type: Task Components: Documentation/Blog Reporter: Diogenese Topper This ticket is to capture the work associated with publishing the March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution" If this blog cannot be published by the *March 31, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17345) Fix flaky NetstatsBootstrapWithEntireSSTablesCompressionStreamingTest.testWithStreamingEntireSSTablesWithoutCompression
[ https://issues.apache.org/jira/browse/CASSANDRA-17345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernardo Botella Corbi reassigned CASSANDRA-17345: -- Assignee: Bernardo Botella Corbi > Fix flaky > NetstatsBootstrapWithEntireSSTablesCompressionStreamingTest.testWithStreamingEntireSSTablesWithoutCompression > > > > Key: CASSANDRA-17345 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17345 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Streaming >Reporter: Brandon Williams >Assignee: Bernardo Botella Corbi >Priority: Normal > Fix For: 4.x > > > Failed 4 times in the last 30 runs. Flakiness: 17%, Stability: 86% > Error Message > Timeout occurred. Please note the time in the report does not reflect the > time until the timeout. > Stacktrace > junit.framework.AssertionFailedError: Timeout occurred. Please note the time > in the report does not reflect the time until the timeout. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17217) LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-17217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-17217:
--
Reviewers: Yifan Cai, Yifan Cai
Status: Review In Progress (was: Patch Available)
+1
Thanks for the fix. Looking at the repeated run. It is green after 4000 loops.
(y)
> LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
> --
>
> Key: CASSANDRA-17217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17217
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The test
> {{org.apache.cassandra.distributed.test.trackwarnings.LocalReadSizeWarningTest#failThresholdSinglePartition}}
> seems to be flaky.
> It was discovered during CASSANDRA-17195 with [this CI
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1217/workflows/b366e352-0862-485a-acdc-5b75fe1ef575/jobs/11188].
> The failure can be reproduced running the test repeatedly for trunk, as it
> can be seen
> [here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1219/workflows/a0c1fb7f-8a07-4fcf-97a4-7caf207dad78].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17424) Performance and Semantic Concerns w/ Metrics for Local vs. Remote Requests in StorageProxy
[
https://issues.apache.org/jira/browse/CASSANDRA-17424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17424:
Fix Version/s: 4.1
(was: 4.x)
Since Version: 4.1
Source Control Link:
https://github.com/apache/cassandra/commit/57ab3afcf16970047d3df4656241cf0705e94bee
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
https://github.com/apache/cassandra/commit/57ab3afcf16970047d3df4656241cf0705e94bee
> Performance and Semantic Concerns w/ Metrics for Local vs. Remote Requests in
> StorageProxy
> --
>
> Key: CASSANDRA-17424
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17424
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In CASSANDRA-10023, we added two new metrics to both {{ClientRequestMetrics}}
> and {{ClientWriteRequestMetrics}} to represent requests where the driver
> either does or does not make a correct token-aware choice of coordinator.
> (Auditing driver behavior is listed as the primary goal of that Jira.)
> There are, however, a few concerns we should address before this releases in
> 4.1:
> 1.) With paging enabled and a LIMIT < fetch size, {{IN}} queries can hit
> {{fetchRows()}} multiple times, so the number of local + remote requests
> isn’t the same as the number of queries marked in {{ClientRequestMetrics}} in
> {{readRegular()}}.
> 2.) {{IN}} queries will potentially mark a bunch of “remote” requests even if
> one key in the {{IN}} set is “local”.
> 3.) Something similar happens with mutations. If {{StorageProxy#mutate()}}
> receives multiple mutations, we’ll mark against one of these new metrics in
> {{ClientWriteRequestMetrics}} for each mutation, while
> {{ClientWriteRequestMetrics}} will only register the actual client request
> once.
> For cases 2 and 3, we may mark both local and remote requests for the same
> overall client request, which introduces ambiguity if these are intended to
> help audit driver coordinator selection behavior. There are a few options:
> a.) We can accept the ambiguity, but then we haven’t really accomplished the
> goal of CASSANDRA-10023 for some request types.
> b.) We can simply not record any of these metrics for requests where multiple
> partitions/tokens are involved.
> c.) We can be lenient, marking requests as “local” if any of the
> partitions/tokens involved in the client request are, in fact, local.
> “c” feels like the option that preserves as much functionality as possible
> without being ambiguous, but problem #2 above is still tricky, given the way
> IN and GROUP BY queries behave w/ paging. (Perhaps ambiguity in that case is
> acceptable?)
> In addition to the general ambiguity around the above…
> 4.) There is excessive object creation involved (on a hot path) in our
> determination of whether a request is local or remote. We should be able to
> mitigate this by getting rid of
> {{AbstractReadExecutor#getContactedReplicas()}} and relying on
> {{ReplicaPlan#lookup()}} rather than creating strings. (Even for writes, we
> should be able to push down marking into performWrite(), where the write
> ReplicaPlan is already available.)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: reduce hot-path object allocations required to record local/remote requests against the client request metrics
This is an automated email from the ASF dual-hosted git repository.
maedhroz pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 57ab3af reduce hot-path object allocations required to record
local/remote requests against the client request metrics
57ab3af is described below
commit 57ab3afcf16970047d3df4656241cf0705e94bee
Author: Caleb Rackliffe
AuthorDate: Mon Mar 14 17:13:47 2022 -0500
reduce hot-path object allocations required to record local/remote requests
against the client request metrics
patch by Caleb Rackliffe; reviewed by Jon Meredith for CASSANDRA-17424
Co-authored-by: Marcus Eriksson
Co-authored-by: Caleb Rackliffe
---
CHANGES.txt| 1 +
.../org/apache/cassandra/service/StorageProxy.java | 48 +-
.../service/reads/AbstractReadExecutor.java| 12 ++
.../metrics/ClientRequestMetricsTest.java | 19 +
4 files changed, 36 insertions(+), 44 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 3e59bc0..cd1270d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * reduce hot-path object allocations required to record local/remote requests
against the client request metrics (CASSANDRA-17424)
* Disallow removing DC from system_auth while nodes are active in the DC
(CASSANDRA-17478)
* Add guardrail for the number of fields per UDT (CASSANDRA-17385)
* Allow users to change cqlsh history location using env variable
(CASSANDRA-17448)
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java
b/src/java/org/apache/cassandra/service/StorageProxy.java
index 99ed347..15e9e2d 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -833,17 +833,6 @@ public class StorageProxy implements StorageProxyMBean
});
}
-private static boolean hasLocalMutation(IMutation mutation)
-{
-return
canDoLocalRequest(StorageService.instance.getNaturalEndpointsWithPort(mutation.getKeyspaceName(),
-
mutation.key().getKey()));
-}
-
-private static boolean canDoLocalRequest(List endpoints)
-{
-return
endpoints.contains(FBUtilities.getBroadcastAddressAndPort().getHostAddressAndPort());
-}
-
/**
* Use this method to have these Mutations applied
* across all replicas. This method will take care
@@ -869,11 +858,6 @@ public class StorageProxy implements StorageProxyMBean
{
for (IMutation mutation : mutations)
{
-if (hasLocalMutation(mutation))
-writeMetrics.localRequests.mark();
-else
-writeMetrics.remoteRequests.mark();
-
if (mutation instanceof CounterMutation)
responseHandlers.add(mutateCounter((CounterMutation)mutation, localDataCenter,
queryStartNanoTime));
else
@@ -1027,11 +1011,6 @@ public class StorageProxy implements StorageProxyMBean
// add a handler for each mutation - includes checking
availability, but doesn't initiate any writes, yet
for (Mutation mutation : mutations)
{
-if (hasLocalMutation(mutation))
-writeMetrics.localRequests.mark();
-else
-writeMetrics.remoteRequests.mark();
-
String keyspaceName = mutation.getKeyspaceName();
Token tk = mutation.key().getToken();
AbstractReplicationStrategy replicationStrategy =
Keyspace.open(keyspaceName).getReplicationStrategy();
@@ -1198,11 +1177,6 @@ public class StorageProxy implements StorageProxyMBean
// add a handler for each mutation - includes checking
availability, but doesn't initiate any writes, yet
for (Mutation mutation : mutations)
{
-if (hasLocalMutation(mutation))
-writeMetrics.localRequests.mark();
-else
-writeMetrics.remoteRequests.mark();
-
WriteResponseHandlerWrapper wrapper =
wrapBatchResponseHandler(mutation,
consistency_level,
batchConsistencyLevel,
@@ -1369,6 +1343,12 @@ public class StorageProxy implements StorageProxyMBean
Token tk = mutation.key().getToken();
ReplicaPlan.ForWrite replicaPlan = ReplicaPlans.forWrite(keyspace,
consistencyLevel, tk, ReplicaPlans.writeNormal);
+
+if (replicaPlan.lookup(FBUtilities.getBroadcastAddressAndPort()) !=
null)
+
[jira] [Commented] (CASSANDRA-17496) Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults
[ https://issues.apache.org/jira/browse/CASSANDRA-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514183#comment-17514183 ] Josh McKenzie commented on CASSANDRA-17496: --- Perfect example from CASSANDRA-17478 on why you shouldn't change things during commit. :) [branch|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:cassandra-17496?expand=1] [JDK 8 CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/194/workflows/b620b52e-1cba-420e-b6ea-d250def4aa27] [JDK 11 CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/194/workflows/b13d1728-4ee1-4a5f-8fd7-484a14fb1af9] > Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults > -- > > Key: CASSANDRA-17496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17496 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Caused by CASSANDRA-17478 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17496) Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults
[ https://issues.apache.org/jira/browse/CASSANDRA-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17496: -- Test and Documentation Plan: Fix unit test Status: Patch Available (was: Open) > Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults > -- > > Key: CASSANDRA-17496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17496 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Caused by CASSANDRA-17478 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17496) Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults
[ https://issues.apache.org/jira/browse/CASSANDRA-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17496: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Low Hanging Fruit Component/s: Test/unit Discovered By: Unit Test Severity: Low Status: Open (was: Triage Needed) > Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults > -- > > Key: CASSANDRA-17496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17496 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Caused by CASSANDRA-17478 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17496) Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults
Josh McKenzie created CASSANDRA-17496: - Summary: Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults Key: CASSANDRA-17496 URL: https://issues.apache.org/jira/browse/CASSANDRA-17496 Project: Cassandra Issue Type: Bug Reporter: Josh McKenzie Caused by CASSANDRA-17478 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17496) Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults
[ https://issues.apache.org/jira/browse/CASSANDRA-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie reassigned CASSANDRA-17496: - Assignee: Josh McKenzie > Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults > -- > > Key: CASSANDRA-17496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17496 > Project: Cassandra > Issue Type: Bug >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Caused by CASSANDRA-17478 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17495: -- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17495: -- Fix Version/s: 4.x > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17495: -- Test and Documentation Plan: New unit testing around guardrail Status: Patch Available (was: Open) > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514175#comment-17514175 ] Josh McKenzie commented on CASSANDRA-17495: --- [PR|https://github.com/apache/cassandra/pull/1532] [JDK 8 CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/193/workflows/5a728155-5bed-4106-8986-be86dc5e4318] [JDK 11 CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/193/workflows/bed54236-76fc-467d-9623-576d00c5cb31] > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
Josh McKenzie created CASSANDRA-17495: - Summary: Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns Key: CASSANDRA-17495 URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 Project: Cassandra Issue Type: New Feature Components: Feature/Guardrails Reporter: Josh McKenzie Assignee: Josh McKenzie Operators should have the ability to freeze the schema of tables in place so users can't mutate columns during various cluster operations. For an example of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17466) Shut repair task executor down without interruption to avoid compromising shared channel proxies
[
https://issues.apache.org/jira/browse/CASSANDRA-17466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514167#comment-17514167
]
Caleb Rackliffe commented on CASSANDRA-17466:
-
[~bereng] I look a [quick
look|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk]
at Butler, and there are definitely some new issues w/ the [group commit log
tests|https://ci-cassandra.apache.org/job/Cassandra-trunk/1051/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/replaySimple_4__compression/].
Are those just CASSANDRA-17469, which was created a week ago (before this
merged)? Looks similar to CASSANDRA-17286 as well...
> Shut repair task executor down without interruption to avoid compromising
> shared channel proxies
>
>
> Key: CASSANDRA-17466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1, 4.0.4
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> If a {{RepairJob}} gets past validation, it builds a list of {{SyncTask}}
> items and fires them off. If any one of those fails, we grab the relevant
> exception and throw it up from {{RepairJob}} to {{RepairSession}}.
> {noformat}
> ERROR 2022-03-09T23:53:36,721
> [Stream-Deserializer-/10.246.3.102:7000-d97958c4]
> org.apache.cassandra.streaming.StreamSession:1110 - [Stream
> #07c55da0-a047-11ec-8122-ab911c7a993f] Remote peer /10.246.3.102:7000 failed
> stream session.
> {noformat}
> {{RepairSession}} then marks itself as being terminated and clears its
> internal maps of active validations and sync tasks, but immediately before it
> does that, it calls {{shutdownNow()}} on the executor that executes those
> tasks. In the case of our failing stream session, we may still have other
> running stream tasks whose threads' interrupt flag has been set, and this can
> have some unintended negative consequences, because any {{ChannelProxy}}
> interrupted in the middle of a blocking operation will both be closed and
> throw a {{ClosedByInterruptException}}. (Keep in mind that we share
> {{ChannelProxy}} instances outside a few specific cases, like those
> introduced in CASSANDRA-15666.)
> We've seen this manifest in production in a couple ways, both of them while
> trying to read from the {{peers_v2}} system table:
> {noformat}
> Exception in thread Thread[RepairJobTask:23,5,main]"^M
> exception="FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-99-big-Data.db
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.getFileDataInput(SSTableReader.java:1628)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.(AbstractSSTableIterator.java:96)
> at
> org.apache.cassandra.db.columniterator.SSTableIterator.(SSTableIterator.java:48)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableReader.iterator(BigTableReader.java:75)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableReader.iterator(BigTableReader.java:67)
> at
> org.apache.cassandra.db.StorageHook$1.makeRowIterator(StorageHook.java:87)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndSSTablesInTimestampOrder(SinglePartitionReadCommand.java:897)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(SinglePartitionReadCommand.java:605)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDisk(SinglePartitionReadCommand.java:578)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryStorage(SinglePartitionReadCommand.java:412)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:414)
> at
> org.apache.cassandra.db.SinglePartitionReadQuery$Group.executeLocally(SinglePartitionReadQuery.java:242)
> at
> org.apache.cassandra.db.SinglePartitionReadQuery$Group.executeInternal(SinglePartitionReadQuery.java:216)
> at
>
[jira] [Updated] (CASSANDRA-17443) testUnwriteableFlushRecovery is never called
[ https://issues.apache.org/jira/browse/CASSANDRA-17443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Branimir Lambov updated CASSANDRA-17443: Status: Review In Progress (was: Needs Committer) > testUnwriteableFlushRecovery is never called > > > Key: CASSANDRA-17443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17443 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Ruslan Fomkin >Priority: Normal > Labels: test > > `testUnwriteableFlushRecovery` of `CommitLogTest` was implemented 6 years ago > and seems to became a dead code immediately. It should be either enabled back > or removed. The source of the test is at > https://github.com/apache/cassandra/blob/2b2c6decfafc6235ad537e72073fab2fd4467e2f/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java#L932 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17443) testUnwriteableFlushRecovery is never called
[ https://issues.apache.org/jira/browse/CASSANDRA-17443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Branimir Lambov updated CASSANDRA-17443: Status: Needs Committer (was: Review In Progress) > testUnwriteableFlushRecovery is never called > > > Key: CASSANDRA-17443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17443 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Ruslan Fomkin >Priority: Normal > Labels: test > > `testUnwriteableFlushRecovery` of `CommitLogTest` was implemented 6 years ago > and seems to became a dead code immediately. It should be either enabled back > or removed. The source of the test is at > https://github.com/apache/cassandra/blob/2b2c6decfafc6235ad537e72073fab2fd4467e2f/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java#L932 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17443) testUnwriteableFlushRecovery is never called
[ https://issues.apache.org/jira/browse/CASSANDRA-17443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Branimir Lambov updated CASSANDRA-17443: Status: Ready to Commit (was: Review In Progress) > testUnwriteableFlushRecovery is never called > > > Key: CASSANDRA-17443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17443 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Ruslan Fomkin >Priority: Normal > Labels: test > > `testUnwriteableFlushRecovery` of `CommitLogTest` was implemented 6 years ago > and seems to became a dead code immediately. It should be either enabled back > or removed. The source of the test is at > https://github.com/apache/cassandra/blob/2b2c6decfafc6235ad537e72073fab2fd4467e2f/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java#L932 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17443) testUnwriteableFlushRecovery is never called
[ https://issues.apache.org/jira/browse/CASSANDRA-17443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Branimir Lambov updated CASSANDRA-17443: Reviewers: Berenguer Blasi, Branimir Lambov (was: Berenguer Blasi) > testUnwriteableFlushRecovery is never called > > > Key: CASSANDRA-17443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17443 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Ruslan Fomkin >Priority: Normal > Labels: test > > `testUnwriteableFlushRecovery` of `CommitLogTest` was implemented 6 years ago > and seems to became a dead code immediately. It should be either enabled back > or removed. The source of the test is at > https://github.com/apache/cassandra/blob/2b2c6decfafc6235ad537e72073fab2fd4467e2f/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java#L932 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514125#comment-17514125 ] Brandon Williams commented on CASSANDRA-17417: -- I think you're correct, I was thinking that we hadn't finished CASSANDRA-17393 but we have so there's no point in keeping it here. I've updated the branch and the CI runs above with it. > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514034#comment-17514034 ] Brandon Williams edited comment on CASSANDRA-17417 at 3/29/22, 2:34 PM: Alright, round 2. This is Brad's patch and then the zip loading returned on top of that. ||Branch||CI| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17417]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/416/workflows/777dcb66-7807-4f8f-bf79-6c359c8e0deb] , [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/416/workflows/eb971fbd-fd9c-47f6-b402-3169aad5d798]| was (Author: brandon.williams): Alright, round 2. This is Brad's patch and then the zip loading returned on top of that. ||Branch||CI| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17417]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/415/workflows/e5c977cc-d2db-4e45-843e-ba0521d5d4f1] , [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/415/workflows/2095aff7-e371-4be3-b9e4-0d98042b027d]| > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17443) testUnwriteableFlushRecovery is never called
[ https://issues.apache.org/jira/browse/CASSANDRA-17443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514122#comment-17514122 ] Ekaterina Dimitrova commented on CASSANDRA-17443: - I think (based on quick git blame) this test was added by [~barnie] in CASSANDRA-11828 so I guess it will be a quick +1 on his end to confirm it :) > testUnwriteableFlushRecovery is never called > > > Key: CASSANDRA-17443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17443 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Ruslan Fomkin >Priority: Normal > Labels: test > > `testUnwriteableFlushRecovery` of `CommitLogTest` was implemented 6 years ago > and seems to became a dead code immediately. It should be either enabled back > or removed. The source of the test is at > https://github.com/apache/cassandra/blob/2b2c6decfafc6235ad537e72073fab2fd4467e2f/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java#L932 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17411) Network partition causes write ONE timeouts when using counters in Cassandra 4
[
https://issues.apache.org/jira/browse/CASSANDRA-17411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514118#comment-17514118
]
Pere Balaguer commented on CASSANDRA-17411:
---
Hey [~brandon.williams],
I am going to do a bit of an assumption with my comment, please correct me if
I'm wrong.
If you kept the app running for a few more minutes you should have seen other
"got x/y ... timeouts/total_rqs" where (x>0) entries, highlighting the client
still sends requests to the DOWN node which didn't happen in c3. In c3 after in
flight requests are concluded, no more traffic is sent to the DOWN node until
it goes back UP
This behavior (sending queries to a DOWN node) is specially bad when counters
are involved as those do not seem trigger speculative retries and always result
in query timeouts for the client.
> Network partition causes write ONE timeouts when using counters in Cassandra 4
> --
>
> Key: CASSANDRA-17411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17411
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Pere Balaguer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: app.py
>
>
> h5. Affected versions:
> * 4.x
> h5. Observed behavior:
> When executing CL=ONE writes on a table with a counter column, if one of the
> nodes is network partitioned from the others, clients keep sending requests
> to it.
> Even though this may be a "driver" problem, I've been able to reproduce it
> with both java and python datastax drivers using their latest available
> versions and given the behavior only changes depending on the Cassandra
> version, well, here I am.
> h5. Expected behavior:
> In Cassandra 3 after all inflight requests fail (expected), no new requests
> are sent to the partitioned node. The expectation is that Cassandra 4 behaves
> the same way.
> h5. How to reproduce:
> {noformat}
> # Create a cluster with the desired version, will go with 4.x for this example
> ccm create bug-report -v 4.0.3
> ccm populate -n 2:2:2
> ccm start
> # Create schemas and so on
> CQL=$(cat < CONSISTENCY ALL;
> DROP KEYSPACE IF EXISTS demo;
> CREATE KEYSPACE demo WITH REPLICATION = {'class': 'NetworkTopologyStrategy',
> 'dc1': 2, 'dc2': 2, 'dc3': 2};
> CREATE TABLE demo.demo (pk uuid PRIMARY KEY, count counter) WITH compaction =
> {'class': 'LeveledCompactionStrategy'};
> END
> )
> ccm node1 cqlsh --verbose --exec="${CQL}"
> # Launch the attached app.py
> # requires cassandra-driver
> python3 app.py "127.0.0.1" "9042"
> # Wait a bit for the app to settle, proceed to next step once you see 3
> messages in stdout like:
> # 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572
> (0.00) timeouts/total_rqs in the last 1 minute
> # Partition one node with iptables
> iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port 7000 -j
> DROP; iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port
> 9042 -j DROP
> {noformat}
> Some time after executing the iptables command in cassandra-3 the output
> should be similar to:
> {noformat}
> 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:51,576 - target-dc3 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:58,032 - target-dc1 - __main__ - INFO - Got 6/252 (2.380952)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,560 - target-dc2 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,620 - target-dc3 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:58,101 - target-dc1 - __main__ - INFO - Got 2/354 (0.564972)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,602 - target-dc2 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,672 - target-dc3 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:58,153 - target-dc1 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> {noformat}
> as the timeouts/rqs shows, in about 2 minutes the partitioned node stops
> receiving traffic
> while as in cassandra-4
> {noformat}
> 2022-03-01 15:49:39,068 - target-dc3 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:39,107 - target-dc2 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:41,206 - target-dc1 - __main__ - INFO - Got 2/444 (0.450450)
> timeouts/total_rqs in the last 1 minute
>
[jira] [Comment Edited] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[
https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514111#comment-17514111
]
Stefan Miklosovic edited comment on CASSANDRA-17417 at 3/29/22, 2:10 PM:
-
I think that futures are ultimately not necessary plus I believe that
[~e.dimitrova] should test that on Mac she has (or anybody with Mac for that
matter) so I am out of "+1"-ing this if you do not mind.
If only six is necessary, it might be simplified to
{code}
lib_zip = find_zip('six-')
if lib_zip:
sys.path.insert(0, lib_zip)
{code}
for loop is not necessary if we have only one library to load.
was (Author: smiklosovic):
I think that futures are ultimately not necessary plus I believe that
[~e.dimitrova] should test that on Mac she has (or anybody with Mac for that
matter) so I am out of "+1"-ing this if you do not mind.
> Replace use of 'six' compatibility library with python 3 equivalents
>
>
> Key: CASSANDRA-17417
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17417
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Attachments: signature.asc, signature.asc, six.pdf
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple
> utilities for wrapping the differences between Python 2 and Python 3. It is
> intended to support codebases that work on both Python 2 and 3.
> Since CQLSH requires python version >= 3.6, its use can be replaced with
> native python 3 constructs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17150) Guardrails for disk usage
[
https://issues.apache.org/jira/browse/CASSANDRA-17150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17150:
--
Change Category: Operability
Complexity: Normal
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> Guardrails for disk usage
> -
>
> Key: CASSANDRA-17150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17150
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for disk usage establishing soft/hard limits on the percentage
> of used disk space. For example:
> {code}
> # Warning threshold to warn when local disk usage exceeds threshold. Valid
> values: (1, 100]
> # Defaults to -1 to disable.
> # disk_usage_percentage_warn_threshold: -1
> # Failure threshold to reject write requests if replica disk usage exceeds
> threshold. Valid values: (1, 100]
> # Defaults to -1 to disable.
> # disk_usage_percentage_failure_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17493) Shutdown all ScheduledExecutors as part of node drainage
[ https://issues.apache.org/jira/browse/CASSANDRA-17493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514114#comment-17514114 ] Stefan Miklosovic commented on CASSANDRA-17493: --- [~sathyakplm] We are implementing CASSANDRA-17180 where we want to start a periodic task and we want to be sure that such task will not be executed on drain and we do not want to hold any Future reference to it or anything like that. So we are relying on the fact that periodic task executors are stopped as part of the drain which is not happening now. > Shutdown all ScheduledExecutors as part of node drainage > > > Key: CASSANDRA-17493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17493 > Project: Cassandra > Issue Type: Bug >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > > We are currently shutting down only non-periodic executors in > StorageService#drain. We should shut down all of them. As of now, there does > not seem to be any reason why these executors should be active. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514111#comment-17514111 ] Stefan Miklosovic commented on CASSANDRA-17417: --- I think that future are ultimately not necessary plus I believe that [~e.dimitrova] should that that on Mac she has (or anybody with Mac for that matter) so I am out of "+1"-ing this if you do not mind. > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514111#comment-17514111 ] Stefan Miklosovic edited comment on CASSANDRA-17417 at 3/29/22, 2:02 PM: - I think that futures are ultimately not necessary plus I believe that [~e.dimitrova] should test that on Mac she has (or anybody with Mac for that matter) so I am out of "+1"-ing this if you do not mind. was (Author: smiklosovic): I think that future are ultimately not necessary plus I believe that [~e.dimitrova] should that that on Mac she has (or anybody with Mac for that matter) so I am out of "+1"-ing this if you do not mind. > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17493) Shutdown all ScheduledExecutors as part of node drainage
[ https://issues.apache.org/jira/browse/CASSANDRA-17493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514092#comment-17514092 ] Sathyanarayanan Saravanamuthu commented on CASSANDRA-17493: --- Hi [~smiklosovic], why is this a bug? What benefits do the changes in the PR bring in? > Shutdown all ScheduledExecutors as part of node drainage > > > Key: CASSANDRA-17493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17493 > Project: Cassandra > Issue Type: Bug >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > > We are currently shutting down only non-periodic executors in > StorageService#drain. We should shut down all of them. As of now, there does > not seem to be any reason why these executors should be active. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17417: - Status: Patch Available (was: Open) > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514049#comment-17514049
]
ROCHETEAU Antoine commented on CASSANDRA-10537:
---
Good to hear :). Rebase is done on both repo and I will try to keep them up to
date on a regular basis
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17492) OWASP failures on lower branches 3/2022
[ https://issues.apache.org/jira/browse/CASSANDRA-17492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17492: - Fix Version/s: 3.0.27 3.11.13 (was: 3.0.x) (was: 3.11.x) Since Version: NA Source Control Link: https://github.com/apache/cassandra/commit/fd1f245353584833b8569666c115c6c64755c2c9 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thanks! > OWASP failures on lower branches 3/2022 > --- > > Key: CASSANDRA-17492 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17492 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.27, 3.11.13 > > > In CASSANDRA-17459 we fixed some security problems that we missed for 3.0 and > 3.11: CASSANDRA-17460 for jackson and the driver suppression. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (7b58b79 -> c6cf374)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 7b58b79 Merge branch 'cassandra-4.0' into trunk new fd1f245 Suppress CVE-2021-44521 new 2c625e1 Merge branch 'cassandra-3.0' into cassandra-3.11 new a6864cc Upgrade jackson to 2.13.2 new 897a251 Merge branch 'cassandra-3.11' into cassandra-4.0 new c6cf374 Merge branch 'cassandra-4.0' into trunk The 5 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (0089858 -> 897a251)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 0089858 Shut repair task executor down without interruption to avoid compromising shared channel proxies new fd1f245 Suppress CVE-2021-44521 new 2c625e1 Merge branch 'cassandra-3.0' into cassandra-3.11 new a6864cc Upgrade jackson to 2.13.2 new 897a251 Merge branch 'cassandra-3.11' into cassandra-4.0 The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 02/02: Upgrade jackson to 2.13.2
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit a6864cccd4c0631a3ae88242739bc592755c349c Author: Brandon Williams AuthorDate: Mon Mar 28 09:57:55 2022 -0500 Upgrade jackson to 2.13.2 Patch by brandonwilliams; reviewed by bereng for CASSANDRA-17492 --- CHANGES.txt | 1 + build.xml | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index a7d74f2..7aef38b 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.11.13 + * Upgrade jackson to 2.13.2 (CASSANDRA-17492) * emit warning on keyspace creation when replication factor is bigger than the number of nodes (CASSANDRA-16747) * Fix snapshot true size calculation (CASSANDRA-17267) * Validate existence of DCs when repairing (CASSANDRA-17407) diff --git a/build.xml b/build.xml index de1e9d2..0081556 100644 --- a/build.xml +++ b/build.xml @@ -362,9 +362,9 @@ - - - + + + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 897a2519bff89b4789ec128d9cfe7d6af9749a63 Merge: 0089858 a6864cc Author: Brandon Williams AuthorDate: Tue Mar 29 07:15:46 2022 -0500 Merge branch 'cassandra-3.11' into cassandra-4.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit c6cf374c9636020bb6ee428aa88a8736d4a9f115 Merge: 7b58b79 897a251 Author: Brandon Williams AuthorDate: Tue Mar 29 07:15:59 2022 -0500 Merge branch 'cassandra-4.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (3a7e5f8 -> a6864cc)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 3a7e5f8 Revert "Upgrade slf4j to 1.7.25" new fd1f245 Suppress CVE-2021-44521 new 2c625e1 Merge branch 'cassandra-3.0' into cassandra-3.11 new a6864cc Upgrade jackson to 2.13.2 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 2 ++ build.xml| 6 +++--- 3 files changed, 6 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/02: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 2c625e10b8586cbde9f671f870a95b238140cda8 Merge: 3a7e5f8 fd1f245 Author: Brandon Williams AuthorDate: Tue Mar 29 07:12:51 2022 -0500 Merge branch 'cassandra-3.0' into cassandra-3.11 .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) diff --cc CHANGES.txt index 8e60deb,eba1ec8..a7d74f2 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,9 -1,5 +1,10 @@@ -3.0.27 +3.11.13 + * emit warning on keyspace creation when replication factor is bigger than the number of nodes (CASSANDRA-16747) + * Fix snapshot true size calculation (CASSANDRA-17267) + * Validate existence of DCs when repairing (CASSANDRA-17407) + * dropping of a materialized view creates a snapshot with dropped- prefix (CASSANDRA-17415) +Merged from 3.0: + * Suppress CVE-2021-44521 (CASSANDRA-17492) * ConnectionLimitHandler may leaks connection count if remote connection drops (CASSANDRA-17252) * Require ant >= 1.10 (CASSANDRA-17428) * Disallow CONTAINS for UPDATE and DELETE (CASSANDRA-15266) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: Suppress CVE-2021-44521
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-3.0 by this push: new fd1f245 Suppress CVE-2021-44521 fd1f245 is described below commit fd1f245353584833b8569666c115c6c64755c2c9 Author: Brandon Williams AuthorDate: Mon Mar 28 10:39:22 2022 -0500 Suppress CVE-2021-44521 Patch by brandonwilliams; reviewed by bereng for CASSANDRA-17492 --- .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) diff --git a/.build/dependency-check-suppressions.xml b/.build/dependency-check-suppressions.xml index 798c71f..4c1c054 100644 --- a/.build/dependency-check-suppressions.xml +++ b/.build/dependency-check-suppressions.xml @@ -55,6 +55,7 @@ ^pkg:maven/com\.datastax\.cassandra/cassandra\-driver\-core@.*$ CVE-2020-13946 CVE-2020-17516 +CVE-2021-44521 diff --git a/CHANGES.txt b/CHANGES.txt index 28fe6ec..eba1ec8 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0.27 + * Suppress CVE-2021-44521 (CASSANDRA-17492) * ConnectionLimitHandler may leaks connection count if remote connection drops (CASSANDRA-17252) * Require ant >= 1.10 (CASSANDRA-17428) * Disallow CONTAINS for UPDATE and DELETE (CASSANDRA-15266) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514034#comment-17514034 ] Brandon Williams edited comment on CASSANDRA-17417 at 3/29/22, 11:42 AM: - Alright, round 2. This is Brad's patch and then the zip loading returned on top of that. ||Branch||CI| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17417]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/415/workflows/e5c977cc-d2db-4e45-843e-ba0521d5d4f1] , [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/415/workflows/2095aff7-e371-4be3-b9e4-0d98042b027d]| was (Author: brandon.williams): Alright, round 2. This is Brad's patch and then the zip loading returned on top of that. ||Branch||CI| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17417]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/415/workflows/e5c977cc-d2db-4e45-843e-ba0521d5d4f1] , [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/415/workflows/2095aff7-e371-4be3-b9e4-0d98042b027d| > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514034#comment-17514034 ] Brandon Williams commented on CASSANDRA-17417: -- Alright, round 2. This is Brad's patch and then the zip loading returned on top of that. ||Branch||CI| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17417]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/415/workflows/e5c977cc-d2db-4e45-843e-ba0521d5d4f1] , [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/415/workflows/2095aff7-e371-4be3-b9e4-0d98042b027d| > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-10190: Assignee: Patrick Bannister (was: Brandon Williams) > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh, pull-request-available > Fix For: 4.0-alpha4, 4.0 > > Attachments: > 0001-Fix-issues-from-version-specific-logic-commit.patch, > 0001-Update-six-to-1.12.0.patch, > 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch, Screen Shot > 2020-02-14 at 10.40.05 AM.png, coverage_notes.txt > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-10190: Assignee: Brandon Williams (was: Patrick Bannister) > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Brandon Williams >Priority: Normal > Labels: cqlsh, pull-request-available > Fix For: 4.0-alpha4, 4.0 > > Attachments: > 0001-Fix-issues-from-version-specific-logic-commit.patch, > 0001-Update-six-to-1.12.0.patch, > 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch, Screen Shot > 2020-02-14 at 10.40.05 AM.png, coverage_notes.txt > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514011#comment-17514011 ] Brandon Williams commented on CASSANDRA-17417: -- I seem to recall actually pulling from pip was problematic and this is a release artifact, but the one used is in fact from pip, just not directly. > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17466) Shut repair task executor down without interruption to avoid compromising shared channel proxies
[
https://issues.apache.org/jira/browse/CASSANDRA-17466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17513991#comment-17513991
]
Berenguer Blasi commented on CASSANDRA-17466:
-
I haven't dug deep. But could sbdy in the know check if this commit be related
to the recent rise in trunk failures on commit log closure?
> Shut repair task executor down without interruption to avoid compromising
> shared channel proxies
>
>
> Key: CASSANDRA-17466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1, 4.0.4
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> If a {{RepairJob}} gets past validation, it builds a list of {{SyncTask}}
> items and fires them off. If any one of those fails, we grab the relevant
> exception and throw it up from {{RepairJob}} to {{RepairSession}}.
> {noformat}
> ERROR 2022-03-09T23:53:36,721
> [Stream-Deserializer-/10.246.3.102:7000-d97958c4]
> org.apache.cassandra.streaming.StreamSession:1110 - [Stream
> #07c55da0-a047-11ec-8122-ab911c7a993f] Remote peer /10.246.3.102:7000 failed
> stream session.
> {noformat}
> {{RepairSession}} then marks itself as being terminated and clears its
> internal maps of active validations and sync tasks, but immediately before it
> does that, it calls {{shutdownNow()}} on the executor that executes those
> tasks. In the case of our failing stream session, we may still have other
> running stream tasks whose threads' interrupt flag has been set, and this can
> have some unintended negative consequences, because any {{ChannelProxy}}
> interrupted in the middle of a blocking operation will both be closed and
> throw a {{ClosedByInterruptException}}. (Keep in mind that we share
> {{ChannelProxy}} instances outside a few specific cases, like those
> introduced in CASSANDRA-15666.)
> We've seen this manifest in production in a couple ways, both of them while
> trying to read from the {{peers_v2}} system table:
> {noformat}
> Exception in thread Thread[RepairJobTask:23,5,main]"^M
> exception="FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-99-big-Data.db
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.getFileDataInput(SSTableReader.java:1628)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.(AbstractSSTableIterator.java:96)
> at
> org.apache.cassandra.db.columniterator.SSTableIterator.(SSTableIterator.java:48)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableReader.iterator(BigTableReader.java:75)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableReader.iterator(BigTableReader.java:67)
> at
> org.apache.cassandra.db.StorageHook$1.makeRowIterator(StorageHook.java:87)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndSSTablesInTimestampOrder(SinglePartitionReadCommand.java:897)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(SinglePartitionReadCommand.java:605)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDisk(SinglePartitionReadCommand.java:578)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryStorage(SinglePartitionReadCommand.java:412)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:414)
> at
> org.apache.cassandra.db.SinglePartitionReadQuery$Group.executeLocally(SinglePartitionReadQuery.java:242)
> at
> org.apache.cassandra.db.SinglePartitionReadQuery$Group.executeInternal(SinglePartitionReadQuery.java:216)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:458)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeLocally(SelectStatement.java:442)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeLocally(SelectStatement.java:96)
> at
>
[jira] [Comment Edited] (CASSANDRA-17466) Shut repair task executor down without interruption to avoid compromising shared channel proxies
[
https://issues.apache.org/jira/browse/CASSANDRA-17466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17513991#comment-17513991
]
Berenguer Blasi edited comment on CASSANDRA-17466 at 3/29/22, 10:37 AM:
I haven't dug deep. But could sbdy in the know check if this commit could be
related to the recent rise in trunk failures on commit log closure please?
was (Author: bereng):
I haven't dug deep. But could sbdy in the know check if this commit be related
to the recent rise in trunk failures on commit log closure?
> Shut repair task executor down without interruption to avoid compromising
> shared channel proxies
>
>
> Key: CASSANDRA-17466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1, 4.0.4
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> If a {{RepairJob}} gets past validation, it builds a list of {{SyncTask}}
> items and fires them off. If any one of those fails, we grab the relevant
> exception and throw it up from {{RepairJob}} to {{RepairSession}}.
> {noformat}
> ERROR 2022-03-09T23:53:36,721
> [Stream-Deserializer-/10.246.3.102:7000-d97958c4]
> org.apache.cassandra.streaming.StreamSession:1110 - [Stream
> #07c55da0-a047-11ec-8122-ab911c7a993f] Remote peer /10.246.3.102:7000 failed
> stream session.
> {noformat}
> {{RepairSession}} then marks itself as being terminated and clears its
> internal maps of active validations and sync tasks, but immediately before it
> does that, it calls {{shutdownNow()}} on the executor that executes those
> tasks. In the case of our failing stream session, we may still have other
> running stream tasks whose threads' interrupt flag has been set, and this can
> have some unintended negative consequences, because any {{ChannelProxy}}
> interrupted in the middle of a blocking operation will both be closed and
> throw a {{ClosedByInterruptException}}. (Keep in mind that we share
> {{ChannelProxy}} instances outside a few specific cases, like those
> introduced in CASSANDRA-15666.)
> We've seen this manifest in production in a couple ways, both of them while
> trying to read from the {{peers_v2}} system table:
> {noformat}
> Exception in thread Thread[RepairJobTask:23,5,main]"^M
> exception="FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-99-big-Data.db
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.getFileDataInput(SSTableReader.java:1628)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.(AbstractSSTableIterator.java:96)
> at
> org.apache.cassandra.db.columniterator.SSTableIterator.(SSTableIterator.java:48)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableReader.iterator(BigTableReader.java:75)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableReader.iterator(BigTableReader.java:67)
> at
> org.apache.cassandra.db.StorageHook$1.makeRowIterator(StorageHook.java:87)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndSSTablesInTimestampOrder(SinglePartitionReadCommand.java:897)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(SinglePartitionReadCommand.java:605)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDisk(SinglePartitionReadCommand.java:578)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryStorage(SinglePartitionReadCommand.java:412)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:414)
> at
> org.apache.cassandra.db.SinglePartitionReadQuery$Group.executeLocally(SinglePartitionReadQuery.java:242)
> at
> org.apache.cassandra.db.SinglePartitionReadQuery$Group.executeInternal(SinglePartitionReadQuery.java:216)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:458)
> at
[jira] [Commented] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17513943#comment-17513943
]
Berenguer Blasi commented on CASSANDRA-10537:
-
[~Antoine Rocheteau] your latest CI looks much better. If you could rebase the
C* trunk PR when you have some time that'd be awesome, so it would be easier to
match failures to the current state.
Now we need to wait for [~blerer] or some other committer to take a look here.
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
