[jira] [Updated] (CASSANDRA-17839) Out of range exception on column index downsampling
[
https://issues.apache.org/jira/browse/CASSANDRA-17839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17839:
Status: Ready to Commit (was: Review In Progress)
+1
> Out of range exception on column index downsampling
> ---
>
> Key: CASSANDRA-17839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17839
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> We've seen a histogram overflow exception in the wild; an
> IllegalArgumentException w/{{{}Out of range{}}} on {{{}Ints.checkedCast{}}}.
> Looks like we need to tune the {{defaultPartitionSizeHistogram}} a bit and be
> more graceful about handling and degrading gracefully in {{SegmentedFile}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17830) Read Unavailables due to GossipStage backlog with high number of pending tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-17830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17830: Status: Ready to Commit (was: Review In Progress) +1 > Read Unavailables due to GossipStage backlog with high number of pending tasks > -- > > Key: CASSANDRA-17830 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17830 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In CASSANDRA-16759, like we changed from iterating over liveMembers + > unreachableMembers to all keys in endpointStateMap > [here|https://github.com/apache/cassandra/commit/2fba5c80ce7bf71d04c62043ffa1088b9e832d83#diff-99267a2170b04fd7dd24d6c6bf2ba1fc26d6dc896cd74f8c5bd56c476e2540e4R208]. > We can have an endpoint in quarantine (in justRemovedEndpoints) which has no > release version information. In this case we don't memoize the value and > instead recalculate the min version for every endpoint for every incoming > gossip message... which can be bad. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17830) Read Unavailables due to GossipStage backlog with high number of pending tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-17830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17830: Status: Review In Progress (was: Patch Available) > Read Unavailables due to GossipStage backlog with high number of pending tasks > -- > > Key: CASSANDRA-17830 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17830 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In CASSANDRA-16759, like we changed from iterating over liveMembers + > unreachableMembers to all keys in endpointStateMap > [here|https://github.com/apache/cassandra/commit/2fba5c80ce7bf71d04c62043ffa1088b9e832d83#diff-99267a2170b04fd7dd24d6c6bf2ba1fc26d6dc896cd74f8c5bd56c476e2540e4R208]. > We can have an endpoint in quarantine (in justRemovedEndpoints) which has no > release version information. In this case we don't memoize the value and > instead recalculate the min version for every endpoint for every incoming > gossip message... which can be bad. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17830) Read Unavailables due to GossipStage backlog with high number of pending tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-17830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17830: Reviewers: Marcus Eriksson > Read Unavailables due to GossipStage backlog with high number of pending tasks > -- > > Key: CASSANDRA-17830 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17830 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In CASSANDRA-16759, like we changed from iterating over liveMembers + > unreachableMembers to all keys in endpointStateMap > [here|https://github.com/apache/cassandra/commit/2fba5c80ce7bf71d04c62043ffa1088b9e832d83#diff-99267a2170b04fd7dd24d6c6bf2ba1fc26d6dc896cd74f8c5bd56c476e2540e4R208]. > We can have an endpoint in quarantine (in justRemovedEndpoints) which has no > release version information. In this case we don't memoize the value and > instead recalculate the min version for every endpoint for every incoming > gossip message... which can be bad. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17613) Avoid getting hanging repairs due to repair message timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577428#comment-17577428 ] Marcus Eriksson commented on CASSANDRA-17613: - 4.1: https://github.com/apache/cassandra/pull/1775 / https://app.circleci.com/pipelines/github/krummas/cassandra/809/workflows/f99a3c25-0d16-4bd4-89db-d1c835ce7b6c trunk: https://github.com/apache/cassandra/pull/1776 / https://app.circleci.com/pipelines/github/krummas/cassandra/807/workflows/72a6a1ef-2052-480e-a396-0cccfdf17efa > Avoid getting hanging repairs due to repair message timeouts > > > Key: CASSANDRA-17613 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17613 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.1-beta > > Time Spent: 20m > Remaining Estimate: 0h > > In 4.0 repair messages can get expired before reaching a replica, this causes > repairs to hang. > CASSANDRA-16909 is meant to fix this, but we need a stopgap fix in 4.0. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17613) Avoid getting hanging repairs due to repair message timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17576877#comment-17576877 ] Marcus Eriksson commented on CASSANDRA-17613: - bq. should we block 4.1? Yes, I think so - I'll provide a 4.1 PR tomorrow > Avoid getting hanging repairs due to repair message timeouts > > > Key: CASSANDRA-17613 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17613 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.1-beta > > Time Spent: 10m > Remaining Estimate: 0h > > In 4.0 repair messages can get expired before reaching a replica, this causes > repairs to hang. > CASSANDRA-16909 is meant to fix this, but we need a stopgap fix in 4.0. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17800) Add some convenience logging to nodetool import
[ https://issues.apache.org/jira/browse/CASSANDRA-17800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17800: Status: Ready to Commit (was: Review In Progress) +1 tiny comment on the PR, feel free to change on commit > Add some convenience logging to nodetool import > --- > > Key: CASSANDRA-17800 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17800 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Nodetool import could use a UUID tagged to a given import process to make > tracking the flow of the import easier from an operational perspective. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17800) Add some convenience logging to nodetool import
[ https://issues.apache.org/jira/browse/CASSANDRA-17800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17800: Reviewers: Marcus Eriksson Status: Review In Progress (was: Patch Available) > Add some convenience logging to nodetool import > --- > > Key: CASSANDRA-17800 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17800 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Nodetool import could use a UUID tagged to a given import process to make > tracking the flow of the import easier from an operational perspective. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17777) Skip sstable startup checks for dropped system tables
[ https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575794#comment-17575794 ] Marcus Eriksson commented on CASSANDRA-1: - +1 > Skip sstable startup checks for dropped system tables > - > > Key: CASSANDRA-1 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1 > Project: Cassandra > Issue Type: Improvement > Components: Local/Startup and Shutdown >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.2 > > Time Spent: 10m > Remaining Estimate: 0h > > In CASSANDRA-8049 we changed our behavior to explicitly not startup while > iterating over the whole data file directory before loading schema. In the > case where you have (admittedly _very)_ old files left around from dropped > system tables from old C* versions (think 1.0 era), you can end up with > clusters that won't start due to what was, at the time, normal operations. > We should change from hard killing nodes to instead warn operators they have > leftovers of old system tables that need to be cleaned up. Ideally these > files would be manually removed by operators before the upgrade to new > versions however we can't always rely on this so killing nodes on startup for > this specific case is suboptimal. We certainly still need to log the found > files to give operators an indication of what needs to be cleaned up. > While we can't load the schema to make sure all directories are safe, we > _can_ know which tables exist in the system keyspace so we should be able to > safely modify this startup check to log rather than kill for system tables > only. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17801) NPE bug in streaming checking if SSTable is being repaired
[
https://issues.apache.org/jira/browse/CASSANDRA-17801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17801:
Reviewers: Marcus Eriksson, Marcus Eriksson
Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson)
Status: Review In Progress (was: Patch Available)
> NPE bug in streaming checking if SSTable is being repaired
> --
>
> Key: CASSANDRA-17801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17801
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Streaming hit a race condition where a SSTable was being repaired, but the
> moment we try to check the repair ID the repair was over
> {code}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.streaming.CassandraStreamManager.lambda$null$0(CassandraStreamManager.java:110)
> at com.google.common.collect.Iterators$5.computeNext(Iterators.java:639)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136)
> at
> org.apache.cassandra.db.streaming.CassandraStreamManager.lambda$createOutgoingStreams$1(CassandraStreamManager.java:121)
> at
> org.apache.cassandra.db.ColumnFamilyStore.select(ColumnFamilyStore.java:2000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.selectAndReference(ColumnFamilyStore.java:1976)
> at
> org.apache.cassandra.db.streaming.CassandraStreamManager.createOutgoingStreams(CassandraStreamManager.java:96)
> at
> org.apache.cassandra.streaming.StreamSession.getOutgoingStreamsForRanges(StreamSession.java:481)
> at
> org.apache.cassandra.streaming.StreamSession.addTransferRanges(StreamSession.java:440)
> at
> org.apache.cassandra.streaming.StreamSession.lambda$null$6(StreamSession.java:816)
> at java.base/java.lang.Iterable.forEach(Iterable.java:75)
> at
> org.apache.cassandra.streaming.StreamSession.lambda$processStreamRequests$7(StreamSession.java:812)
> at java.base/java.util.Map.forEach(Map.java:661)
> at
> org.apache.cassandra.streaming.StreamSession.processStreamRequests(StreamSession.java:808)
> at
> org.apache.cassandra.streaming.StreamSession.prepareAsync(StreamSession.java:740)
> at
> org.apache.cassandra.streaming.StreamSession.lambda$prepare$3(StreamSession.java:720)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17801) NPE bug in streaming checking if SSTable is being repaired
[
https://issues.apache.org/jira/browse/CASSANDRA-17801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17801:
Status: Ready to Commit (was: Review In Progress)
+1
> NPE bug in streaming checking if SSTable is being repaired
> --
>
> Key: CASSANDRA-17801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17801
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Streaming hit a race condition where a SSTable was being repaired, but the
> moment we try to check the repair ID the repair was over
> {code}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.streaming.CassandraStreamManager.lambda$null$0(CassandraStreamManager.java:110)
> at com.google.common.collect.Iterators$5.computeNext(Iterators.java:639)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136)
> at
> org.apache.cassandra.db.streaming.CassandraStreamManager.lambda$createOutgoingStreams$1(CassandraStreamManager.java:121)
> at
> org.apache.cassandra.db.ColumnFamilyStore.select(ColumnFamilyStore.java:2000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.selectAndReference(ColumnFamilyStore.java:1976)
> at
> org.apache.cassandra.db.streaming.CassandraStreamManager.createOutgoingStreams(CassandraStreamManager.java:96)
> at
> org.apache.cassandra.streaming.StreamSession.getOutgoingStreamsForRanges(StreamSession.java:481)
> at
> org.apache.cassandra.streaming.StreamSession.addTransferRanges(StreamSession.java:440)
> at
> org.apache.cassandra.streaming.StreamSession.lambda$null$6(StreamSession.java:816)
> at java.base/java.lang.Iterable.forEach(Iterable.java:75)
> at
> org.apache.cassandra.streaming.StreamSession.lambda$processStreamRequests$7(StreamSession.java:812)
> at java.base/java.util.Map.forEach(Map.java:661)
> at
> org.apache.cassandra.streaming.StreamSession.processStreamRequests(StreamSession.java:808)
> at
> org.apache.cassandra.streaming.StreamSession.prepareAsync(StreamSession.java:740)
> at
> org.apache.cassandra.streaming.StreamSession.lambda$prepare$3(StreamSession.java:720)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17777) Skip sstable startup checks for dropped system tables
[ https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-1: Status: Ready to Commit (was: Review In Progress) +1 > Skip sstable startup checks for dropped system tables > - > > Key: CASSANDRA-1 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1 > Project: Cassandra > Issue Type: Improvement > Components: Local/Startup and Shutdown >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In CASSANDRA-8049 we changed our behavior to explicitly not startup while > iterating over the whole data file directory before loading schema. In the > case where you have (admittedly _very)_ old files left around from dropped > system tables from old C* versions (think 1.0 era), you can end up with > clusters that won't start due to what was, at the time, normal operations. > We should change from hard killing nodes to instead warn operators they have > leftovers of old system tables that need to be cleaned up. Ideally these > files would be manually removed by operators before the upgrade to new > versions however we can't always rely on this so killing nodes on startup for > this specific case is suboptimal. We certainly still need to log the found > files to give operators an indication of what needs to be cleaned up. > While we can't load the schema to make sure all directories are safe, we > _can_ know which tables exist in the system keyspace so we should be able to > safely modify this startup check to log rather than kill for system tables > only. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17777) Skip sstable startup checks for dropped system tables
[ https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-1: Reviewers: Marcus Eriksson Status: Review In Progress (was: Patch Available) > Skip sstable startup checks for dropped system tables > - > > Key: CASSANDRA-1 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1 > Project: Cassandra > Issue Type: Improvement > Components: Local/Startup and Shutdown >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In CASSANDRA-8049 we changed our behavior to explicitly not startup while > iterating over the whole data file directory before loading schema. In the > case where you have (admittedly _very)_ old files left around from dropped > system tables from old C* versions (think 1.0 era), you can end up with > clusters that won't start due to what was, at the time, normal operations. > We should change from hard killing nodes to instead warn operators they have > leftovers of old system tables that need to be cleaned up. Ideally these > files would be manually removed by operators before the upgrade to new > versions however we can't always rely on this so killing nodes on startup for > this specific case is suboptimal. We certainly still need to log the found > files to give operators an indication of what needs to be cleaned up. > While we can't load the schema to make sure all directories are safe, we > _can_ know which tables exist in the system keyspace so we should be able to > safely modify this startup check to log rather than kill for system tables > only. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17789) Extend nodetool verify with functionality to detect partitions with duplicate keys
[ https://issues.apache.org/jira/browse/CASSANDRA-17789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575096#comment-17575096 ] Marcus Eriksson commented on CASSANDRA-17789: - +1 > Extend nodetool verify with functionality to detect partitions with duplicate > keys > -- > > Key: CASSANDRA-17789 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17789 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > We've seen instances where, during upgrades across major versions and in > mixed version clusters, we end up with data in a table that has duplication > of primary keys. This is obviously an illegal state and being able to quickly > scan for this and log partition keys for which we're seeing this state has > proven quite useful. > It's a fairly small change to verify/scrub to integrate this extra > functionality. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17733) min_tracked_partition_size_bytes should not have the suffix prefix
[ https://issues.apache.org/jira/browse/CASSANDRA-17733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563251#comment-17563251 ] Marcus Eriksson commented on CASSANDRA-17733: - +1 on just renaming it, thanks for catching this > min_tracked_partition_size_bytes should not have the suffix prefix > -- > > Key: CASSANDRA-17733 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17733 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.x > > > min_tracked_partition_size_bytes was added in CASSANDRA-16310. It should have > not been added with the unit suffix anymore as confirmed on the commit. > It is also confusing now when users can add unit of their choice. > We have two options: > * keep it with annotation and add also version without the suffix > * rename it as we are still alpha and API changes can be done for bug > fixing. Not sure whether we need an approval on the ML for this one. > CC [~ycai] , [~marcuse] and [~dcapwell] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17614) Fix repair_tests/repair_test.py::TestRepair::test_non_replicated_ks_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17614:
Fix Version/s: 4.0.4
Since Version: 4.0.3
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/e76008d0a71bce385210e7cdf820c9b6459b8c80
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
and committed, thanks!
> Fix repair_tests/repair_test.py::TestRepair::test_non_replicated_ks_repair
> --
>
> Key: CASSANDRA-17614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.4
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Seems we need to ignore non-related keyspaces after CASSANDRA-17594
> https://ci-cassandra.apache.org/job/Cassandra-4.0/389/testReport/dtest.repair_tests.repair_test/TestRepair/test_non_replicated_ks_repair/
> {code}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node3] 'ERROR [Repair-Task:1] 2022-05-05 15:07:53,951
> RepairRunnable.java:178 - Repair 237883a0-cc85-11ec-8760-0b7eabc00dbb
> failed:\njava.lang.RuntimeException: Nothing to repair for (0,1] in
> system_traces - aborting\n\tat
> org.apache.cassandra.repair.RepairRunnable.getNeighborsAndRanges(RepairRunnable.java:338)\n\tat
>
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:265)\n\tat
>
> org.apache.cassandra.repair.RepairRunnable.run(RepairRunnable.java:241)\n\tat
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.lang.Thread.run(Thread.java:748)']
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17614) Fix repair_tests/repair_test.py::TestRepair::test_non_replicated_ks_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17614:
Test and Documentation Plan: jenkins run
Status: Patch Available (was: Open)
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1689/
https://github.com/apache/cassandra-dtest/pull/194
> Fix repair_tests/repair_test.py::TestRepair::test_non_replicated_ks_repair
> --
>
> Key: CASSANDRA-17614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> Seems we need to ignore non-related keyspaces after CASSANDRA-17594
> https://ci-cassandra.apache.org/job/Cassandra-4.0/389/testReport/dtest.repair_tests.repair_test/TestRepair/test_non_replicated_ks_repair/
> {code}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node3] 'ERROR [Repair-Task:1] 2022-05-05 15:07:53,951
> RepairRunnable.java:178 - Repair 237883a0-cc85-11ec-8760-0b7eabc00dbb
> failed:\njava.lang.RuntimeException: Nothing to repair for (0,1] in
> system_traces - aborting\n\tat
> org.apache.cassandra.repair.RepairRunnable.getNeighborsAndRanges(RepairRunnable.java:338)\n\tat
>
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:265)\n\tat
>
> org.apache.cassandra.repair.RepairRunnable.run(RepairRunnable.java:241)\n\tat
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.lang.Thread.run(Thread.java:748)']
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17614) Fix repair_tests/repair_test.py::TestRepair::test_non_replicated_ks_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17614:
Bug Category: Parent values: Degradation(12984)Level 1 values: Other
Exception(12998)
Complexity: Low Hanging Fruit
Discovered By: DTest
Severity: Low
Status: Open (was: Triage Needed)
> Fix repair_tests/repair_test.py::TestRepair::test_non_replicated_ks_repair
> --
>
> Key: CASSANDRA-17614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> Seems we need to ignore non-related keyspaces after CASSANDRA-17594
> https://ci-cassandra.apache.org/job/Cassandra-4.0/389/testReport/dtest.repair_tests.repair_test/TestRepair/test_non_replicated_ks_repair/
> {code}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node3] 'ERROR [Repair-Task:1] 2022-05-05 15:07:53,951
> RepairRunnable.java:178 - Repair 237883a0-cc85-11ec-8760-0b7eabc00dbb
> failed:\njava.lang.RuntimeException: Nothing to repair for (0,1] in
> system_traces - aborting\n\tat
> org.apache.cassandra.repair.RepairRunnable.getNeighborsAndRanges(RepairRunnable.java:338)\n\tat
>
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:265)\n\tat
>
> org.apache.cassandra.repair.RepairRunnable.run(RepairRunnable.java:241)\n\tat
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.lang.Thread.run(Thread.java:748)']
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17614) Fix repair_tests/repair_test.py::TestRepair::test_non_replicated_ks_repair
Marcus Eriksson created CASSANDRA-17614:
---
Summary: Fix
repair_tests/repair_test.py::TestRepair::test_non_replicated_ks_repair
Key: CASSANDRA-17614
URL: https://issues.apache.org/jira/browse/CASSANDRA-17614
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
Seems we need to ignore non-related keyspaces after CASSANDRA-17594
https://ci-cassandra.apache.org/job/Cassandra-4.0/389/testReport/dtest.repair_tests.repair_test/TestRepair/test_non_replicated_ks_repair/
{code}
Unexpected error found in node logs (see stdout for full details). Errors:
[[node3] 'ERROR [Repair-Task:1] 2022-05-05 15:07:53,951 RepairRunnable.java:178
- Repair 237883a0-cc85-11ec-8760-0b7eabc00dbb
failed:\njava.lang.RuntimeException: Nothing to repair for (0,1] in
system_traces - aborting\n\tat
org.apache.cassandra.repair.RepairRunnable.getNeighborsAndRanges(RepairRunnable.java:338)\n\tat
org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:265)\n\tat
org.apache.cassandra.repair.RepairRunnable.run(RepairRunnable.java:241)\n\tat
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
java.lang.Thread.run(Thread.java:748)']
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17613) Avoid getting hanging repairs due to repair message timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17613: Test and Documentation Plan: cci run Status: Patch Available (was: Open) https://github.com/apache/cassandra/pull/1611 * increases timeout from 10s to 1 minute for the repair messages * additionally bumps timeout for VALIDATION_RSP to 5 minutes * adds an error callback when sending SYNC_REQ and VALIDATION_REQ messages to avoid the hanging repairs tests: https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F17613=all > Avoid getting hanging repairs due to repair message timeouts > > > Key: CASSANDRA-17613 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17613 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.1.x > > > In 4.0 repair messages can get expired before reaching a replica, this causes > repairs to hang. > CASSANDRA-16909 is meant to fix this, but we need a stopgap fix in 4.0. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17613) Avoid getting hanging repairs due to repair message timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17613: Bug Category: Parent values: Degradation(12984)Level 1 values: Slow Use Case(12996) Complexity: Low Hanging Fruit Discovered By: Adhoc Test Fix Version/s: 4.0.x 4.1.x Reviewers: David Capwell Severity: Normal Status: Open (was: Triage Needed) > Avoid getting hanging repairs due to repair message timeouts > > > Key: CASSANDRA-17613 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17613 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.1.x > > > In 4.0 repair messages can get expired before reaching a replica, this causes > repairs to hang. > CASSANDRA-16909 is meant to fix this, but we need a stopgap fix in 4.0. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17613) Avoid getting hanging repairs due to repair message timeouts
Marcus Eriksson created CASSANDRA-17613: --- Summary: Avoid getting hanging repairs due to repair message timeouts Key: CASSANDRA-17613 URL: https://issues.apache.org/jira/browse/CASSANDRA-17613 Project: Cassandra Issue Type: Bug Components: Consistency/Repair Reporter: Marcus Eriksson Assignee: Marcus Eriksson In 4.0 repair messages can get expired before reaching a replica, this causes repairs to hang. CASSANDRA-16909 is meant to fix this, but we need a stopgap fix in 4.0. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17451:
Fix Version/s: 4.1
(was: 4.x)
Since Version: 4.1
Source Control Link:
https://github.com/apache/cassandra/commit/3b648ca09ecfc100d5ad2e3b462d4949dbc03498
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
and committed, thanks
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.1
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname ascii,
> lastname ascii,
> age int
> ) WITH COMPACT STORAGE;
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
>[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins'])
> # FIXME There appears to be some sort of problem with reusable
> cells
> # when executing this query. It's likely that CASSANDRA-9705 will
> # fix this, but I'm not 100% sure.
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479",
>[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'])
> assert_all(cursor, "SELECT * FROM users",
>[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'],
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:157:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For
[jira] [Updated] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17451:
Reviewers: Benedict Elliott Smith (was: Benedict Elliott Smith, Marcus
Eriksson)
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname ascii,
> lastname ascii,
> age int
> ) WITH COMPACT STORAGE;
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
>[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins'])
> # FIXME There appears to be some sort of problem with reusable
> cells
> # when executing this query. It's likely that CASSANDRA-9705 will
> # fix this, but I'm not 100% sure.
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479",
>[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'])
> assert_all(cursor, "SELECT * FROM users",
>[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'],
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:157:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17451:
Reviewers: Benedict Elliott Smith, Marcus Eriksson (was: Benedict Elliott
Smith)
Status: Review In Progress (was: Patch Available)
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname ascii,
> lastname ascii,
> age int
> ) WITH COMPACT STORAGE;
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
>[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins'])
> # FIXME There appears to be some sort of problem with reusable
> cells
> # when executing this query. It's likely that CASSANDRA-9705 will
> # fix this, but I'm not 100% sure.
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479",
>[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'])
> assert_all(cursor, "SELECT * FROM users",
>[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'],
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:157:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17451:
Status: Ready to Commit (was: Review In Progress)
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname ascii,
> lastname ascii,
> age int
> ) WITH COMPACT STORAGE;
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
>[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins'])
> # FIXME There appears to be some sort of problem with reusable
> cells
> # when executing this query. It's likely that CASSANDRA-9705 will
> # fix this, but I'm not 100% sure.
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479",
>[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'])
> assert_all(cursor, "SELECT * FROM users",
>[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'],
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:157:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531156#comment-17531156
]
Marcus Eriksson commented on CASSANDRA-17451:
-
tests:
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1653/
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname ascii,
> lastname ascii,
> age int
> ) WITH COMPACT STORAGE;
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
>[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins'])
> # FIXME There appears to be some sort of problem with reusable
> cells
> # when executing this query. It's likely that CASSANDRA-9705 will
> # fix this, but I'm not 100% sure.
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479",
>[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'])
> assert_all(cursor, "SELECT * FROM users",
>[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'],
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:157:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17379) Fail starting when the same parameter exists more than once in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17379:
Status: Ready to Commit (was: Review In Progress)
> Fail starting when the same parameter exists more than once in cassandra.yaml
> --
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17379) Fail starting when the same parameter exists more than once in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17379:
Source Control Link:
https://github.com/apache/cassandra/commit/7ce140bd1dea311b9f98cdfbcd07dcff9fbd457c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
and committed, thanks!
tests:
https://app.circleci.com/pipelines/github/krummas/cassandra/804/workflows/fd7d187f-2035-49d3-ad98-1da6ad68a38e
> Fail starting when the same parameter exists more than once in cassandra.yaml
> --
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17379) Fail starting when the same parameter exists more than once in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17379:
Summary: Fail starting when the same parameter exists more than once in
cassandra.yaml (was: Fail starting when the same parameter exists more than
once with different values in cassandra.yaml )
> Fail starting when the same parameter exists more than once in cassandra.yaml
> --
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17451:
Test and Documentation Plan: jenkins run
Status: Patch Available (was: Open)
{{BATCH_REMOVE_REQ}} changed from {{UUID}} -> {{TimeUUID}} but the serializer
didn't
https://github.com/apache/cassandra/pull/1594
trying to submit a jenkins run but nothing happens, will update once it goes
through
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname ascii,
> lastname ascii,
> age int
> ) WITH COMPACT STORAGE;
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
>[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins'])
> # FIXME There appears to be some sort of problem with reusable
> cells
> # when executing this query. It's likely that CASSANDRA-9705 will
> # fix this, but I'm not 100% sure.
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479",
>[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'])
> assert_all(cursor, "SELECT * FROM users",
>[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'],
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:157:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17451:
Reviewers: Benedict Elliott Smith
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname ascii,
> lastname ascii,
> age int
> ) WITH COMPACT STORAGE;
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
>[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins'])
> # FIXME There appears to be some sort of problem with reusable
> cells
> # when executing this query. It's likely that CASSANDRA-9705 will
> # fix this, but I'm not 100% sure.
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479",
>[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'])
> assert_all(cursor, "SELECT * FROM users",
>[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'],
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:157:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17451) Flaky upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
[
https://issues.apache.org/jira/browse/CASSANDRA-17451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson reassigned CASSANDRA-17451:
---
Assignee: Marcus Eriksson (was: Brandon Williams)
> Flaky
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk.test_noncomposite_static_cf
> ---
>
> Key: CASSANDRA-17451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17451
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> dtest-upgrade.upgrade_tests.cql_tests
> TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk
> test_noncomposite_static_cf is flaky.
> {code}
> Error Message
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 1 responses and 1
> failures: UNKNOWN from /127.0.0.1:7000" info={'consistency': 'ONE',
> 'required_responses': 1, 'received_responses': 1, 'failures': 1,
> 'error_code_map': {'127.0.0.1': '0x'}}
> Stacktrace
> self = 0x7fc77ceb7d00>
> def test_noncomposite_static_cf(self):
> """ Test non-composite static CF syntax """
> cursor = self.prepare()
>
> # Create
> cursor.execute("""
> CREATE TABLE users (
> userid uuid PRIMARY KEY,
> firstname ascii,
> lastname ascii,
> age int
> ) WITH COMPACT STORAGE;
> """)
>
> for is_upgraded, cursor in self.do_upgrade(cursor):
> logger.debug("Querying {} node".format("upgraded" if is_upgraded
> else "old"))
> cursor.execute("TRUNCATE users")
>
> # Inserts
> cursor.execute("INSERT INTO users (userid, firstname, lastname,
> age) VALUES (550e8400-e29b-41d4-a716-44665544, 'Frodo', 'Baggins', 32)")
> cursor.execute("UPDATE users SET firstname = 'Samwise', lastname
> = 'Gamgee', age = 33 WHERE userid = f47ac10b-58cc-4372-a567-0e02b2c3d479")
>
> # Queries
> assert_one(cursor, "SELECT firstname, lastname FROM users WHERE
> userid = 550e8400-e29b-41d4-a716-44665544", ['Frodo', 'Baggins'])
>
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544",
>[UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins'])
> # FIXME There appears to be some sort of problem with reusable
> cells
> # when executing this query. It's likely that CASSANDRA-9705 will
> # fix this, but I'm not 100% sure.
> assert_one(cursor, "SELECT * FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479",
>[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'])
> assert_all(cursor, "SELECT * FROM users",
>[[UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479'), 33,
> 'Samwise', 'Gamgee'],
> [UUID('550e8400-e29b-41d4-a716-44665544'), 32,
> 'Frodo', 'Baggins']])
>
> # Test batch inserts
> > cursor.execute("""
> BEGIN BATCH
> INSERT INTO users (userid, age) VALUES
> (550e8400-e29b-41d4-a716-44665544, 36)
> UPDATE users SET age = 37 WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> DELETE firstname, lastname FROM users WHERE userid =
> 550e8400-e29b-41d4-a716-44665544
> DELETE firstname, lastname FROM users WHERE userid =
> f47ac10b-58cc-4372-a567-0e02b2c3d479
> APPLY BATCH
> """)
> upgrade_tests/cql_tests.py:157:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17453:
Fix Version/s: 4.1
Since Version: 4.x
Source Control Link:
https://github.com/apache/cassandra/commit/bcf56629e821295a22371c2cf178faae0636c68e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.1
>
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17453:
Status: Ready to Commit (was: Review In Progress)
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17453:
Reviewers: Brandon Williams (was: Brandon Williams, Marcus Eriksson)
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17453:
Reviewers: Brandon Williams, Marcus Eriksson (was: Brandon Williams)
Status: Review In Progress (was: Patch Available)
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17453:
Reviewers: Brandon Williams
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson reassigned CASSANDRA-17453:
---
Assignee: Marcus Eriksson
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Assignee: Marcus Eriksson
>Priority: Normal
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529238#comment-17529238
]
Marcus Eriksson commented on CASSANDRA-16310:
-
I retriggered yesterday as well:
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1638/
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528826#comment-17528826
]
Marcus Eriksson commented on CASSANDRA-16310:
-
seems system schema mutation got > 20kb after top partitions table was added:
https://github.com/apache/cassandra-dtest/pull/189
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1637/
[~bereng] could you review?
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528713#comment-17528713
]
Marcus Eriksson commented on CASSANDRA-16310:
-
thanks. will check
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.1
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528250#comment-17528250
]
Marcus Eriksson edited comment on CASSANDRA-17453 at 4/26/22 3:33 PM:
--
bumping the timeouts seem to fix this
100x run:
https://app.circleci.com/pipelines/github/krummas/cassandra/802/workflows/4ff6be03-bcfc-4aa8-8532-a7e1d340f2c9/jobs/6298
https://github.com/krummas/cassandra/commit/b30628db07021437ed48bf32e86ef5b7115b1609
was (Author: krummas):
bumping the timeouts seem to fix this
https://app.circleci.com/pipelines/github/krummas/cassandra/802/workflows/4ff6be03-bcfc-4aa8-8532-a7e1d340f2c9/jobs/6298
https://github.com/krummas/cassandra/commit/b30628db07021437ed48bf32e86ef5b7115b1609
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17453:
Test and Documentation Plan: repeated cci run
Status: Patch Available (was: Open)
bumping the timeouts seem to fix this
https://app.circleci.com/pipelines/github/krummas/cassandra/802/workflows/4ff6be03-bcfc-4aa8-8532-a7e1d340f2c9/jobs/6298
https://github.com/krummas/cassandra/commit/b30628db07021437ed48bf32e86ef5b7115b1609
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-16310:
Source Control Link:
https://github.com/apache/cassandra/commit/545809616c92a91e4c39d1eedfa65800f25a2a93
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
And committed with the nits fixed, thanks!
tests:
https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F16310=all
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.1
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-16310:
Fix Version/s: 4.1
(was: 4.x)
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.1
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17578) Test failure: org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527629#comment-17527629
]
Marcus Eriksson edited comment on CASSANDRA-17578 at 4/25/22 4:50 PM:
--
this one is weird, checking the logs:
{code}
Compacted (ae3993b0-c2b9-11ec-9067-072fd66af76a) 2 sstables to
[/home/cassandra/cassandra/build/test/cassandra/data/RangeTombstoneTest/StandardInteger1-a84cb360c2b911ec
9067072fd66af76a/nb-31-big,] to level=0. 0.113KiB to 0.056KiB...
{code}
after the major compaction
And comparing the size of the resulting sstable in a successful test shows
exactly the same. So it seems the RT doesn't show up when iterating the rows.
Hacking up the test to actually purge the RT we get this:
{code}
Compacted (22d7a5a0-c4b7-11ec-b705-8f5d495e1ca3) 2 sstables to
[/Users/marcus_eriksson/oss/cassandra/build/test/cassandra/data/RangeTombstoneTest/StandardInteger1-21398600c4b711ecb7058f5d495e1ca3/nb-3-big,]
to level=0. 0.127KiB to 0.030KiB
{code}
was (Author: krummas):
this one is weird, checking the logs:
{code}
Compacted (ae3993b0-c2b9-11ec-9067-072fd66af76a) 2 sstables to
[/home/cassandra/cassandra/build/test/cassandra/data/RangeTombstoneTest/StandardInteger1-a84cb360c2b911ec
9067072fd66af76a/nb-31-big,] to level=0. 0.113KiB to 0.056KiB...
{code}
after the major compaction
And comparing the size of the resulting sstable in a successful test shows
exactly the same. So it seems the RT doesn't show up when iterating the rows.
> Test failure:
> org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction
> -
>
> Key: CASSANDRA-17578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17578
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1099/testReport/org.apache.cassandra.db/RangeTombstoneTest/testRangeTombstoneCompaction_compression_2/
> {code}
> junit.framework.AssertionFailedError: Expecting open marker, got Row: name=8
> | val=8
> at
> org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction(RangeTombstoneTest.java:561)
> 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)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17578) Test failure: org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527629#comment-17527629
]
Marcus Eriksson commented on CASSANDRA-17578:
-
this one is weird, checking the logs:
{code}
Compacted (ae3993b0-c2b9-11ec-9067-072fd66af76a) 2 sstables to
[/home/cassandra/cassandra/build/test/cassandra/data/RangeTombstoneTest/StandardInteger1-a84cb360c2b911ec
9067072fd66af76a/nb-31-big,] to level=0. 0.113KiB to 0.056KiB...
{code}
after the major compaction
And comparing the size of the resulting sstable in a successful test shows
exactly the same. So it seems the RT doesn't show up when iterating the rows.
> Test failure:
> org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction
> -
>
> Key: CASSANDRA-17578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17578
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1099/testReport/org.apache.cassandra.db/RangeTombstoneTest/testRangeTombstoneCompaction_compression_2/
> {code}
> junit.framework.AssertionFailedError: Expecting open marker, got Row: name=8
> | val=8
> at
> org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction(RangeTombstoneTest.java:561)
> 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)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17578) Test failure: org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction
Marcus Eriksson created CASSANDRA-17578:
---
Summary: Test failure:
org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction
Key: CASSANDRA-17578
URL: https://issues.apache.org/jira/browse/CASSANDRA-17578
Project: Cassandra
Issue Type: Bug
Reporter: Marcus Eriksson
https://ci-cassandra.apache.org/job/Cassandra-trunk/1099/testReport/org.apache.cassandra.db/RangeTombstoneTest/testRangeTombstoneCompaction_compression_2/
{code}
junit.framework.AssertionFailedError: Expecting open marker, got Row: name=8 |
val=8
at
org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction(RangeTombstoneTest.java:561)
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)
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17139) readWriteDuringBootstrapTest - org.apache.cassandra.distributed.test.ring.BootstrapTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17139: Fix Version/s: 3.0.x > readWriteDuringBootstrapTest - > org.apache.cassandra.distributed.test.ring.BootstrapTest > --- > > Key: CASSANDRA-17139 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17139 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 4.0.x > > > The test was seen failing in both > [CircleCI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1188/workflows/06afaf5b-6951-4b3d-8fbf-6ef2aef04e52/jobs/7025] > and > [Jenkins|https://jenkins-cm4.apache.org/job/Cassandra-4.0/267/testReport/junit/org.apache.cassandra.distributed.test.ring/BootstrapTest/readWriteDuringBootstrapTest/] > lately. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17537) nodetool compact should support using a key string to find the range to avoid operators having to manually do this
[ https://issues.apache.org/jira/browse/CASSANDRA-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17537: Status: Review In Progress (was: Patch Available) > nodetool compact should support using a key string to find the range to avoid > operators having to manually do this > -- > > Key: CASSANDRA-17537 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17537 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > Its common that a single key needs to be compact, and operators need to do > the following > 1) go from key -> token > 2) generate range > 3) call nodetool compact with this range > We can simply this workflow by adding this to compact > nodetool compact ks.tbl -k “key1" -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17537) nodetool compact should support using a key string to find the range to avoid operators having to manually do this
[ https://issues.apache.org/jira/browse/CASSANDRA-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17537: Status: Ready to Commit (was: Review In Progress) > nodetool compact should support using a key string to find the range to avoid > operators having to manually do this > -- > > Key: CASSANDRA-17537 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17537 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > Its common that a single key needs to be compact, and operators need to do > the following > 1) go from key -> token > 2) generate range > 3) call nodetool compact with this range > We can simply this workflow by adding this to compact > nodetool compact ks.tbl -k “key1" -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17537) nodetool compact should support using a key string to find the range to avoid operators having to manually do this
[ https://issues.apache.org/jira/browse/CASSANDRA-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525442#comment-17525442 ] Marcus Eriksson commented on CASSANDRA-17537: - +1 > nodetool compact should support using a key string to find the range to avoid > operators having to manually do this > -- > > Key: CASSANDRA-17537 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17537 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > Its common that a single key needs to be compact, and operators need to do > the following > 1) go from key -> token > 2) generate range > 3) call nodetool compact with this range > We can simply this workflow by adding this to compact > nodetool compact ks.tbl -k “key1" -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17537) nodetool compact should support using a key string to find the range to avoid operators having to manually do this
[ https://issues.apache.org/jira/browse/CASSANDRA-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17537: Reviewers: Marcus Eriksson added a few comments on the PR > nodetool compact should support using a key string to find the range to avoid > operators having to manually do this > -- > > Key: CASSANDRA-17537 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17537 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Its common that a single key needs to be compact, and operators need to do > the following > 1) go from key -> token > 2) generate range > 3) call nodetool compact with this range > We can simply this workflow by adding this to compact > nodetool compact ks.tbl -k “key1" -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17561: Fix Version/s: 4.x > Diagnostic snapshot service should only snapshot mismatching ranges on > preview repair mismatch > -- > > Key: CASSANDRA-17561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > We currently snapshot all sstables in a table when a preview repair mismatch > occurs, we should only snapshot the sstables containing the mismatching ranges -- 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-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17561: Test and Documentation Plan: new test, cci run Status: Patch Available (was: Open) https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2Fsnapshot_mismatching_ranges=all https://github.com/apache/cassandra/pull/1577 > Diagnostic snapshot service should only snapshot mismatching ranges on > preview repair mismatch > -- > > Key: CASSANDRA-17561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > We currently snapshot all sstables in a table when a preview repair mismatch > occurs, we should only snapshot the sstables containing the mismatching ranges -- 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-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17561: Change Category: Quality Assurance Complexity: Low Hanging Fruit Reviewers: Sam Tunnicliffe Status: Open (was: Triage Needed) > Diagnostic snapshot service should only snapshot mismatching ranges on > preview repair mismatch > -- > > Key: CASSANDRA-17561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > We currently snapshot all sstables in a table when a preview repair mismatch > occurs, we should only snapshot the sstables containing the mismatching ranges -- 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-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
Marcus Eriksson created CASSANDRA-17561: --- Summary: Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch Key: CASSANDRA-17561 URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 Project: Cassandra Issue Type: Improvement Components: Consistency/Repair Reporter: Marcus Eriksson Assignee: Marcus Eriksson We currently snapshot all sstables in a table when a preview repair mismatch occurs, we should only snapshot the sstables containing the mismatching ranges -- 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-17379) Fail starting when the same parameter exists more than once with different values in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524185#comment-17524185
]
Marcus Eriksson commented on CASSANDRA-17379:
-
PR updated with the above
> Fail starting when the same parameter exists more than once with different
> values in cassandra.yaml
>
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
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-17379) Fail starting when the same parameter exists more than once with different values in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524133#comment-17524133
]
Marcus Eriksson commented on CASSANDRA-17379:
-
I'm +1 disallowing new + old config params even if the value is the same
> Fail starting when the same parameter exists more than once with different
> values in cassandra.yaml
>
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
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-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524130#comment-17524130
]
Marcus Eriksson commented on CASSANDRA-16310:
-
rebased and a small update (use DataStorageSpec for the min partition size
config param) now that CASSANDRA-14752 has been merged:
https://github.com/krummas/cassandra/commits/marcuse/16310
https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F16310
[~dcapwell] could you have a final look before I commit this?
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
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-17535) Remove cassandra-stress server functionality
[ https://issues.apache.org/jira/browse/CASSANDRA-17535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17535: Fix Version/s: 4.1 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/537321e9c7d2696cddc35e808a48846cb67ba52a Resolution: Fixed Status: Resolved (was: Ready to Commit) and committed, thanks! > Remove cassandra-stress server functionality > > > Key: CASSANDRA-17535 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17535 > Project: Cassandra > Issue Type: Task > Components: Test/benchmark >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.1 > > > The cassandra-stress server functionality is documented (CASSANDRA-15749) > insecure and we should drop it as it is most likely never used by anyone. -- 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-17379) Fail starting when the same parameter exists more than once with different values in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17379:
Test and Documentation Plan: new unit test, cci run
Status: Patch Available (was: Open)
Patch adds two new properties:
* {{cassandra.allow_duplicate_config_keys}}: allows having duplicate keys at
all (ones with the same name, or new / old names. Defaults to {{true}} for now
(I'd prefer setting this to false as well though)
* {{cassandra.allow_conflicting_config_values}}: allows having new/old
parameters with different values. Defaults to {{false}}.
https://github.com/apache/cassandra/pull/1557
https://app.circleci.com/pipelines/github/krummas/cassandra/791/workflows/b383569a-a78a-4f4b-886a-42e64904db54
> Fail starting when the same parameter exists more than once with different
> values in cassandra.yaml
>
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
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-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518873#comment-17518873
]
Marcus Eriksson commented on CASSANDRA-16310:
-
[~smiklosovic] sorry, missed the message, we're blocked on CASSANDRA-14752 -
once that is committed I'll get this merged
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
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-17535) Remove cassandra-stress server functionality
[ https://issues.apache.org/jira/browse/CASSANDRA-17535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518812#comment-17518812 ] Marcus Eriksson commented on CASSANDRA-17535: - thanks for the review, I already removed the -sendto from cassandra_stress.adoc in the PR > Remove cassandra-stress server functionality > > > Key: CASSANDRA-17535 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17535 > Project: Cassandra > Issue Type: Task > Components: Test/benchmark >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > The cassandra-stress server functionality is documented (CASSANDRA-15749) > insecure and we should drop it as it is most likely never used by anyone. -- 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-17535) Remove cassandra-stress server functionality
[ https://issues.apache.org/jira/browse/CASSANDRA-17535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17535: Test and Documentation Plan: cci run Status: Patch Available (was: Open) tests: https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2Fremove_stressd=all PR: https://github.com/apache/cassandra/pull/1554 > Remove cassandra-stress server functionality > > > Key: CASSANDRA-17535 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17535 > Project: Cassandra > Issue Type: Task > Components: Test/benchmark >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > The cassandra-stress server functionality is documented (CASSANDRA-15749) > insecure and we should drop it as it is most likely never used by anyone. -- 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-17535) Remove cassandra-stress server functionality
[ https://issues.apache.org/jira/browse/CASSANDRA-17535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17535: Change Category: Operability Complexity: Low Hanging Fruit Fix Version/s: 4.x Status: Open (was: Triage Needed) > Remove cassandra-stress server functionality > > > Key: CASSANDRA-17535 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17535 > Project: Cassandra > Issue Type: Task > Components: Test/benchmark >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > The cassandra-stress server functionality is documented (CASSANDRA-15749) > insecure and we should drop it as it is most likely never used by anyone. -- 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-17535) Remove cassandra-stress server functionality
Marcus Eriksson created CASSANDRA-17535: --- Summary: Remove cassandra-stress server functionality Key: CASSANDRA-17535 URL: https://issues.apache.org/jira/browse/CASSANDRA-17535 Project: Cassandra Issue Type: Task Components: Test/benchmark Reporter: Marcus Eriksson Assignee: Marcus Eriksson The cassandra-stress server functionality is documented (CASSANDRA-15749) insecure and we should drop it as it is most likely never used by anyone. -- 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
]
Marcus Eriksson updated CASSANDRA-17424:
Status: Ready to Commit (was: Review In Progress)
+1
> 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.x
>
> Time Spent: 1h
> 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
[jira] [Commented] (CASSANDRA-5901) Bootstrap should also make the data consistent on the new node
[ https://issues.apache.org/jira/browse/CASSANDRA-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511639#comment-17511639 ] Marcus Eriksson commented on CASSANDRA-5901: [~blerer] I'll post a new patch at some point, unmarking as patch available, thanks for the ping > Bootstrap should also make the data consistent on the new node > -- > > Key: CASSANDRA-5901 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5901 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Streaming and Messaging >Reporter: Sankalp Kohli >Assignee: Marcus Eriksson >Priority: Low > Fix For: 4.x > > > Currently when we are bootstrapping a new node, it might bootstrap from a > node which does not have most upto date data. Because of this, we need to run > a repair after that. > Most people will always run the repair so it would help if we can provide a > parameter to bootstrap to run the repair once the bootstrap has finished. > It can also stop the node from responding to reads till repair has finished. > This could be another param as well. -- 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-5901) Bootstrap should also make the data consistent on the new node
[ https://issues.apache.org/jira/browse/CASSANDRA-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-5901: --- Status: Open (was: Patch Available) > Bootstrap should also make the data consistent on the new node > -- > > Key: CASSANDRA-5901 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5901 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Streaming and Messaging >Reporter: Sankalp Kohli >Assignee: Marcus Eriksson >Priority: Low > Fix For: 4.x > > > Currently when we are bootstrapping a new node, it might bootstrap from a > node which does not have most upto date data. Because of this, we need to run > a repair after that. > Most people will always run the repair so it would help if we can provide a > parameter to bootstrap to run the repair once the bootstrap has finished. > It can also stop the node from responding to reads till repair has finished. > This could be another param as well. -- 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
]
Marcus Eriksson updated CASSANDRA-17424:
Attachment: (was:
bugreport-blackjack-QODS30.163-7-27-2022-03-13-13-48-43.png)
> 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.x
>
> Time Spent: 1h
> 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
[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
]
Marcus Eriksson updated CASSANDRA-17424:
Reviewers: Jon Meredith, Jon Meredith, Marcus Eriksson (was: Jon Meredith,
Jon Meredith)
> 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.x
>
> Attachments:
> bugreport-blackjack-QODS30.163-7-27-2022-03-13-13-48-43.png
>
> Time Spent: 1h
> 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
[jira] [Updated] (CASSANDRA-13460) Diag. Events: Add local persistency
[
https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-13460:
Reviewers: Marcus Eriksson, Michael Semb Wever (was: Michael Semb Wever)
> Diag. Events: Add local persistency
> ---
>
> Key: CASSANDRA-13460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13460
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 0001-Add-persistency-for-events-to-system-keyspace.patch
>
>
> Some generated events will be rather less frequent but very useful for
> retroactive troubleshooting. E.g. all events related to bootstraping and
> gossip would probably be worth saving, as they might provide valuable
> insights and will consume very little resources in low quantities. Imaging if
> we could e.g. in case of CASSANDRA-13348 just ask the user to -run a tool
> like {{./bin/diagdump BootstrapEvent}} on each host, to get us a detailed log
> of all relevant events- provide a dump of all events as described in the
> [documentation|https://github.com/spodkowinski/cassandra/blob/WIP-13460/doc/source/operating/diag_events.rst].
>
> This could be done by saving events white-listed in cassandra.yaml to a local
> table. Maybe using a TTL.
--
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-13460) Diag. Events: Add local persistency
[
https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17506149#comment-17506149
]
Marcus Eriksson commented on CASSANDRA-13460:
-
I could, but I don't know when - its a fairly large patch.
Assigning myself as a reviewer, but no clue when I'll be able to get to this
> Diag. Events: Add local persistency
> ---
>
> Key: CASSANDRA-13460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13460
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 0001-Add-persistency-for-events-to-system-keyspace.patch
>
>
> Some generated events will be rather less frequent but very useful for
> retroactive troubleshooting. E.g. all events related to bootstraping and
> gossip would probably be worth saving, as they might provide valuable
> insights and will consume very little resources in low quantities. Imaging if
> we could e.g. in case of CASSANDRA-13348 just ask the user to -run a tool
> like {{./bin/diagdump BootstrapEvent}} on each host, to get us a detailed log
> of all relevant events- provide a dump of all events as described in the
> [documentation|https://github.com/spodkowinski/cassandra/blob/WIP-13460/doc/source/operating/diag_events.rst].
>
> This could be done by saving events white-listed in cassandra.yaml to a local
> table. Maybe using a TTL.
--
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-17316) Remove all usages of junit.framework
[
https://issues.apache.org/jira/browse/CASSANDRA-17316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17504786#comment-17504786
]
Marcus Eriksson commented on CASSANDRA-17316:
-
lgtm, maybe we should also ban it with checkstyle? Something like this;
https://github.com/krummas/cassandra/commit/49c64e37d25d1c3cd16ffaff2431aa9a96ff697b
> Remove all usages of junit.framework
>
>
> Key: CASSANDRA-17316
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17316
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Let's remove all the vestiges of the legacy {{junit}} library in one piece of
> work instead of slowly over the lifetime of the project :)
--
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-17316) Remove all usages of junit.framework
[
https://issues.apache.org/jira/browse/CASSANDRA-17316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17316:
Reviewers: Marcus Eriksson
Status: Review In Progress (was: Patch Available)
> Remove all usages of junit.framework
>
>
> Key: CASSANDRA-17316
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17316
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Let's remove all the vestiges of the legacy {{junit}} library in one piece of
> work instead of slowly over the lifetime of the project :)
--
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-17414) Block usage of Instant.now()
[ https://issues.apache.org/jira/browse/CASSANDRA-17414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17414: Fix Version/s: 4.1 (was: 4.x) Since Version: 4.x Source Control Link: https://github.com/apache/cassandra/commit/60675cc2759db0c5629604279e70c51e10dfefd6 Resolution: Fixed Status: Resolved (was: Ready to Commit) committed, thanks! One failure in the test run above, handled in CASSANDRA-17139 > Block usage of Instant.now() > > > Key: CASSANDRA-17414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17414 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.1 > > > After CEP-10 we should avoid using Instant.now() -- 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-17414) Block usage of Instant.now()
[ https://issues.apache.org/jira/browse/CASSANDRA-17414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17414: Status: Ready to Commit (was: Review In Progress) > Block usage of Instant.now() > > > Key: CASSANDRA-17414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17414 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > After CEP-10 we should avoid using Instant.now() -- 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-17414) Block usage of Instant.now()
[ https://issues.apache.org/jira/browse/CASSANDRA-17414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17414: Reviewers: Benedict Elliott Smith (was: Benedict Elliott Smith, Marcus Eriksson) > Block usage of Instant.now() > > > Key: CASSANDRA-17414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17414 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > After CEP-10 we should avoid using Instant.now() -- 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-17414) Block usage of Instant.now()
[ https://issues.apache.org/jira/browse/CASSANDRA-17414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17414: Reviewers: Benedict Elliott Smith, Marcus Eriksson (was: Benedict Elliott Smith) Status: Review In Progress (was: Patch Available) > Block usage of Instant.now() > > > Key: CASSANDRA-17414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17414 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > After CEP-10 we should avoid using Instant.now() -- 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-17414) Block usage of Instant.now()
[ https://issues.apache.org/jira/browse/CASSANDRA-17414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500571#comment-17500571 ] Marcus Eriksson edited comment on CASSANDRA-17414 at 3/9/22, 9:59 AM: -- [https://github.com/apache/cassandra/pull/1477] [https://app.circleci.com/pipelines/github/krummas/cassandra/785/workflows/04492fa1-5579-47d1-abcf-dbf72e09828e] was (Author: krummas): https://github.com/apache/cassandra/pull/1477 https://app.circleci.com/pipelines/github/krummas/cassandra/784/workflows/e0879aae-d97a-4eaf-ac32-e205133a6f7c > Block usage of Instant.now() > > > Key: CASSANDRA-17414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17414 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > After CEP-10 we should avoid using Instant.now() -- 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-17416) Test Failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testCDCIndexFileWriteOnSync
Marcus Eriksson created CASSANDRA-17416: --- Summary: 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 [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-17414) Block usage of Instant.now()
[ https://issues.apache.org/jira/browse/CASSANDRA-17414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17414: Test and Documentation Plan: cci run Status: Patch Available (was: Open) https://github.com/apache/cassandra/pull/1477 https://app.circleci.com/pipelines/github/krummas/cassandra/784/workflows/e0879aae-d97a-4eaf-ac32-e205133a6f7c > Block usage of Instant.now() > > > Key: CASSANDRA-17414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17414 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > After CEP-10 we should avoid using Instant.now() -- 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-17414) Block usage of Instant.now()
[ https://issues.apache.org/jira/browse/CASSANDRA-17414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17414: Reviewers: Benedict Elliott Smith > Block usage of Instant.now() > > > Key: CASSANDRA-17414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17414 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > After CEP-10 we should avoid using Instant.now() -- 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-17414) Block usage of Instant.now()
[ https://issues.apache.org/jira/browse/CASSANDRA-17414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17414: Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear Impact(13164) Complexity: Low Hanging Fruit Component/s: Build Discovered By: Code Inspection Fix Version/s: 4.x Severity: Low Status: Open (was: Triage Needed) > Block usage of Instant.now() > > > Key: CASSANDRA-17414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17414 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > After CEP-10 we should avoid using Instant.now() -- 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-17414) Block usage of Instant.now()
Marcus Eriksson created CASSANDRA-17414: --- Summary: Block usage of Instant.now() Key: CASSANDRA-17414 URL: https://issues.apache.org/jira/browse/CASSANDRA-17414 Project: Cassandra Issue Type: Bug Reporter: Marcus Eriksson Assignee: Marcus Eriksson After CEP-10 we should avoid using Instant.now() -- 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-17321) Investigate large number of test timeouts on specific build runs
[ https://issues.apache.org/jira/browse/CASSANDRA-17321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500569#comment-17500569 ] Marcus Eriksson commented on CASSANDRA-17321: - https://ci-cassandra.apache.org/job/Cassandra-4.0/346/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/testExpireInbound_compression/ > Investigate large number of test timeouts on specific build runs > > > Key: CASSANDRA-17321 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17321 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Josh McKenzie >Priority: Normal > > We have a selection of new test failures on CI run 323 on 4.0 and 923 on > trunk that appear to have a variety of teardown errors or timeouts. We should > look into if there's any kind of theme, commonality, etc that we can make > changes w/respect to to prevent this kind of "dud job" from occurring in the > future. > 323 4.0: https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/ > 923 trunk: https://ci-cassandra.apache.org/job/Cassandra-trunk/923/ > Failures on 4.0: > https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/dtest-novnode.materialized_views_test/TestMaterializedViewsConsistency/test_multi_partition_consistent_reads_after_write/ > https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/dtest-novnode.transient_replication_test/TestTransientReplication/test_cheap_quorums/ > https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/dtest-novnode.client_request_metrics_test/TestClientRequestMetrics/test_client_request_metrics/ > https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/dtest-novnode.repair_tests.repair_test/TestRepair/test_multiple_ranges_repair/ > https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/testExpireSome/ > Notably, trunk build 923 appears to have the same pattern of a slew of > untraced timeouts on tests: > https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/org.apache.cassandra.distributed.upgrade/CompactStorageUpgradeTest/compactStorageHiddenColumnTest/ > https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/org.apache.cassandra.transport/CQLConnectionTest/handleCorruptionOfLargeMessageFrame_compression_2/ > https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/org.apache.cassandra.distributed.test/NetstatsRepairStreamingTest/testWithCompressionEnabled/ > https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/org.apache.cassandra.distributed.test/NetstatsBootstrapWithEntireSSTablesCompressionStreamingTest/testWithStreamingEntireSSTablesWithoutCompressionWithoutThrottling_4/ > https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/testExpireSome_compression/ > https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/dtest-novnode.transient_replication_test/TestTransientReplication/test_transient_write/ > https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/dtest-novnode.read_repair_test/TestSpeculativeReadRepair/test_quorum_requirement_on_speculated_read/ -- 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-16349) SSTableLoader reports error when SSTable(s) do not have data for some nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499050#comment-17499050
]
Marcus Eriksson commented on CASSANDRA-16349:
-
+1
> SSTableLoader reports error when SSTable(s) do not have data for some nodes
> ---
>
> Key: CASSANDRA-16349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16349
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
> Fix For: 4.1, 4.0.4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Running SSTableLoader in verbose mode will show error(s) if there are node(s)
> that do not own any data from the SSTable(s). This can happen in at least 2
> cases:
> # SSTableLoader is used to stream backups while keeping the same token ranges
> # SSTable(s) are created with CQLSSTableWriter to match token ranges (this
> can bring better performance by using ZeroCopy streaming)
> Partial output of the SSTableLoader:
> {quote}ERROR 02:47:47,842 [Stream #fa8e73b0-3da5-11eb-9c47-c5d27ae8fe47]
> Remote peer /127.0.0.4:7000 failed stream session.
> ERROR 02:47:47,842 [Stream #fa8e73b0-3da5-11eb-9c47-c5d27ae8fe47] Remote peer
> /127.0.0.3:7000 failed stream session.
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.611KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.611KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.515KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.427KiB/s)
> {quote}
>
> Stack trace:
> {quote}java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:552)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:533)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:99)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:88)
> at
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1056)
> at
> com.google.common.util.concurrent.DirectExecutor.execute(DirectExecutor.java:30)
> at
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:1138)
> at
> com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:958)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:748)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:220)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:196)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:505)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:819)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:595)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {quote}
> To reproduce create a cluster with ccm with more nodes than the RF, put some
> data into it copy a SSTable and stream it.
>
> The error originates on the nodes, the following stack trace is shown in the
> logs:
> {quote}java.lang.IllegalStateException: Stream hasn't been read yet
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:507)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.getSize(CassandraIncomingFile.java:96)
> at
> org.apache.cassandra.streaming.StreamSession.receive(StreamSession.java:789)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:587)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189)
> at
>
[jira] [Commented] (CASSANDRA-17280) Deprecate JavaScript UDF
[ https://issues.apache.org/jira/browse/CASSANDRA-17280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17497352#comment-17497352 ] Marcus Eriksson commented on CASSANDRA-17280: - +1 > Deprecate JavaScript UDF > > > Key: CASSANDRA-17280 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17280 > Project: Cassandra > Issue Type: Task > Components: Feature/UDF >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x > > > There was a [consensus > |https://lists.apache.org/thread/mnxh94lg9v94bfntq88051z3ww16q2fk] that JS > UDF can be deprecated and removed with the next major release. > As part of this ticket we can add: > * Warning to the users when they use them In 4.0.2 > * Docs update > * Twitter update > * Announcement to the user mailing list -- 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-17388) DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
[
https://issues.apache.org/jira/browse/CASSANDRA-17388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17388:
Status: Ready to Commit (was: Review In Progress)
> DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
> ---
>
> Key: CASSANDRA-17388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17388
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/NEWS.txt
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Document changes made by CASSANDRA-17352 in {{NEWS.txt}} and {{CHANGES.txt}}.
--
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-17388) DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
[
https://issues.apache.org/jira/browse/CASSANDRA-17388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17494409#comment-17494409
]
Marcus Eriksson commented on CASSANDRA-17388:
-
+1
> DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
> ---
>
> Key: CASSANDRA-17388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17388
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/NEWS.txt
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Document changes made by CASSANDRA-17352 in {{NEWS.txt}} and {{CHANGES.txt}}.
--
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-17388) DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
[
https://issues.apache.org/jira/browse/CASSANDRA-17388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17388:
Reviewers: Marcus Eriksson
Status: Review In Progress (was: Patch Available)
> DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
> ---
>
> Key: CASSANDRA-17388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17388
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/NEWS.txt
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Document changes made by CASSANDRA-17352 in {{NEWS.txt}} and {{CHANGES.txt}}.
--
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-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493908#comment-17493908
]
Marcus Eriksson commented on CASSANDRA-17352:
-
yes,
https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/config/Config.java#L329-L340
- there are most likely other issues when running with
{{enable_user_defined_functions_threads: false}}
> CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
> -
>
> Key: CASSANDRA-17352
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17352
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
>
> When running Apache Cassandra with the following configuration:
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> enable_user_defined_functions_threads: false
> it is possible for an attacker to execute arbitrary code on the host. The
> attacker would need to have enough permissions to create user defined
> functions in the cluster to be able to exploit this. Note that this
> configuration is documented as unsafe, and will continue to be considered
> unsafe after this CVE.
> This issue is being tracked as CASSANDRA-17352
> Mitigation:
> Set `enable_user_defined_functions_threads: true` (this is default)
> or
> 3.0 users should upgrade to 3.0.26
> 3.11 users should upgrade to 3.11.12
> 4.0 users should upgrade to 4.0.2
> Credit:
> This issue was discovered by Omer Kaspi of the JFrog Security vulnerability
> research team.
--
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-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493892#comment-17493892 ] Marcus Eriksson edited comment on CASSANDRA-17352 at 2/17/22, 11:59 AM: not sure I understand the question - is there a problem with the patch? was (Author: krummas): not sure I understand the question - do you have a problem with the patch? > CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs > - > > Key: CASSANDRA-17352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17352 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDF >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.26, 3.11.12, 4.0.2 > > > When running Apache Cassandra with the following configuration: > enable_user_defined_functions: true > enable_scripted_user_defined_functions: true > enable_user_defined_functions_threads: false > it is possible for an attacker to execute arbitrary code on the host. The > attacker would need to have enough permissions to create user defined > functions in the cluster to be able to exploit this. Note that this > configuration is documented as unsafe, and will continue to be considered > unsafe after this CVE. > This issue is being tracked as CASSANDRA-17352 > Mitigation: > Set `enable_user_defined_functions_threads: true` (this is default) > or > 3.0 users should upgrade to 3.0.26 > 3.11 users should upgrade to 3.11.12 > 4.0 users should upgrade to 4.0.2 > Credit: > This issue was discovered by Omer Kaspi of the JFrog Security vulnerability > research team. -- 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-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493892#comment-17493892 ] Marcus Eriksson commented on CASSANDRA-17352: - not sure I understand the question - do you have a problem with the patch? > CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs > - > > Key: CASSANDRA-17352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17352 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDF >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.26, 3.11.12, 4.0.2 > > > When running Apache Cassandra with the following configuration: > enable_user_defined_functions: true > enable_scripted_user_defined_functions: true > enable_user_defined_functions_threads: false > it is possible for an attacker to execute arbitrary code on the host. The > attacker would need to have enough permissions to create user defined > functions in the cluster to be able to exploit this. Note that this > configuration is documented as unsafe, and will continue to be considered > unsafe after this CVE. > This issue is being tracked as CASSANDRA-17352 > Mitigation: > Set `enable_user_defined_functions_threads: true` (this is default) > or > 3.0 users should upgrade to 3.0.26 > 3.11 users should upgrade to 3.11.12 > 4.0 users should upgrade to 4.0.2 > Credit: > This issue was discovered by Omer Kaspi of the JFrog Security vulnerability > research team. -- 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-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493841#comment-17493841 ] Marcus Eriksson commented on CASSANDRA-17352: - nice catch - I flipped the booleans in the comment above (and edited comment to be correct) > CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs > - > > Key: CASSANDRA-17352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17352 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDF >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.26, 3.11.12, 4.0.2 > > > When running Apache Cassandra with the following configuration: > enable_user_defined_functions: true > enable_scripted_user_defined_functions: true > enable_user_defined_functions_threads: false > it is possible for an attacker to execute arbitrary code on the host. The > attacker would need to have enough permissions to create user defined > functions in the cluster to be able to exploit this. Note that this > configuration is documented as unsafe, and will continue to be considered > unsafe after this CVE. > This issue is being tracked as CASSANDRA-17352 > Mitigation: > Set `enable_user_defined_functions_threads: true` (this is default) > or > 3.0 users should upgrade to 3.0.26 > 3.11 users should upgrade to 3.11.12 > 4.0 users should upgrade to 4.0.2 > Credit: > This issue was discovered by Omer Kaspi of the JFrog Security vulnerability > research team. -- 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-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490815#comment-17490815
]
Marcus Eriksson edited comment on CASSANDRA-17352 at 2/17/22, 10:21 AM:
It is possible for an attacker to create a scripted UDF which executes
arbitrary code on the server.
Attacker needs to have enough permissions to create user defined functions on
the server, and {{enable_user_defined_functions_threads}} must have been
changed from {{true}} to {{false}} by the operator
https://github.com/apache/cassandra/commit/5c9ba06dd31157cd224af2cec75521fefe2c9883
to continue running with {{enable_user_defined_functions_threads: false}}
setting {{allow_insecure_udfs: true}} is required
to continue accessing {{System.*}} classes, {{allow_extra_insecure_udfs: true}}
is required
was (Author: krummas):
It is possible for an attacker to create a scripted UDF which executes
arbitrary code on the server.
Attacker needs to have enough permissions to create user defined functions on
the server, and {{enable_user_defined_functions_threads}} must have been
changed from {{false}} to {{true}} by the operator
https://github.com/apache/cassandra/commit/5c9ba06dd31157cd224af2cec75521fefe2c9883
to continue running with {{enable_user_defined_functions_threads: false}}
setting {{allow_insecure_udfs: true}} is required
to continue accessing {{System.*}} classes, {{allow_extra_insecure_udfs: true}}
is required
> CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
> -
>
> Key: CASSANDRA-17352
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17352
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
>
> When running Apache Cassandra with the following configuration:
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> enable_user_defined_functions_threads: false
> it is possible for an attacker to execute arbitrary code on the host. The
> attacker would need to have enough permissions to create user defined
> functions in the cluster to be able to exploit this. Note that this
> configuration is documented as unsafe, and will continue to be considered
> unsafe after this CVE.
> This issue is being tracked as CASSANDRA-17352
> Mitigation:
> Set `enable_user_defined_functions_threads: true` (this is default)
> or
> 3.0 users should upgrade to 3.0.26
> 3.11 users should upgrade to 3.11.12
> 4.0 users should upgrade to 4.0.2
> Credit:
> This issue was discovered by Omer Kaspi of the JFrog Security vulnerability
> research team.
--
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-17272) LeveledCompactionStrategy disk space check improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17272: Fix Version/s: 3.0.27 3.11.13 4.1 4.0.4 (was: 3.0.x) (was: 4.x) (was: 3.11.x) (was: 4.0.x) Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra/commit/b58a5c86e89e10ad4d39756c5314a756eb18204d Resolution: Fixed Status: Resolved (was: Ready to Commit) and committed, thanks! test results; [3.0|https://app.circleci.com/pipelines/github/krummas/cassandra/782/workflows/9aee2269-1a67-41ff-a088-47ff77eeb82d] [3.11|https://app.circleci.com/pipelines/github/krummas/cassandra/780/workflows/5100c640-aafc-407e-91a3-2e1a9e6d3d3c] [4.0|https://app.circleci.com/pipelines/github/krummas/cassandra/783/workflows/594e1ca2-f346-4c4c-9458-381a32b404e4] [trunk|https://app.circleci.com/pipelines/github/krummas/cassandra/781/workflows/1b908866-deac-47f8-be13-0aedbd36f85b] > LeveledCompactionStrategy disk space check improvements > --- > > Key: CASSANDRA-17272 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17272 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.27, 3.11.13, 4.1, 4.0.4 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We currently allow reducing scope (removing sstables from the compaction) > when starting STCS-in-L0 with LCS if the compaction is too large for the > available disk space. We can do the same for L0 -> L1 compactions - but we > can only remove L0 sstables to avoid causing overlap in L1. > Also, in 3.0, when starting an LCS compaction we try to [get a writeable > location|https://github.com/apache/cassandra/blob/b1a8a56c563b85ab9a34d3bbf9c16278dd441157/src/java/org/apache/cassandra/db/compaction/writers/CompactionAwareWriter.java#L128] > where the full result of the compaction will fit - here we should only get a > directory where the first sstable fits, otherwise the compaction might fail > even though there is enough space in total among the data directories -- 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-17272) LeveledCompactionStrategy disk space check improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17272: Status: Ready to Commit (was: Review In Progress) > LeveledCompactionStrategy disk space check improvements > --- > > Key: CASSANDRA-17272 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17272 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We currently allow reducing scope (removing sstables from the compaction) > when starting STCS-in-L0 with LCS if the compaction is too large for the > available disk space. We can do the same for L0 -> L1 compactions - but we > can only remove L0 sstables to avoid causing overlap in L1. > Also, in 3.0, when starting an LCS compaction we try to [get a writeable > location|https://github.com/apache/cassandra/blob/b1a8a56c563b85ab9a34d3bbf9c16278dd441157/src/java/org/apache/cassandra/db/compaction/writers/CompactionAwareWriter.java#L128] > where the full result of the compaction will fit - here we should only get a > directory where the first sstable fits, otherwise the compaction might fail > even though there is enough space in total among the data directories -- 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
