[jira] [Updated] (CASSANDRA-18151) org.apache.cassandra.distributed.test.SchemaTest timeout
[ https://issues.apache.org/jira/browse/CASSANDRA-18151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18151: Bug Category: Parent values: Correctness(12982) Complexity: Normal Discovered By: Unit Test Fix Version/s: 4.2 Severity: Normal Status: Open (was: Triage Needed) > org.apache.cassandra.distributed.test.SchemaTest timeout > > > Key: CASSANDRA-18151 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18151 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.2 > > > See here for another timeout of this test > https://app.circleci.com/pipelines/github/bereng/cassandra/836/workflows/dd9f0441-df59-40e7-b00b-c0788f0235a6/jobs/7597/tests#failed-test-0 > It is unclear if it's an env issue or related to CASSANDRA-17819 or similar > ones as this test has some history to it. -- 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] [Created] (CASSANDRA-18151) org.apache.cassandra.distributed.test.SchemaTest timeout
Berenguer Blasi created CASSANDRA-18151: --- Summary: org.apache.cassandra.distributed.test.SchemaTest timeout Key: CASSANDRA-18151 URL: https://issues.apache.org/jira/browse/CASSANDRA-18151 Project: Cassandra Issue Type: Bug Components: Test/unit Reporter: Berenguer Blasi See here for another timeout of this test https://app.circleci.com/pipelines/github/bereng/cassandra/836/workflows/dd9f0441-df59-40e7-b00b-c0788f0235a6/jobs/7597/tests#failed-test-0 It is unclear if it's an env issue or related to CASSANDRA-17819 or similar ones as this test has some history to it. -- 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-18118) Do not leak 2015 memtable synthetic Epoch
[
https://issues.apache.org/jira/browse/CASSANDRA-18118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675845#comment-17675845
]
Berenguer Blasi commented on CASSANDRA-18118:
-
Thx for the review!
> Do not leak 2015 memtable synthetic Epoch
> -
>
> Key: CASSANDRA-18118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18118
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> This
> [Epoch|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> can
> [leak|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/Memtable.java#L392]
> affecting all the timestamps logic. It has been observed in a production
> env it can i.e. prevent proper sstable and tombstone cleanup.
> To reproduce create the following table:
> {noformat}
> drop keyspace test;
> create keyspace test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> CREATE TABLE test.test (
> key text PRIMARY KEY,
> id text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '2', 'tombstone_compaction_interval':
> '3000', 'tombstone_threshold': '0.1', 'unchecked_tombstone_compaction':
> 'true'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 10
> AND gc_grace_seconds = 10
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> CREATE INDEX id_idx ON test.test (id);
> {noformat}
> And stress load it with:
> {noformat}
> insert into test.test (key,id) values('$RANDOM_UUID $RANDOM_UUID',
> 'eaca36a1-45f1-469c-a3f6-3ba54220363f') USING TTL 10
> {noformat}
> Notice how all inserts have a 10s TTL, the default 10s TTL and gc_grace is
> also at 10s. This is to speed up the repro:
> - Run the load for a couple minutes and track sstables disk usage. You will
> see it does only increase, nothing gets cleaned up and it doesn't stop
> growing (notice all this is well past the 10s gc_grace and TTL)
> - Running a flush and a compaction while under load against the keyspace,
> table or index doesn't solve the issue.
> - Stopping the load and running a compaction doesn't solve the issue.
> Flushing does though.
> - On the original observation where TTL was around 600s and gc_grace around
> 1800s we could get GBs of sstables that weren't cleaned up or compacted away
> after hours of work.
> - Reproduction can also happen on plain sstables by repeatedly
> inserting/deleting/overwriting the same values over and over again without 2i
> indices or TTL being involved.
> The problem seems to be
> [EncodingStats|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> using a synthetic Epoch in 2015 which plays nice with Vint serialization.
> Unfortunately {{Memtable}} is using that to keep track of the
> {{minTimestamp}} which can leak the 2015 Epoch. This confuses any logic
> consuming that timestamp. In this particular case purge and fully expired
> sstables weren't properly detected.
--
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-18118) Do not leak 2015 memtable synthetic Epoch
[
https://issues.apache.org/jira/browse/CASSANDRA-18118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18118:
Fix Version/s: 3.11.15
4.0.8
4.1.1
4.2
(was: 3.11.x)
(was: 4.0.x)
Since Version: 3.11.11
Source Control Link:
https://github.com/apache/cassandra/commit/b8a87abba47441d97b3c85a0473d02919e1c071b
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Do not leak 2015 memtable synthetic Epoch
> -
>
> Key: CASSANDRA-18118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18118
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> This
> [Epoch|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> can
> [leak|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/Memtable.java#L392]
> affecting all the timestamps logic. It has been observed in a production
> env it can i.e. prevent proper sstable and tombstone cleanup.
> To reproduce create the following table:
> {noformat}
> drop keyspace test;
> create keyspace test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> CREATE TABLE test.test (
> key text PRIMARY KEY,
> id text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '2', 'tombstone_compaction_interval':
> '3000', 'tombstone_threshold': '0.1', 'unchecked_tombstone_compaction':
> 'true'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 10
> AND gc_grace_seconds = 10
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> CREATE INDEX id_idx ON test.test (id);
> {noformat}
> And stress load it with:
> {noformat}
> insert into test.test (key,id) values('$RANDOM_UUID $RANDOM_UUID',
> 'eaca36a1-45f1-469c-a3f6-3ba54220363f') USING TTL 10
> {noformat}
> Notice how all inserts have a 10s TTL, the default 10s TTL and gc_grace is
> also at 10s. This is to speed up the repro:
> - Run the load for a couple minutes and track sstables disk usage. You will
> see it does only increase, nothing gets cleaned up and it doesn't stop
> growing (notice all this is well past the 10s gc_grace and TTL)
> - Running a flush and a compaction while under load against the keyspace,
> table or index doesn't solve the issue.
> - Stopping the load and running a compaction doesn't solve the issue.
> Flushing does though.
> - On the original observation where TTL was around 600s and gc_grace around
> 1800s we could get GBs of sstables that weren't cleaned up or compacted away
> after hours of work.
> - Reproduction can also happen on plain sstables by repeatedly
> inserting/deleting/overwriting the same values over and over again without 2i
> indices or TTL being involved.
> The problem seems to be
> [EncodingStats|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> using a synthetic Epoch in 2015 which plays nice with Vint serialization.
> Unfortunately {{Memtable}} is using that to keep track of the
> {{minTimestamp}} which can leak the 2015 Epoch. This confuses any logic
> consuming that timestamp. In this particular case purge and fully expired
> sstables weren't properly detected.
--
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
[cassandra] branch cassandra-4.1 updated (a0c6191238 -> 438346aaa6)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from a0c6191238 Merge branch 'cassandra-4.0' into cassandra-4.1 new b8a87abba4 Do not leak 2015 synthetic memtable Epoch new a83de9bcd2 Merge branch 'cassandra-3.11' into cassandra-4.0 new 438346aaa6 Merge branch 'cassandra-4.0' into cassandra-4.1 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../cassandra/db/SinglePartitionReadCommand.java | 3 +- .../db/compaction/CompactionController.java| 14 +- .../cassandra/db/memtable/AbstractMemtable.java| 19 ++- .../org/apache/cassandra/db/memtable/Memtable.java | 2 + .../db/memtable/ShardedSkipListMemtable.java | 9 +- .../apache/cassandra/db/ColumnFamilyStoreTest.java | 152 + 6 files changed, 192 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 995c3abc420a6e44a6725616125445a0b024da12
Merge: 1b2e49e97c 438346aaa6
Author: Bereng
AuthorDate: Thu Jan 12 08:21:36 2023 +0100
Merge branch 'cassandra-4.1' into trunk
.../cassandra/db/SinglePartitionReadCommand.java | 3 +-
.../db/compaction/CompactionController.java| 14 +-
.../cassandra/db/memtable/AbstractMemtable.java| 12 +-
.../org/apache/cassandra/db/memtable/Memtable.java | 2 +
.../db/memtable/ShardedSkipListMemtable.java | 9 +-
.../apache/cassandra/db/memtable/TrieMemtable.java | 9 +-
.../apache/cassandra/db/ColumnFamilyStoreTest.java | 151 +
7 files changed, 192 insertions(+), 8 deletions(-)
diff --cc src/java/org/apache/cassandra/db/memtable/AbstractMemtable.java
index 38249a20d6,ca6dbf6577..8e50456d6b
--- a/src/java/org/apache/cassandra/db/memtable/AbstractMemtable.java
+++ b/src/java/org/apache/cassandra/db/memtable/AbstractMemtable.java
@@@ -66,9 -74,16 +76,9 @@@ public abstract class AbstractMemtable
return currentOperations.get();
}
-/**
- * Returns the minTS if one available, otherwise NO_MIN_TIMESTAMP.
- *
- * EncodingStats uses a synthetic epoch TS at 2015. We don't want to leak
that (CASSANDRA-18118) so we return NO_MIN_TIMESTAMP instead.
- *
- * @return The minTS or NO_MIN_TIMESTAMP if none available
- */
public long getMinTimestamp()
{
- return minTimestamp.get();
+ return minTimestamp.get() != EncodingStats.NO_STATS.minTimestamp ?
minTimestamp.get() : NO_MIN_TIMESTAMP;
}
public int getMinLocalDeletionTime()
diff --cc src/java/org/apache/cassandra/db/memtable/TrieMemtable.java
index ae3d2e8ec3,00..ff8d765706
mode 100644,00..100644
--- a/src/java/org/apache/cassandra/db/memtable/TrieMemtable.java
+++ b/src/java/org/apache/cassandra/db/memtable/TrieMemtable.java
@@@ -1,722 -1,0 +1,729 @@@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.db.memtable;
+
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Map;
+import java.util.NavigableSet;
+import java.util.Objects;
+import java.util.concurrent.atomic.AtomicBoolean;
+import java.util.concurrent.atomic.AtomicReference;
+import java.util.concurrent.locks.ReentrantLock;
+
+import com.google.common.annotations.VisibleForTesting;
+import com.google.common.collect.Iterators;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import org.apache.cassandra.config.DatabaseDescriptor;
+import org.apache.cassandra.db.BufferDecoratedKey;
+import org.apache.cassandra.db.Clustering;
+import org.apache.cassandra.db.ColumnFamilyStore;
+import org.apache.cassandra.db.DataRange;
+import org.apache.cassandra.db.DecoratedKey;
+import org.apache.cassandra.db.DeletionInfo;
+import org.apache.cassandra.db.PartitionPosition;
+import org.apache.cassandra.db.RegularAndStaticColumns;
+import org.apache.cassandra.db.Slices;
+import org.apache.cassandra.db.commitlog.CommitLogPosition;
+import org.apache.cassandra.db.filter.ClusteringIndexFilter;
+import org.apache.cassandra.db.filter.ColumnFilter;
+import org.apache.cassandra.db.partitions.AbstractUnfilteredPartitionIterator;
+import org.apache.cassandra.db.partitions.BTreePartitionData;
+import org.apache.cassandra.db.partitions.BTreePartitionUpdater;
+import org.apache.cassandra.db.partitions.ImmutableBTreePartition;
+import org.apache.cassandra.db.partitions.Partition;
+import org.apache.cassandra.db.partitions.PartitionUpdate;
+import org.apache.cassandra.db.partitions.UnfilteredPartitionIterator;
+import org.apache.cassandra.db.rows.EncodingStats;
+import org.apache.cassandra.db.rows.Row;
+import org.apache.cassandra.db.rows.UnfilteredRowIterator;
+import org.apache.cassandra.db.tries.InMemoryTrie;
+import org.apache.cassandra.db.tries.Trie;
+import org.apache.cassandra.dht.AbstractBounds;
+import org.apache.cassandra.dht.Bounds;
+import
[cassandra] branch cassandra-4.0 updated (6c65c9e49e -> a83de9bcd2)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 6c65c9e49e Merge branch 'cassandra-3.11' into cassandra-4.0 new b8a87abba4 Do not leak 2015 synthetic memtable Epoch new a83de9bcd2 Merge branch 'cassandra-3.11' into cassandra-4.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: src/java/org/apache/cassandra/db/Memtable.java | 20 +++- .../cassandra/db/SinglePartitionReadCommand.java | 3 ++- .../db/compaction/CompactionController.java | 16 +++- .../apache/cassandra/db/ColumnFamilyStoreTest.java | 9 + 4 files changed, 41 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18118) Do not leak 2015 memtable synthetic Epoch
[
https://issues.apache.org/jira/browse/CASSANDRA-18118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18118:
Status: Ready to Commit (was: Review In Progress)
> Do not leak 2015 memtable synthetic Epoch
> -
>
> Key: CASSANDRA-18118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18118
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> This
> [Epoch|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> can
> [leak|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/Memtable.java#L392]
> affecting all the timestamps logic. It has been observed in a production
> env it can i.e. prevent proper sstable and tombstone cleanup.
> To reproduce create the following table:
> {noformat}
> drop keyspace test;
> create keyspace test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> CREATE TABLE test.test (
> key text PRIMARY KEY,
> id text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '2', 'tombstone_compaction_interval':
> '3000', 'tombstone_threshold': '0.1', 'unchecked_tombstone_compaction':
> 'true'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 10
> AND gc_grace_seconds = 10
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> CREATE INDEX id_idx ON test.test (id);
> {noformat}
> And stress load it with:
> {noformat}
> insert into test.test (key,id) values('$RANDOM_UUID $RANDOM_UUID',
> 'eaca36a1-45f1-469c-a3f6-3ba54220363f') USING TTL 10
> {noformat}
> Notice how all inserts have a 10s TTL, the default 10s TTL and gc_grace is
> also at 10s. This is to speed up the repro:
> - Run the load for a couple minutes and track sstables disk usage. You will
> see it does only increase, nothing gets cleaned up and it doesn't stop
> growing (notice all this is well past the 10s gc_grace and TTL)
> - Running a flush and a compaction while under load against the keyspace,
> table or index doesn't solve the issue.
> - Stopping the load and running a compaction doesn't solve the issue.
> Flushing does though.
> - On the original observation where TTL was around 600s and gc_grace around
> 1800s we could get GBs of sstables that weren't cleaned up or compacted away
> after hours of work.
> - Reproduction can also happen on plain sstables by repeatedly
> inserting/deleting/overwriting the same values over and over again without 2i
> indices or TTL being involved.
> The problem seems to be
> [EncodingStats|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> using a synthetic Epoch in 2015 which plays nice with Vint serialization.
> Unfortunately {{Memtable}} is using that to keep track of the
> {{minTimestamp}} which can leak the 2015 Epoch. This confuses any logic
> consuming that timestamp. In this particular case purge and fully expired
> sstables weren't properly detected.
--
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
[cassandra] branch cassandra-3.11 updated: Do not leak 2015 synthetic memtable Epoch
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new b8a87abba4 Do not leak 2015 synthetic memtable Epoch
b8a87abba4 is described below
commit b8a87abba47441d97b3c85a0473d02919e1c071b
Author: Bereng
AuthorDate: Fri Dec 9 11:13:52 2022 +0100
Do not leak 2015 synthetic memtable Epoch
patch by Berenguer Blasi; reviewed by Caleb Rackliffe for CASSANDRA-18118
---
build.xml| 2 ++
src/java/org/apache/cassandra/db/Memtable.java | 20 +++-
.../cassandra/db/SinglePartitionReadCommand.java | 3 ++-
.../db/compaction/CompactionController.java | 16 +++-
.../apache/cassandra/db/ColumnFamilyStoreTest.java | 9 +
5 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/build.xml b/build.xml
index 5e15f4923d..590e523fce 100644
--- a/build.xml
+++ b/build.xml
@@ -1227,6 +1227,8 @@
+
+
diff --git a/src/java/org/apache/cassandra/db/Memtable.java
b/src/java/org/apache/cassandra/db/Memtable.java
index ae8b8d3a74..9cfcb2f830 100644
--- a/src/java/org/apache/cassandra/db/Memtable.java
+++ b/src/java/org/apache/cassandra/db/Memtable.java
@@ -66,6 +66,7 @@ public class Memtable implements Comparable
private static final Logger logger =
LoggerFactory.getLogger(Memtable.class);
public static final MemtablePool MEMORY_POOL =
createMemtableAllocatorPool();
+public static final long NO_MIN_TIMESTAMP = -1;
private static MemtablePool createMemtableAllocatorPool()
{
@@ -161,6 +162,16 @@ public class Memtable implements Comparable
this.columnsCollector = new
ColumnsCollector(metadata.partitionColumns());
}
+@VisibleForTesting
+public Memtable(CFMetaData metadata, long minTimestamp)
+{
+this.initialComparator = metadata.comparator;
+this.cfs = null;
+this.allocator = null;
+this.columnsCollector = new
ColumnsCollector(metadata.partitionColumns());
+this.minTimestamp = minTimestamp;
+}
+
public MemtableAllocator getAllocator()
{
return allocator;
@@ -387,9 +398,16 @@ public class Memtable implements Comparable
return partitions.get(key);
}
+/**
+ * Returns the minTS if one available, otherwise NO_MIN_TIMESTAMP.
+ *
+ * EncodingStats uses a synthetic epoch TS at 2015. We don't want to leak
that (CASSANDRA-18118) so we return NO_MIN_TIMESTAMP instead.
+ *
+ * @return The minTS or NO_MIN_TIMESTAMP if none available
+ */
public long getMinTimestamp()
{
-return minTimestamp;
+return minTimestamp != EncodingStats.NO_STATS.minTimestamp ?
minTimestamp : NO_MIN_TIMESTAMP;
}
/**
diff --git a/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
b/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
index a97243be2f..dfdcc03014 100644
--- a/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
+++ b/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
@@ -713,7 +713,8 @@ public class SinglePartitionReadCommand extends ReadCommand
if (partition == null)
continue;
-minTimestamp = Math.min(minTimestamp,
memtable.getMinTimestamp());
+if (memtable.getMinTimestamp() != Memtable.NO_MIN_TIMESTAMP)
+minTimestamp = Math.min(minTimestamp,
memtable.getMinTimestamp());
@SuppressWarnings("resource") // 'iter' is added to iterators
which is closed on exception, or through the closing of the final merged
iterator
UnfilteredRowIterator iter =
filter.getUnfilteredRowIterator(columnFilter(), partition);
diff --git
a/src/java/org/apache/cassandra/db/compaction/CompactionController.java
b/src/java/org/apache/cassandra/db/compaction/CompactionController.java
index 84aac09052..19318ff1a9 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionController.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionController.java
@@ -207,7 +207,10 @@ public class CompactionController implements AutoCloseable
}
for (Memtable memtable :
cfStore.getTracker().getView().getAllMemtables())
-minTimestamp = Math.min(minTimestamp, memtable.getMinTimestamp());
+{
+if (memtable.getMinTimestamp() != Memtable.NO_MIN_TIMESTAMP)
+minTimestamp = Math.min(minTimestamp,
memtable.getMinTimestamp());
+}
// At this point, minTimestamp denotes the lowest timestamp of any
relevant
// SSTable or Memtable that contains a constructive value. candidates
contains all the
@@ -281,11 +284,14
[cassandra] branch trunk updated (1b2e49e97c -> 995c3abc42)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 1b2e49e97c Merge branch 'cassandra-4.1' into trunk new b8a87abba4 Do not leak 2015 synthetic memtable Epoch new a83de9bcd2 Merge branch 'cassandra-3.11' into cassandra-4.0 new 438346aaa6 Merge branch 'cassandra-4.0' into cassandra-4.1 new 995c3abc42 Merge branch 'cassandra-4.1' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../cassandra/db/SinglePartitionReadCommand.java | 3 +- .../db/compaction/CompactionController.java| 14 +- .../cassandra/db/memtable/AbstractMemtable.java| 12 +- .../org/apache/cassandra/db/memtable/Memtable.java | 2 + .../db/memtable/ShardedSkipListMemtable.java | 9 +- .../apache/cassandra/db/memtable/TrieMemtable.java | 9 +- .../apache/cassandra/db/ColumnFamilyStoreTest.java | 151 + 7 files changed, 192 insertions(+), 8 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into cassandra-4.1
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 438346aaa6aa8b57ae6ee31fd6ab18e6369292f3
Merge: a0c6191238 a83de9bcd2
Author: Bereng
AuthorDate: Thu Jan 12 08:19:22 2023 +0100
Merge branch 'cassandra-4.0' into cassandra-4.1
.../cassandra/db/SinglePartitionReadCommand.java | 3 +-
.../db/compaction/CompactionController.java| 14 +-
.../cassandra/db/memtable/AbstractMemtable.java| 19 ++-
.../org/apache/cassandra/db/memtable/Memtable.java | 2 +
.../db/memtable/ShardedSkipListMemtable.java | 9 +-
.../apache/cassandra/db/ColumnFamilyStoreTest.java | 152 +
6 files changed, 192 insertions(+), 7 deletions(-)
diff --cc src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
index 64136b6099,8ac26e8513..963b9fee1c
--- a/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
+++ b/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java
@@@ -661,19 -605,20 +661,20 @@@ public class SinglePartitionReadComman
InputCollector inputCollector =
iteratorsForPartition(view, controller);
try
{
+SSTableReadMetricsCollector metricsCollector = new
SSTableReadMetricsCollector();
+
for (Memtable memtable : view.memtables)
{
-Partition partition = memtable.getPartition(partitionKey());
-if (partition == null)
+@SuppressWarnings("resource") // 'iter' is added to iterators
which is closed on exception, or through the closing of the final merged
iterator
+UnfilteredRowIterator iter =
memtable.rowIterator(partitionKey(), filter.getSlices(metadata()),
columnFilter(), filter.isReversed(), metricsCollector);
+if (iter == null)
continue;
- minTimestamp = Math.min(minTimestamp,
memtable.getMinTimestamp());
+ if (memtable.getMinTimestamp() != Memtable.NO_MIN_TIMESTAMP)
+ minTimestamp = Math.min(minTimestamp,
memtable.getMinTimestamp());
-@SuppressWarnings("resource") // 'iter' is added to iterators
which is closed on exception, or through the closing of the final merged
iterator
-UnfilteredRowIterator iter =
filter.getUnfilteredRowIterator(columnFilter(), partition);
-
// Memtable data is always considered unrepaired
-
controller.updateMinOldestUnrepairedTombstone(partition.stats().minLocalDeletionTime);
+
controller.updateMinOldestUnrepairedTombstone(memtable.getMinLocalDeletionTime());
inputCollector.addMemtableIterator(RTBoundValidator.validate(iter,
RTBoundValidator.Stage.MEMTABLE, false));
mostRecentPartitionTombstone =
Math.max(mostRecentPartitionTombstone,
diff --cc src/java/org/apache/cassandra/db/compaction/CompactionController.java
index 26dcdd39a6,bb2094f931..0e79fc1b59
--- a/src/java/org/apache/cassandra/db/compaction/CompactionController.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionController.java
@@@ -263,10 -270,14 +266,13 @@@ public class CompactionController exten
for (Memtable memtable : memtables)
{
- if (memtable.rowIterator(key) != null)
+ if (memtable.getMinTimestamp() != Memtable.NO_MIN_TIMESTAMP)
{
- minTimestampSeen = Math.min(minTimestampSeen,
memtable.getMinTimestamp());
- hasTimestamp = true;
-Partition partition = memtable.getPartition(key);
-if (partition != null)
++if (memtable.rowIterator(key) != null)
+ {
-minTimestampSeen = Math.min(minTimestampSeen,
partition.stats().minTimestamp);
++minTimestampSeen = Math.min(minTimestampSeen,
memtable.getMinTimestamp());
+ hasTimestamp = true;
+ }
}
}
diff --cc src/java/org/apache/cassandra/db/memtable/AbstractMemtable.java
index 0ac7482e4a,00..ca6dbf6577
mode 100644,00..100644
--- a/src/java/org/apache/cassandra/db/memtable/AbstractMemtable.java
+++ b/src/java/org/apache/cassandra/db/memtable/AbstractMemtable.java
@@@ -1,221 -1,0 +1,238 @@@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit a83de9bcd21a032c1dbc6dc323c7e53f828b2cb6
Merge: 6c65c9e49e b8a87abba4
Author: Bereng
AuthorDate: Thu Jan 12 08:17:48 2023 +0100
Merge branch 'cassandra-3.11' into cassandra-4.0
src/java/org/apache/cassandra/db/Memtable.java | 20 +++-
.../cassandra/db/SinglePartitionReadCommand.java | 3 ++-
.../db/compaction/CompactionController.java | 16 +++-
.../apache/cassandra/db/ColumnFamilyStoreTest.java | 9 +
4 files changed, 41 insertions(+), 7 deletions(-)
diff --cc src/java/org/apache/cassandra/db/Memtable.java
index 73f45f7b96,9cfcb2f830..c6eb68ea57
--- a/src/java/org/apache/cassandra/db/Memtable.java
+++ b/src/java/org/apache/cassandra/db/Memtable.java
@@@ -169,9 -159,19 +170,19 @@@ public class Memtable implements Compar
this.initialComparator = metadata.comparator;
this.cfs = null;
this.allocator = null;
-this.columnsCollector = new
ColumnsCollector(metadata.partitionColumns());
+this.columnsCollector = new
ColumnsCollector(metadata.regularAndStaticColumns());
}
+ @VisibleForTesting
-public Memtable(CFMetaData metadata, long minTimestamp)
++public Memtable(TableMetadata metadata, long minTimestamp)
+ {
+ this.initialComparator = metadata.comparator;
+ this.cfs = null;
+ this.allocator = null;
-this.columnsCollector = new
ColumnsCollector(metadata.partitionColumns());
++this.columnsCollector = new
ColumnsCollector(metadata.regularAndStaticColumns());
+ this.minTimestamp = minTimestamp;
+ }
+
public MemtableAllocator getAllocator()
{
return allocator;
diff --cc test/unit/org/apache/cassandra/db/ColumnFamilyStoreTest.java
index 266b37d86a,8e8e9c94b7..b1c6599b5b
--- a/test/unit/org/apache/cassandra/db/ColumnFamilyStoreTest.java
+++ b/test/unit/org/apache/cassandra/db/ColumnFamilyStoreTest.java
@@@ -91,6 -96,17 +91,15 @@@ public class ColumnFamilyStoreTes
Keyspace.open(KEYSPACE2).getColumnFamilyStore(CF_STANDARD1).truncateBlocking();
}
+ @Test
+ public void testMemtableTimestamp() throws Throwable
+ {
+ assertEquals(Memtable.NO_MIN_TIMESTAMP,
- (new
Memtable(Keyspace.open(KEYSPACE1).getColumnFamilyStore(CF_STANDARD1).metadata,
++ (new
Memtable(Keyspace.open(KEYSPACE1).getColumnFamilyStore(CF_STANDARD1).metadata(),
+EncodingStats.NO_STATS.minTimestamp))
+ .getMinTimestamp());
+ }
+
@Test
// create two sstables, and verify that we only deserialize data from the
most recent one
public void testTimeSortedQuery()
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675835#comment-17675835 ] maxwellguo commented on CASSANDRA-18061: Hi [~jlewandowski][~smiklosovic], I adjusted part of the code , so can you help to take a look agagin? Thanks > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 3h 50m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675825#comment-17675825
]
Berenguer Blasi commented on CASSANDRA-18032:
-
Thx for the reviews!
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {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-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18032:
Fix Version/s: 3.0.29
3.11.15
4.0.8
4.1.1
4.2
(was: 3.0.x)
(was: 3.11.x)
(was: 4.0.x)
(was: 4.1.x)
Since Version: 4.1.0
Source Control Link:
https://github.com/apache/cassandra/commit/69dfed3671144c019fb69793e3152b5a71d76421
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {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-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18032:
Status: Ready to Commit (was: Review In Progress)
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {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-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18032:
Reviewers: Andres de la Peña, Berenguer Blasi (was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {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
[cassandra] branch cassandra-4.1 updated (da5ec9a8e3 -> a0c6191238)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from da5ec9a8e3 Merge branch 'cassandra-4.0' into cassandra-4.1 new 69dfed3671 When generate.sh fails its rc=0 new 7fe71274d0 Merge branch 'cassandra-3.0' into cassandra-3.11 new 6c65c9e49e Merge branch 'cassandra-3.11' into cassandra-4.0 new a0c6191238 Merge branch 'cassandra-4.0' into cassandra-4.1 The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/generate.sh | 1 + 1 file changed, 1 insertion(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (f17e431f24 -> 6c65c9e49e)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from f17e431f24 Merge branch 'cassandra-3.11' into cassandra-4.0 new 69dfed3671 When generate.sh fails its rc=0 new 7fe71274d0 Merge branch 'cassandra-3.0' into cassandra-3.11 new 6c65c9e49e Merge branch 'cassandra-3.11' into cassandra-4.0 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/generate.sh | 1 + 1 file changed, 1 insertion(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into cassandra-4.1
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit a0c6191238dfde1a21f078f6505b0a5ff42de1b2
Merge: da5ec9a8e3 6c65c9e49e
Author: Bereng
AuthorDate: Thu Jan 12 07:08:36 2023 +0100
Merge branch 'cassandra-4.0' into cassandra-4.1
.circleci/generate.sh | 1 +
1 file changed, 1 insertion(+)
diff --cc .circleci/generate.sh
index 384709489b,634a0807b4..faa5f80b43
--- a/.circleci/generate.sh
+++ b/.circleci/generate.sh
@@@ -18,7 -18,8 +18,8 @@@
#
BASEDIR=`dirname $0`
-BASE_BRANCH=cassandra-4.0
+BASE_BRANCH=cassandra-4.1
+ set -e
die ()
{
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 1b2e49e97c138124d2a74900dfefd5ea6fec1cef
Merge: e936b2cc1b a0c6191238
Author: Bereng
AuthorDate: Thu Jan 12 07:09:54 2023 +0100
Merge branch 'cassandra-4.1' into trunk
.circleci/generate.sh | 1 +
1 file changed, 1 insertion(+)
diff --cc .circleci/generate.sh
index 379af70bdf,faa5f80b43..c605e835f5
--- a/.circleci/generate.sh
+++ b/.circleci/generate.sh
@@@ -18,7 -18,8 +18,8 @@@
#
BASEDIR=`dirname $0`
-BASE_BRANCH=cassandra-4.1
+BASE_BRANCH=trunk
+ set -e
die ()
{
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: When generate.sh fails its rc=0
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new 69dfed3671 When generate.sh fails its rc=0
69dfed3671 is described below
commit 69dfed3671144c019fb69793e3152b5a71d76421
Author: Bereng
AuthorDate: Fri Nov 11 09:56:49 2022 +0100
When generate.sh fails its rc=0
patch by Berenguer Blasi; reviewed by Andres de la Peña for CASSANDRA-18032
---
.circleci/generate.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/.circleci/generate.sh b/.circleci/generate.sh
index c3a836a97e..ac08687556 100755
--- a/.circleci/generate.sh
+++ b/.circleci/generate.sh
@@ -19,6 +19,7 @@
BASEDIR=`dirname $0`
BASE_BRANCH=cassandra-3.0
+set -e
die ()
{
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 7fe71274d009b18c16f71c7e223eb8f225ed5a8e
Merge: 156cc6fedc 69dfed3671
Author: Bereng
AuthorDate: Thu Jan 12 07:06:04 2023 +0100
Merge branch 'cassandra-3.0' into cassandra-3.11
.circleci/generate.sh | 1 +
1 file changed, 1 insertion(+)
diff --cc .circleci/generate.sh
index a40e002da7,ac08687556..15c2849645
--- a/.circleci/generate.sh
+++ b/.circleci/generate.sh
@@@ -18,7 -18,8 +18,8 @@@
#
BASEDIR=`dirname $0`
-BASE_BRANCH=cassandra-3.0
+BASE_BRANCH=cassandra-3.11
+ set -e
die ()
{
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (e936b2cc1b -> 1b2e49e97c)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from e936b2cc1b fix serialization error in getsstables --show-levels new 69dfed3671 When generate.sh fails its rc=0 new 7fe71274d0 Merge branch 'cassandra-3.0' into cassandra-3.11 new 6c65c9e49e Merge branch 'cassandra-3.11' into cassandra-4.0 new a0c6191238 Merge branch 'cassandra-4.0' into cassandra-4.1 new 1b2e49e97c Merge branch 'cassandra-4.1' into trunk The 5 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/generate.sh | 1 + 1 file changed, 1 insertion(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 6c65c9e49e656fc1fc4ae23adda391d0e3d4f2b4
Merge: f17e431f24 7fe71274d0
Author: Bereng
AuthorDate: Thu Jan 12 07:07:30 2023 +0100
Merge branch 'cassandra-3.11' into cassandra-4.0
.circleci/generate.sh | 1 +
1 file changed, 1 insertion(+)
diff --cc .circleci/generate.sh
index f7e1b575ff,15c2849645..634a0807b4
--- a/.circleci/generate.sh
+++ b/.circleci/generate.sh
@@@ -18,7 -18,8 +18,8 @@@
#
BASEDIR=`dirname $0`
-BASE_BRANCH=cassandra-3.11
+BASE_BRANCH=cassandra-4.0
+ set -e
die ()
{
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (156cc6fedc -> 7fe71274d0)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 156cc6fedc Merge branch 'cassandra-3.0' into cassandra-3.11 new 69dfed3671 When generate.sh fails its rc=0 new 7fe71274d0 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/generate.sh | 1 + 1 file changed, 1 insertion(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18022) Extend profileload to track by additional metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-18022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675786#comment-17675786 ] Jordan West commented on CASSANDRA-18022: - New test runs here: [j11|https://app.circleci.com/pipelines/github/jrwest/cassandra/142/workflows/99bb5ff6-2704-443b-8c26-396fffa2dd2d] [j8|https://app.circleci.com/pipelines/github/jrwest/cassandra/142/workflows/88ad9267-90ed-433d-b4f0-347d2687dab6] Pretty sure those failures were a race condition between the sampler threads and the test thread. While I don't love the solution I used, adding sleeps, it does accurately simulate how profileload works in prod (sleeping between begin/finishSampling calls). > Extend profileload to track by additional metrics > - > > Key: CASSANDRA-18022 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18022 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > Add option to toppartitions to track by: > * Row Count > * Tombstone Count > * SSTable Count > * Latency -- 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-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16895: Description: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup *NOTE:* GC tuning, performance testing were never agreed to be part of this ticket. was: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Epic > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > This ticket is intended to group all issues found to support Java 17 in the > future. > Upgrade steps: > * [Dependencies > |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to > be updated (not all but at least those that require an update in order to > work with Java 17) > * More encapsulated JDK internal APIs. Some of the issues might be solved > with the dependencies updates > * Currently trunk compiles if we remove the Nashorn dependency (ant script > tag, used for the test environment; UDFs) . The oracle recommendation to use > Nashorn-core won't work for the project as it is under GPL 2.0. Most probably > we will opt in for graal-sdk licensed under UPL > * All tests to be cleaned > * CI environment to be setup > *NOTE:* GC tuning, performance testing were never agreed to be part of this > ticket. -- 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-18022) Extend profileload to track by additional metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-18022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675782#comment-17675782 ] Jordan West commented on CASSANDRA-18022: - hmm wasn't expecting the new tests to fail. will take a closer look. > Extend profileload to track by additional metrics > - > > Key: CASSANDRA-18022 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18022 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > Add option to toppartitions to track by: > * Row Count > * Tombstone Count > * SSTable Count > * Latency -- 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-18022) Extend profileload to track by additional metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-18022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675776#comment-17675776 ] Jordan West commented on CASSANDRA-18022: - You are correct about the bug. I had conflated onClose with onPartitionClose. Fixed and added a test. New test runs: [j11|https://app.circleci.com/pipelines/github/jrwest/cassandra/140/workflows/b67f4535-e9f5-4874-a3cc-3d3812400e51] [j8|https://app.circleci.com/pipelines/github/jrwest/cassandra/140/workflows/8fa018e1-1237-4f83-94b4-7b2693e26d3e] > Extend profileload to track by additional metrics > - > > Key: CASSANDRA-18022 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18022 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > Add option to toppartitions to track by: > * Row Count > * Tombstone Count > * SSTable Count > * Latency -- 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-18140) getsstables --show-levels JMX serialization error
[
https://issues.apache.org/jira/browse/CASSANDRA-18140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-18140:
Fix Version/s: NA
Since Version: 4.2
Source Control Link:
https://github.com/apache/cassandra/commit/e936b2cc1ba7f525c636de5f9fb1780ca70f1762
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Commited as
https://github.com/apache/cassandra/commit/e936b2cc1ba7f525c636de5f9fb1780ca70f1762
> getsstables --show-levels JMX serialization error
> -
>
> Key: CASSANDRA-18140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18140
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: NA
>
>
> While the interface is compliant and tested by JMXStandardsTest the
> implementation is not actually serializable:
> {{java.io.NotSerializableException:
> com.google.common.collect.AbstractMapBasedMultimap$AsMap}}
--
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
[cassandra] branch trunk updated (386bf7815a -> e936b2cc1b)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 386bf7815a Merge branch 'cassandra-4.1' into trunk add e936b2cc1b fix serialization error in getsstables --show-levels No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + .../org/apache/cassandra/db/ColumnFamilyStore.java| 19 +-- .../apache/cassandra/db/ColumnFamilyStoreMBean.java | 2 +- src/java/org/apache/cassandra/tools/NodeProbe.java| 3 +-- .../apache/cassandra/tools/nodetool/GetSSTables.java | 4 ++-- 5 files changed, 18 insertions(+), 11 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18140) getsstables --show-levels JMX serialization error
[
https://issues.apache.org/jira/browse/CASSANDRA-18140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-18140:
Reviewers: Brandon Williams, Cheng Wang (was: Brandon Williams)
> getsstables --show-levels JMX serialization error
> -
>
> Key: CASSANDRA-18140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18140
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
>
> While the interface is compliant and tested by JMXStandardsTest the
> implementation is not actually serializable:
> {{java.io.NotSerializableException:
> com.google.common.collect.AbstractMapBasedMultimap$AsMap}}
--
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-18140) getsstables --show-levels JMX serialization error
[
https://issues.apache.org/jira/browse/CASSANDRA-18140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-18140:
Status: Ready to Commit (was: Review In Progress)
> getsstables --show-levels JMX serialization error
> -
>
> Key: CASSANDRA-18140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18140
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
>
> While the interface is compliant and tested by JMXStandardsTest the
> implementation is not actually serializable:
> {{java.io.NotSerializableException:
> com.google.common.collect.AbstractMapBasedMultimap$AsMap}}
--
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-18114) Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
[
https://issues.apache.org/jira/browse/CASSANDRA-18114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18114:
--
Reviewers: David Capwell
Status: Review In Progress (was: Patch Available)
+1
> Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
> ---
>
> Key: CASSANDRA-18114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18114
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CollectionSerializer}} and its subclasses have completely ignored
> {{ProtocolVersion}} for a very long time. It’s possible we may need to
> version their behavior in the future, but there’s no reason to keep the dead
> code in the meantime, as it causes confusion around whether code that uses
> these classes needs to provide a version.
--
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-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Status: Patch Available (was: Ready to Commit) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 50m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- 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-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Status: Needs Committer (was: Patch Available) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 50m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- 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-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675740#comment-17675740 ] Paulo Motta commented on CASSANDRA-16418: - I rebased and squashed Lindsey's commit [on this branch|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418] + updated tests [from this commit|https://github.com/pauloricardomg/cassandra/commit/702f77d247893a51461823268ad6a20cd6c1a021] and submitted CI on https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418 (still queued). I think this is ready for a second round of review. [~JoshuaMcKenzie] [~stefan.miklosovic] would you have cycles to take a look? > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 50m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- 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-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Status: Ready to Commit (was: Changes Suggested) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 50m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- 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-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675737#comment-17675737
]
Paulo Motta commented on CASSANDRA-16418:
-
In order to check the tests were reliably reproducing the issue on Lindsey's
[branch|https://github.com/apache/cassandra/pull/2061] I commented out the
following excerpt:
{noformat}
InetAddressAndPort localAddress =
FBUtilities.getBroadcastAddressAndPort();
Integer pendingRangesCount =
tokenMetadata.getPendingRanges(keyspaceName, localAddress).size();
if (pendingRangesCount > 0)
{
throw new RuntimeException("Node is involved in cluster membership
changes. Not safe to run cleanup.");
}
{noformat}
And expected both
[testCleanupFailsDuringOngoingDecommission|https://github.com/apache/cassandra/pull/2061/files#diff-68d2cd75caa0e4091c7206717116594bdcb0aab38f72f6d6afa44eac60466e13R41]
and
[testCleanupFailsDuringOngoingBootstrap|https://github.com/apache/cassandra/pull/2061/files#diff-68d2cd75caa0e4091c7206717116594bdcb0aab38f72f6d6afa44eac60466e13R85]
to fail.
Even though the tests failed most of the time, sometimes the tests passed so
data was not being wrongly cleaned up as expected.
The reason for this is that these tests require that the cleanup is executed
between the sstables are transferred by streaming and the ring membership
operation is finished. There is a small chance cleanup is not executed within
this window so the issue will not reproduce, especially if we run this test on
faster hardware.
I took a slightly different testing approach on [this
commit|https://github.com/pauloricardomg/cassandra/blob/702f77d247893a51461823268ad6a20cd6c1a021/test/distributed/org/apache/cassandra/distributed/test/ring/CleanupFailureTest.java#L40]
that inserts data while a node is bootstrapping or decommissioning and checks
the data is present after a cleanup is run. This was able to reliably reproduce
the issue when the excerpt above is commented out.
The updated test is more deterministic because we don't depend on streaming nor
timing. Furthermore this makes the test faster since we don't need so many rows
to reproduce the issue, which is needed with the streaming approach.
A nice benefit of this approach is that since we only run cleanup a single time
while the node is bootstrapping/decommissioning, we're able to [verify that the
cleanup fails with the expected error
message|https://github.com/pauloricardomg/cassandra/blob/702f77d247893a51461823268ad6a20cd6c1a021/test/distributed/org/apache/cassandra/distributed/test/ring/CleanupFailureTest.java#L105].
> Unsafe to run nodetool cleanup during bootstrap or decommission
> ---
>
> Key: CASSANDRA-16418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16418
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: James Baker
>Assignee: Lindsey Zurovchak
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> What we expected: Running a cleanup is a safe operation; the result of
> running a query after a cleanup should be the same as the result of running a
> query before a cleanup.
> What actually happened: We ran a cleanup during a decommission. All the
> streamed data was silently deleted, the bootstrap did not fail, the cluster's
> data after the decommission was very different to the state before.
> Why: Cleanups do not take into account pending ranges and so the cleanup
> thought that all the data that had just been streamed was redundant and so
> deleted it. We think that this is symmetric with bootstraps, though have not
> verified.
> Not sure if this is technically a bug but it was very surprising (and
> seemingly undocumented) behaviour.
>
--
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-18150) Prefer snakeyaml's SafeConstructor over Constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18150: - Change Category: Code Clarity Complexity: Low Hanging Fruit Component/s: Local/Config Fix Version/s: 3.0.x 3.11.x 4.0.x 4.1.x 4.x Assignee: Brandon Williams Status: Open (was: Triage Needed) > Prefer snakeyaml's SafeConstructor over Constructor > --- > > Key: CASSANDRA-18150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > CVE-2022-1471 allows RCE through the Constructor class. While this isn't a > concern since yaml is only used for configuration, it is simple enough to > switch to SafeConstructor and harden the server a little more. -- 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-16304) Consider implementing ClusteringComparator without a lambda
[
https://issues.apache.org/jira/browse/CASSANDRA-16304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16304:
Issue Type: Task (was: Improvement)
> Consider implementing ClusteringComparator without a lambda
> ---
>
> Key: CASSANDRA-16304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16304
> Project: Cassandra
> Issue Type: Task
> Components: Jamm
>Reporter: Adrian Cole
>Priority: Normal
> Fix For: 4.x
>
>
> Using lambdas forces jamm to do things that can easily break. It might be
> safer to implement things like ClusteringComparator directly as classes or as
> an enum
> {noformat}
> Unexpected exception during request
> (org.apache.cassandra.transport.messages.ErrorMessage)
> java.lang.UnsupportedOperationException: can't get field offset on a hidden
> class: private final org.apache.cassandra.db.ClusteringComparator
> org.apache.cassandra.db.ClusteringComparator$$Lambda$165/0x00010028ab60.arg$1
> at jdk.unsupported/sun.misc.Unsafe.objectFieldOffset(Unknown Source)
> at
> org.github.jamm.MemoryLayoutSpecification.sizeOfInstanceWithUnsafe(MemoryLayoutSpecification.java:108)
> at
> org.github.jamm.MemoryLayoutSpecification.sizeOfWithUnsafe(MemoryLayoutSpecification.java:89)
> at org.github.jamm.MemoryMeter.measure(MemoryMeter.java:217)
> at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:259)
> at
> org.apache.cassandra.utils.ObjectSizes.measureDeep(ObjectSizes.java:155)
> at
> org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:454)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:424)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:408)
> at
> org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:114)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Unknown Source)
> {noformat}
--
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-18118) Do not leak 2015 memtable synthetic Epoch
[
https://issues.apache.org/jira/browse/CASSANDRA-18118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675735#comment-17675735
]
Caleb Rackliffe commented on CASSANDRA-18118:
-
+1 on all PRs
Thanks for the patches!
> Do not leak 2015 memtable synthetic Epoch
> -
>
> Key: CASSANDRA-18118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18118
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> This
> [Epoch|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> can
> [leak|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/Memtable.java#L392]
> affecting all the timestamps logic. It has been observed in a production
> env it can i.e. prevent proper sstable and tombstone cleanup.
> To reproduce create the following table:
> {noformat}
> drop keyspace test;
> create keyspace test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> CREATE TABLE test.test (
> key text PRIMARY KEY,
> id text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '2', 'tombstone_compaction_interval':
> '3000', 'tombstone_threshold': '0.1', 'unchecked_tombstone_compaction':
> 'true'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 10
> AND gc_grace_seconds = 10
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> CREATE INDEX id_idx ON test.test (id);
> {noformat}
> And stress load it with:
> {noformat}
> insert into test.test (key,id) values('$RANDOM_UUID $RANDOM_UUID',
> 'eaca36a1-45f1-469c-a3f6-3ba54220363f') USING TTL 10
> {noformat}
> Notice how all inserts have a 10s TTL, the default 10s TTL and gc_grace is
> also at 10s. This is to speed up the repro:
> - Run the load for a couple minutes and track sstables disk usage. You will
> see it does only increase, nothing gets cleaned up and it doesn't stop
> growing (notice all this is well past the 10s gc_grace and TTL)
> - Running a flush and a compaction while under load against the keyspace,
> table or index doesn't solve the issue.
> - Stopping the load and running a compaction doesn't solve the issue.
> Flushing does though.
> - On the original observation where TTL was around 600s and gc_grace around
> 1800s we could get GBs of sstables that weren't cleaned up or compacted away
> after hours of work.
> - Reproduction can also happen on plain sstables by repeatedly
> inserting/deleting/overwriting the same values over and over again without 2i
> indices or TTL being involved.
> The problem seems to be
> [EncodingStats|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> using a synthetic Epoch in 2015 which plays nice with Vint serialization.
> Unfortunately {{Memtable}} is using that to keep track of the
> {{minTimestamp}} which can leak the 2015 Epoch. This confuses any logic
> consuming that timestamp. In this particular case purge and fully expired
> sstables weren't properly detected.
--
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-18110) Streaming progress virtual table lock contention can trigger TCP_USER_TIMEOUT and fail streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-18110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675733#comment-17675733
]
David Capwell commented on CASSANDRA-18110:
---
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|cassandra-4.1|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-18110-cassandra-4.1-880F7124-2E8C-43F5-891A-F37CABAF55FB]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-18110-cassandra-4.1-880F7124-2E8C-43F5-891A-F37CABAF55FB]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/2180/]|
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-18110-trunk-880F7124-2E8C-43F5-891A-F37CABAF55FB]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-18110-trunk-880F7124-2E8C-43F5-891A-F37CABAF55FB]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/2181/]|
> Streaming progress virtual table lock contention can trigger TCP_USER_TIMEOUT
> and fail streaming
>
>
> Key: CASSANDRA-18110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18110
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Jon Meredith
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
>
> Running four concurrent host replacements on a 4.1.0 development cluster has
> repeatably failed to complete bootstrap with all four hosts failing bootsrrap
> and staying in JOINING, logging the message.
> {code:java}
> ERROR 2022-12-07T21:15:48,860 [main]
> org.apache.cassandra.service.StorageService:2019 - Error while waiting on
> bootstrap to complete. Bootstrap will have to be restarted.
> {code}
> Bootstrap fails as the the FileStreamTasks on the streaming followers
> encounter an EOF while transmitting the files.
> {code:java}
> ERROR 2022-12-07T15:49:39,164 [NettyStreaming-Outbound-/1.2.3.4.7000:2]
> org.apache.cassandra.streaming.StreamSession:718 - [Stream
> #8d313690-7674-11ed-813f-95c261b64a82] Streaming error occurred on session
> with peer 1.2.3.4:7000 through 1.2.3.4:40292
> org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException: The channel
> this output stream was writing to has been closed
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.propagateFailedFlush(AsyncChannelOutputPlus.java:200)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitUntilFlushed(AsyncChannelOutputPlus.java:158)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitForSpace(AsyncChannelOutputPlus.java:140)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.beginFlush(AsyncChannelOutputPlus.java:97)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.lambda$writeToChannel$0(AsyncStreamingOutputPlus.java:124)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.lambda$write$0(CassandraCompressedStreamWriter.java:89)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.writeToChannel(AsyncStreamingOutputPlus.java:120)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.write(CassandraCompressedStreamWriter.java:88)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraOutgoingFile.write(CassandraOutgoingFile.java:177)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage.serialize(OutgoingStreamMessage.java:87)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:45)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:34)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:39)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.async.StreamingMultiplexedChannel$FileStreamTask.run(StreamingMultiplexedChannel.java:311)
> [cassandra.jar]
>at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> [cassandra.jar]
>at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
>at
>
[jira] [Commented] (CASSANDRA-18149) snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064
[ https://issues.apache.org/jira/browse/CASSANDRA-18149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675731#comment-17675731 ] Brandon Williams commented on CASSANDRA-18149: -- CVE-2021-4235: https://nvd.nist.gov/vuln/detail/CVE-2021-4235 Denial of service vector, which isn't a concern. CVE-2022-1471: https://nvd.nist.gov/vuln/detail/CVE-2022-1471 RCE through the Constructor() class. It is recommended to use the SafeConstructor() class instead. I've created CASSANDRA-18150 to handle that. CVE-2022-3064: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3064 parsing malicious yaml can cause a DoS, again not a concern. > snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064 > -- > > Key: CASSANDRA-18149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18149 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > The OWASP scan is reporting these for both snakeyaml-1.11 and snakeyaml-1.26. > These are similar to CASSANDRA-17907 in that they require access to the yaml > to have any effect. -- 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] [Created] (CASSANDRA-18150) Prefer snakeyaml's SafeConstructor over Constructor
Brandon Williams created CASSANDRA-18150: Summary: Prefer snakeyaml's SafeConstructor over Constructor Key: CASSANDRA-18150 URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams CVE-2022-1471 allows RCE through the Constructor class. While this isn't a concern since yaml is only used for configuration, it is simple enough to switch to SafeConstructor and harden the server a little more. -- 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-18110) Streaming progress virtual table lock contention can trigger TCP_USER_TIMEOUT and fail streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-18110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18110:
--
Status: Ready to Commit (was: Review In Progress)
> Streaming progress virtual table lock contention can trigger TCP_USER_TIMEOUT
> and fail streaming
>
>
> Key: CASSANDRA-18110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18110
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Jon Meredith
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
>
> Running four concurrent host replacements on a 4.1.0 development cluster has
> repeatably failed to complete bootstrap with all four hosts failing bootsrrap
> and staying in JOINING, logging the message.
> {code:java}
> ERROR 2022-12-07T21:15:48,860 [main]
> org.apache.cassandra.service.StorageService:2019 - Error while waiting on
> bootstrap to complete. Bootstrap will have to be restarted.
> {code}
> Bootstrap fails as the the FileStreamTasks on the streaming followers
> encounter an EOF while transmitting the files.
> {code:java}
> ERROR 2022-12-07T15:49:39,164 [NettyStreaming-Outbound-/1.2.3.4.7000:2]
> org.apache.cassandra.streaming.StreamSession:718 - [Stream
> #8d313690-7674-11ed-813f-95c261b64a82] Streaming error occurred on session
> with peer 1.2.3.4:7000 through 1.2.3.4:40292
> org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException: The channel
> this output stream was writing to has been closed
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.propagateFailedFlush(AsyncChannelOutputPlus.java:200)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitUntilFlushed(AsyncChannelOutputPlus.java:158)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitForSpace(AsyncChannelOutputPlus.java:140)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.beginFlush(AsyncChannelOutputPlus.java:97)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.lambda$writeToChannel$0(AsyncStreamingOutputPlus.java:124)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.lambda$write$0(CassandraCompressedStreamWriter.java:89)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.writeToChannel(AsyncStreamingOutputPlus.java:120)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.write(CassandraCompressedStreamWriter.java:88)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraOutgoingFile.write(CassandraOutgoingFile.java:177)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage.serialize(OutgoingStreamMessage.java:87)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:45)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:34)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:39)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.async.StreamingMultiplexedChannel$FileStreamTask.run(StreamingMultiplexedChannel.java:311)
> [cassandra.jar]
>at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> [cassandra.jar]
>at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
>at java.lang.Thread.run(Thread.java:829) [?:?]
>Suppressed: java.nio.channels.ClosedChannelException
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.doFlush(AsyncStreamingOutputPlus.java:82)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.flush(AsyncChannelOutputPlus.java:229)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.close(AsyncChannelOutputPlus.java:248)
> ~[cassandra.jar]
>at
>
[jira] [Updated] (CASSANDRA-18149) snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064
[ https://issues.apache.org/jira/browse/CASSANDRA-18149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18149: - Description: The OWASP scan is reporting these for both snakeyaml-1.11 and snakeyaml-1.26. These are similar to CASSANDRA-17907 in that they require access to the yaml to have any effect. was:These are similar to CASSANDRA-17907 in that they require access to the yaml to have any effect. > snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064 > -- > > Key: CASSANDRA-18149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18149 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > The OWASP scan is reporting these for both snakeyaml-1.11 and snakeyaml-1.26. > These are similar to CASSANDRA-17907 in that they require access to the yaml > to have any effect. -- 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-18149) snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064
[ https://issues.apache.org/jira/browse/CASSANDRA-18149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18149: - Bug Category: Parent values: Security(12985) Complexity: Normal Component/s: Dependencies Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064 > -- > > Key: CASSANDRA-18149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18149 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > These are similar to CASSANDRA-17907 in that they require access to the yaml > to have any effect. -- 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] [Assigned] (CASSANDRA-18149) snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064
[ https://issues.apache.org/jira/browse/CASSANDRA-18149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-18149: Assignee: Brandon Williams > snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064 > -- > > Key: CASSANDRA-18149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18149 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > These are similar to CASSANDRA-17907 in that they require access to the yaml > to have any effect. -- 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] [Created] (CASSANDRA-18149) snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064
Brandon Williams created CASSANDRA-18149: Summary: snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064 Key: CASSANDRA-18149 URL: https://issues.apache.org/jira/browse/CASSANDRA-18149 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams These are similar to CASSANDRA-17907 in that they require access to the yaml to have any effect. -- 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-18149) snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064
[ https://issues.apache.org/jira/browse/CASSANDRA-18149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18149: - Fix Version/s: 3.0.x 3.11.x 4.0.x 4.1.x 4.x > snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064 > -- > > Key: CASSANDRA-18149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18149 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > These are similar to CASSANDRA-17907 in that they require access to the yaml > to have any effect. -- 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-18148) netty-all vulnerability: CVE-2022-41881
[ https://issues.apache.org/jira/browse/CASSANDRA-18148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18148: - Fix Version/s: 3.0.x 3.11.x 4.0.x 4.1.x 4.x > netty-all vulnerability: CVE-2022-41881 > --- > > Key: CASSANDRA-18148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18148 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This is showing in the OWASP scan. -- 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-18148) netty-all vulnerability: CVE-2022-41881
[ https://issues.apache.org/jira/browse/CASSANDRA-18148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675723#comment-17675723 ] Brandon Williams commented on CASSANDRA-18148: -- https://github.com/netty/netty/security/advisories/GHSA-fx2c-96vj-985v This doesn't appear to affect us, but I am not a netty expert. > netty-all vulnerability: CVE-2022-41881 > --- > > Key: CASSANDRA-18148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18148 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Priority: Normal > > This is showing in the OWASP scan. -- 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-18148) netty-all vulnerability: CVE-2022-41881
[ https://issues.apache.org/jira/browse/CASSANDRA-18148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18148: - Bug Category: Parent values: Security(12985) Complexity: Normal Component/s: Dependencies Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > netty-all vulnerability: CVE-2022-41881 > --- > > Key: CASSANDRA-18148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18148 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This is showing in the OWASP scan. -- 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] [Created] (CASSANDRA-18148) netty-all vulnerability: CVE-2022-41881
Brandon Williams created CASSANDRA-18148: Summary: netty-all vulnerability: CVE-2022-41881 Key: CASSANDRA-18148 URL: https://issues.apache.org/jira/browse/CASSANDRA-18148 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams This is showing in the OWASP scan. -- 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-18147) netty-all vulnerability: CVE-2022-41915
[ https://issues.apache.org/jira/browse/CASSANDRA-18147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675721#comment-17675721 ] Brandon Williams commented on CASSANDRA-18147: -- This is yet another netty HTTP issue that does not affect us as we do not use HTTP and can be suppressed. > netty-all vulnerability: CVE-2022-41915 > --- > > Key: CASSANDRA-18147 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18147 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This is being reported by the OWASP scan. -- 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-18147) netty-all vulnerability: CVE-2022-41915
[ https://issues.apache.org/jira/browse/CASSANDRA-18147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18147: - Fix Version/s: 3.0.x 3.11.x 4.0.x 4.1.x 4.x > netty-all vulnerability: CVE-2022-41915 > --- > > Key: CASSANDRA-18147 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18147 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This is being reported by the OWASP scan. -- 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-18147) netty-all vulnerability: CVE-2022-41915
[ https://issues.apache.org/jira/browse/CASSANDRA-18147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18147: - Bug Category: Parent values: Security(12985) Complexity: Normal Component/s: Dependencies Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > netty-all vulnerability: CVE-2022-41915 > --- > > Key: CASSANDRA-18147 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18147 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This is being reported by the OWASP scan. -- 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-18147) netty-all vulnerability: CVE-2022-41915
[ https://issues.apache.org/jira/browse/CASSANDRA-18147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18147: - Description: This is being reported by the OWASP scan. > netty-all vulnerability: CVE-2022-41915 > --- > > Key: CASSANDRA-18147 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18147 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Priority: Normal > > This is being reported by the OWASP scan. -- 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] [Created] (CASSANDRA-18147) netty-all vulnerability
Brandon Williams created CASSANDRA-18147: Summary: netty-all vulnerability Key: CASSANDRA-18147 URL: https://issues.apache.org/jira/browse/CASSANDRA-18147 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams -- 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-18147) netty-all vulnerability: CVE-2022-41915
[ https://issues.apache.org/jira/browse/CASSANDRA-18147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18147: - Summary: netty-all vulnerability: CVE-2022-41915 (was: netty-all vulnerability) > netty-all vulnerability: CVE-2022-41915 > --- > > Key: CASSANDRA-18147 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18147 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Priority: Normal > -- 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-18146) commons-cli vulnerability: CVE-2021-37533
[ https://issues.apache.org/jira/browse/CASSANDRA-18146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18146: - Bug Category: Parent values: Security(12985) Complexity: Normal Component/s: Dependencies Discovered By: User Report Severity: Normal Assignee: Brandon Williams Status: Open (was: Triage Needed) > commons-cli vulnerability: CVE-2021-37533 > - > > Key: CASSANDRA-18146 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18146 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This CVE is being reported by the OWASP scan for: > commons-cli-1.1.jar: CVE-2021-37533 > commons-codec-1.9.jar: CVE-2021-37533 > commons-math3-3.2.jar: CVE-2021-37533 > additionally commons-lang3-3.1.jar is also reported on 3.x. -- 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-18146) commons-cli vulnerability: CVE-2021-37533
[ https://issues.apache.org/jira/browse/CASSANDRA-18146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18146: - Fix Version/s: 3.0.x 3.11.x 4.0.x 4.1.x 4.x > commons-cli vulnerability: CVE-2021-37533 > - > > Key: CASSANDRA-18146 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18146 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This CVE is being reported by the OWASP scan for: > commons-cli-1.1.jar: CVE-2021-37533 > commons-codec-1.9.jar: CVE-2021-37533 > commons-math3-3.2.jar: CVE-2021-37533 > additionally commons-lang3-3.1.jar is also reported on 3.x. -- 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-18146) commons-cli vulnerability: CVE-2021-37533
[ https://issues.apache.org/jira/browse/CASSANDRA-18146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675719#comment-17675719 ] Brandon Williams commented on CASSANDRA-18146: -- "Prior to Apache Commons Net 3.9.0, Net's FTP client trusts the host from PASV response by default." We don't use this and can suppress. > commons-cli vulnerability: CVE-2021-37533 > - > > Key: CASSANDRA-18146 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18146 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Priority: Normal > > This CVE is being reported by the OWASP scan for: > commons-cli-1.1.jar: CVE-2021-37533 > commons-codec-1.9.jar: CVE-2021-37533 > commons-math3-3.2.jar: CVE-2021-37533 > additionally commons-lang3-3.1.jar is also reported on 3.x. -- 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] [Created] (CASSANDRA-18146) commons-cli vulnerability: CVE-2021-37533
Brandon Williams created CASSANDRA-18146: Summary: commons-cli vulnerability: CVE-2021-37533 Key: CASSANDRA-18146 URL: https://issues.apache.org/jira/browse/CASSANDRA-18146 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams This CVE is being reported by the OWASP scan for: commons-cli-1.1.jar: CVE-2021-37533 commons-codec-1.9.jar: CVE-2021-37533 commons-math3-3.2.jar: CVE-2021-37533 additionally commons-lang3-3.1.jar is also reported on 3.x. -- 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] [Created] (CASSANDRA-18145) Run entire Cassandra Jenkins in an independent EC2/EKS account
Henrik Ingo created CASSANDRA-18145: --- Summary: Run entire Cassandra Jenkins in an independent EC2/EKS account Key: CASSANDRA-18145 URL: https://issues.apache.org/jira/browse/CASSANDRA-18145 Project: Cassandra Issue Type: Task Reporter: Henrik Ingo -- 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] [Comment Edited] (CASSANDRA-16325) Update streaming metrics incrementally
[
https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675685#comment-17675685
]
Isaac Reath edited comment on CASSANDRA-16325 at 1/11/23 8:10 PM:
--
This looks good to me. I left a comment about usage of {{bytesWritten}} in
{{CassandraEntireSSTableStreamWriter}}. I might be wrong about that usage so I
can look into it on my ticket.
edit: spoke with David offline to clear up my comment.
was (Author: isaacreath):
This looks good to me. I left a comment about usage of {{bytesWritten}} in
{{CassandraEntireSSTableStreamWriter}}. I might be wrong about that usage so I
can look into it on my ticket.
> Update streaming metrics incrementally
> --
>
> Key: CASSANDRA-16325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16325
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Paulo Motta
>Assignee: Isaac Reath
>Priority: Normal
> Labels: lhf
> Fix For: 4.2
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> Currently the inbound and outbound streamed bytes metrics are incremented
> after each file is streamed, what doesn't represent the current number of
> bytes streamed since it can take a long time for a large file to be streamed.
> We should update the metric incrementally as data is streamed.
--
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-18141) Cqlsh incorrectly formats duration
[
https://issues.apache.org/jira/browse/CASSANDRA-18141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675700#comment-17675700
]
Brandon Williams commented on CASSANDRA-18141:
--
[Here|https://app.circleci.com/pipelines/github/driftx/cassandra/747/workflows/4bfc6ac9-b698-4b5b-b3dd-5a7d4a8e6c96/jobs/9177]
you go.
> Cqlsh incorrectly formats duration
> --
>
> Key: CASSANDRA-18141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18141
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Maciej Sokol
>Assignee: Maciej Sokol
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like something broke between C* 3.11 and C* 4.X when it comes to
> duration types.
> Example:
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (email text,la_duration
> duration,PRIMARY KEY(email));
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s250ms);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', PT12H30M);
> 3.11:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 5.0.1 | Cassandra 3.11.15-SNAPSHOT | CQL spec 3.4.4 | Native protocol
> v4]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +
> te...@test.com | 12h
> te...@test.com | 12h30m30s250ms
> te...@test.com | 12h30m
> te...@test.com | 12h30m
> te...@test.com | 12h30m30s
> (5 rows)
> 4.X:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 6.0.0 | Cassandra 4.0.8-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +-
> te...@test.com | 12.0h
> te...@test.com | 12.5084028h30.5041666m30.25s250.0ms
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.508h30.5m30.0s
> (5 rows)
--
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] [Comment Edited] (CASSANDRA-18141) Cqlsh incorrectly formats duration
[
https://issues.apache.org/jira/browse/CASSANDRA-18141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675697#comment-17675697
]
Ekaterina Dimitrova edited comment on CASSANDRA-18141 at 1/11/23 7:47 PM:
--
Can we re-run {{j11_cqlsh_dtests_py38_vnode for 4.0, please? It seems there was
some environmental issue. The other SchemaTest failure doesn't seem related and
it was also just reported in CASSANDRA-17819.}}
{{I can review the code changes later today or tomorrow. }}
was (Author: e.dimitrova):
Can we re-run {{j11_cqlsh_dtests_py38_vnode for 4.0, please? It seems there was
some environmental issue. The other SchemaTest doesn't seem related and it was
also just reported in CASSANDRA-17819.}}
{{I can review the code changes later today or tomorrow. }}
> Cqlsh incorrectly formats duration
> --
>
> Key: CASSANDRA-18141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18141
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Maciej Sokol
>Assignee: Maciej Sokol
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like something broke between C* 3.11 and C* 4.X when it comes to
> duration types.
> Example:
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (email text,la_duration
> duration,PRIMARY KEY(email));
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s250ms);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', PT12H30M);
> 3.11:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 5.0.1 | Cassandra 3.11.15-SNAPSHOT | CQL spec 3.4.4 | Native protocol
> v4]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +
> te...@test.com | 12h
> te...@test.com | 12h30m30s250ms
> te...@test.com | 12h30m
> te...@test.com | 12h30m
> te...@test.com | 12h30m30s
> (5 rows)
> 4.X:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 6.0.0 | Cassandra 4.0.8-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +-
> te...@test.com | 12.0h
> te...@test.com | 12.5084028h30.5041666m30.25s250.0ms
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.508h30.5m30.0s
> (5 rows)
--
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-18141) Cqlsh incorrectly formats duration
[
https://issues.apache.org/jira/browse/CASSANDRA-18141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675697#comment-17675697
]
Ekaterina Dimitrova commented on CASSANDRA-18141:
-
Can we re-run {{j11_cqlsh_dtests_py38_vnode for 4.0, please? It seems there was
some environmental issue. The other SchemaTest doesn't seem related and it was
also just reported in CASSANDRA-17819.}}
{{I can review the code changes later today or tomorrow. }}
> Cqlsh incorrectly formats duration
> --
>
> Key: CASSANDRA-18141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18141
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Maciej Sokol
>Assignee: Maciej Sokol
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like something broke between C* 3.11 and C* 4.X when it comes to
> duration types.
> Example:
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (email text,la_duration
> duration,PRIMARY KEY(email));
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s250ms);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', PT12H30M);
> 3.11:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 5.0.1 | Cassandra 3.11.15-SNAPSHOT | CQL spec 3.4.4 | Native protocol
> v4]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +
> te...@test.com | 12h
> te...@test.com | 12h30m30s250ms
> te...@test.com | 12h30m
> te...@test.com | 12h30m
> te...@test.com | 12h30m30s
> (5 rows)
> 4.X:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 6.0.0 | Cassandra 4.0.8-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +-
> te...@test.com | 12.0h
> te...@test.com | 12.5084028h30.5041666m30.25s250.0ms
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.508h30.5m30.0s
> (5 rows)
--
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] [Comment Edited] (CASSANDRA-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
[
https://issues.apache.org/jira/browse/CASSANDRA-17819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675691#comment-17675691
]
Ekaterina Dimitrova edited comment on CASSANDRA-17819 at 1/11/23 7:41 PM:
--
Thanks [~bereng], as this ticket was closed In September 2022 I think it makes
sense to open new one and link it to this one {*}if related{*}.
Whether it is related - I don't know as:
1) At the time the patch was submitted tests were ran many times in a loop
2) I see your example is from trunk which is quite active now so it could be
something newly introduced.
was (Author: e.dimitrova):
Thanks [~bereng], as this ticket was closed In September 2022 I think it makes
sense to open new one and link it to this one if related.
Whether it is related - I don't know as:
1) At the time the patch was submitted tests were ran many times in a loop
2) I see your example is from trunk which is quite active now so it could be
something newly introduced.
> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.7, 4.1-beta1, 4.2
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> The test
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}},
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
> * 4.1:
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/134/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> * trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1265/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> {code:java}
> Error Message
> Condition with lambda expression in
> org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> Stacktrace
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
> at
> org.apache.cassandra.distributed.test.SchemaTest.schemaReset(SchemaTest.java:115)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-15 15:02:14,783 Reflections.java:219 -
> Reflections took 1873 ms to scan 8 urls, producing 1754 keys and 6912 values
> INFO [main] 2022-08-15 15:02:16,407 Reflections.java:219 -
> Reflections took 1561 ms to scan 8 urls, producing 1754 keys and 6912 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2022-08-15 15:02:17,554 InternalLoggerFactory.ja
> ...[truncated 1761288 chars]...
> cutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> INFO [node2_isolatedExecutor:3] node2 2022-08-15 15:03:52,096
> MessagingService.java:519 - Waiting for messaging service to quiesce
> {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] [Commented] (CASSANDRA-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
[
https://issues.apache.org/jira/browse/CASSANDRA-17819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675691#comment-17675691
]
Ekaterina Dimitrova commented on CASSANDRA-17819:
-
Thanks [~bereng], as this ticket was closed In September 2022 I think it makes
sense to open new one and link it to this one if related.
Whether it is related - I don't know as:
1) At the time the patch was submitted tests were ran many times in a loop
2) I see your example is from trunk which is quite active now so it could be
something newly introduced.
> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.7, 4.1-beta1, 4.2
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> The test
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}},
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
> * 4.1:
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/134/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> * trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1265/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> {code:java}
> Error Message
> Condition with lambda expression in
> org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> Stacktrace
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
> at
> org.apache.cassandra.distributed.test.SchemaTest.schemaReset(SchemaTest.java:115)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-15 15:02:14,783 Reflections.java:219 -
> Reflections took 1873 ms to scan 8 urls, producing 1754 keys and 6912 values
> INFO [main] 2022-08-15 15:02:16,407 Reflections.java:219 -
> Reflections took 1561 ms to scan 8 urls, producing 1754 keys and 6912 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2022-08-15 15:02:17,554 InternalLoggerFactory.ja
> ...[truncated 1761288 chars]...
> cutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> INFO [node2_isolatedExecutor:3] node2 2022-08-15 15:03:52,096
> MessagingService.java:519 - Waiting for messaging service to quiesce
> {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] [Comment Edited] (CASSANDRA-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675688#comment-17675688 ] Brandon Williams edited comment on CASSANDRA-18121 at 1/11/23 7:31 PM: --- The whole suite passes on a 2-core, 4G VM which should be equivalent to medium. There's no swap on the machine, both 3.8 and 3.11 have comparable memory usage, and the load doesn't even break 2.0. It's like there's a magic switch that makes circle performance tank without any discernible reason - GC is minimal. was (Author: brandon.williams): The whole suite passes on a 2-core, 4G VM which should be equivalent to medium. There's no swap on the machine, both 3.8 and 3.11 have comparable memory usage, and the load doesn't even break 2.0. It's there's a magic switch that makes circle performance tank without any discernible reason - GC is minimal. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675688#comment-17675688 ] Brandon Williams commented on CASSANDRA-18121: -- The whole suite passes on a 2-core, 4G VM which should be equivalent to medium. There's no swap on the machine, both 3.8 and 3.11 have comparable memory usage, and the load doesn't even break 2.0. It's there's a magic switch that makes circle performance tank without any discernible reason - GC is minimal. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-18139) Revert changes to units output in FileUtils#stringifyFileSize post CASSANDRA-15234
[ https://issues.apache.org/jira/browse/CASSANDRA-18139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18139: Bug Category: (was: Parent values: Correctness(12982)) > Revert changes to units output in FileUtils#stringifyFileSize post > CASSANDRA-15234 > -- > > Key: CASSANDRA-18139 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18139 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Priority: Normal > > As discussed in CASSANDRA-15234, FileUtils#stringifyFileSize is used in > nodetool output which can break people parsing the nodetool output -- 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-18139) Revert changes to units output in FileUtils#stringifyFileSize post CASSANDRA-15234
[ https://issues.apache.org/jira/browse/CASSANDRA-18139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18139: Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Component/s: Local/Config Discovered By: User Report Severity: Low Status: Open (was: Triage Needed) > Revert changes to units output in FileUtils#stringifyFileSize post > CASSANDRA-15234 > -- > > Key: CASSANDRA-18139 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18139 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Priority: Normal > > As discussed in CASSANDRA-15234, FileUtils#stringifyFileSize is used in > nodetool output which can break people parsing the nodetool output -- 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-18139) Revert changes to units output in FileUtils#stringifyFileSize post CASSANDRA-15234
[ https://issues.apache.org/jira/browse/CASSANDRA-18139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18139: Fix Version/s: 4.x > Revert changes to units output in FileUtils#stringifyFileSize post > CASSANDRA-15234 > -- > > Key: CASSANDRA-18139 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18139 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > As discussed in CASSANDRA-15234, FileUtils#stringifyFileSize is used in > nodetool output which can break people parsing the nodetool output -- 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-18114) Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
[
https://issues.apache.org/jira/browse/CASSANDRA-18114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18114:
Test and Documentation Plan: dead code removal, so just make sure there are
no regressions in existing tests
Status: Patch Available (was: In Progress)
|trunk|[patch|https://github.com/apache/cassandra/pull/2086]|[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-18114]|
> Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
> ---
>
> Key: CASSANDRA-18114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18114
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CollectionSerializer}} and its subclasses have completely ignored
> {{ProtocolVersion}} for a very long time. It’s possible we may need to
> version their behavior in the future, but there’s no reason to keep the dead
> code in the meantime, as it causes confusion around whether code that uses
> these classes needs to provide a version.
--
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-16325) Update streaming metrics incrementally
[
https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675685#comment-17675685
]
Isaac Reath commented on CASSANDRA-16325:
-
This looks good to me. I left a comment about usage of {{bytesWritten}} in
{{CassandraEntireSSTableStreamWriter}}. I might be wrong about that usage so I
can look into it on my ticket.
> Update streaming metrics incrementally
> --
>
> Key: CASSANDRA-16325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16325
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Paulo Motta
>Assignee: Isaac Reath
>Priority: Normal
> Labels: lhf
> Fix For: 4.2
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> Currently the inbound and outbound streamed bytes metrics are incremented
> after each file is streamed, what doesn't represent the current number of
> bytes streamed since it can take a long time for a large file to be streamed.
> We should update the metric incrementally as data is streamed.
--
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-12106) Add ability to blocklist / denylist a CQL partition so all requests are ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675682#comment-17675682 ] Josh McKenzie commented on CASSANDRA-12106: --- I'll defer to [~smiklosovic] as he has the PoC of it. > Add ability to blocklist / denylist a CQL partition so all requests are > ignored > --- > > Key: CASSANDRA-12106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12106 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Local Write-Read Paths, Local/Config >Reporter: Geoffrey Yu >Assignee: Josh McKenzie >Priority: Low > Fix For: 4.1-alpha1, 4.1 > > Attachments: 12106-trunk.txt > > > Sometimes reads/writes to a given partition may cause problems due to the > data present. It would be useful to have a manual way to blocklist / denylist > such partitions so all read and write requests to them are rejected. -- 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-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default cas
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-12525: - Summary: When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default cassandra/cassandra credentials (was: When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default cassandra/cassandra crendetials) > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra credentials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema, Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- 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] [Created] (CASSANDRA-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
David Capwell created CASSANDRA-18144:
-
Summary:
org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
fails when running with TrieMemtables
Key: CASSANDRA-18144
URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
Project: Cassandra
Issue Type: Bug
Components: CI
Reporter: David Capwell
https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
{code}
java.lang.RuntimeException: Error setting schema for test (query was: alter
table cql_test_keyspace.table_01 with compaction = {'class':
'SizeTieredCompactionStrategy', 'enabled': false})
at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
at
org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
Caused by: java.lang.ClassCastException:
org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
org.apache.cassandra.dht.Murmur3Partitioner$LongToken
at
org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
at
org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
at
org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
at
org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
at
org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
at
org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
at
org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
at
org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
at
org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
at
org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
at
org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
at
org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
at
org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
{code}
First reported to slack:
https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
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-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
[
https://issues.apache.org/jira/browse/CASSANDRA-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18144:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.x
Severity: Normal
Status: Open (was: Triage Needed)
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
> fails when running with TrieMemtables
> ---
>
> Key: CASSANDRA-18144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
> {code}
> java.lang.RuntimeException: Error setting schema for test (query was: alter
> table cql_test_keyspace.table_01 with compaction = {'class':
> 'SizeTieredCompactionStrategy', 'enabled': false})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
> at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken
> at
> org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
> at
> org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
> at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
> at
> org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
> at
> org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
> at
> org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
> at
> org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
> {code}
> First reported to slack:
> https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
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-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default cas
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-12525: - Reviewers: Brandon Williams, Stefan Miklosovic (was: Stefan Miklosovic) > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema, Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- 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-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default c
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675681#comment-17675681 ] Brandon Williams commented on CASSANDRA-12525: -- LGTM, I think we just need to run CI. > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema, Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- 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-18027) Use G1GC as default
[ https://issues.apache.org/jira/browse/CASSANDRA-18027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-18027: -- Priority: High (was: Normal) > Use G1GC as default > --- > > Key: CASSANDRA-18027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18027 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 4.1.x, 4.x > > > G1GC is well battle tested now, and the recommended configuration for most > users. CMS can work well on smaller heaps but requires more tuning, initially > and over time. G1GC just works. CMS was deprecated in JDK 9. > Patch at > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/7486/trunk -- 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-18130) Log hardware and container params during test runs to help troubleshoot intermittent failures
[
https://issues.apache.org/jira/browse/CASSANDRA-18130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675680#comment-17675680
]
Josh McKenzie commented on CASSANDRA-18130:
---
bq. Yes, but it's not big enough to handle a pipeline build. Let me loop back
on this later in the week, ok?
Certainly; this is going to depend on progress on CASSANDRA-17869 for the
pipeline integration so best to keep focus there.
> Log hardware and container params during test runs to help troubleshoot
> intermittent failures
> -
>
> Key: CASSANDRA-18130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18130
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java, Test/dtest/python, Test/unit
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> {color:#00}We’ve long had flakiness in our containerized ASF CI
> environment that we don’t see in circleci. The environment itself is both
> containerized and heterogenous, so there are differences in both the hardware
> environment and the software environment in which it executes. For reference,
> see:
> [https://github.com/apache/cassandra-builds/blob/trunk/ASF-jenkins-agents.md#current-agents]{color}
> {color:#00} {color}
> {color:#00}We should log a variety of hardware, container, and software
> environment details to help get to the bottom of where some test failures may
> be occurring. As we don’t have shell access to the machines it’ll be easier
> to have this information logged / retrieved during test runs than to try and
> profile each host independently.{color}
--
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-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default c
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675678#comment-17675678 ] German Eichberger commented on CASSANDRA-12525: --- [~smiklosovic] this looks great - especially the use of the cql client. > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema, Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- 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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675668#comment-17675668 ] Andres de la Peña commented on CASSANDRA-14361: --- Sure, I'm taking a look. As for the mockito-inline dependency, I think we need dev list approval for any new dependencies. > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ben Bromhead >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 4.x > > Time Spent: 1h > Remaining Estimate: 0h > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- 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
[cassandra-accord] branch trunk updated: Refactor Timestamp/TxnId (#22)
This is an automated email from the ASF dual-hosted git repository.
benedict pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git
The following commit(s) were added to refs/heads/trunk by this push:
new bf414d3 Refactor Timestamp/TxnId (#22)
bf414d3 is described below
commit bf414d39ea495f8914f7cb5fb5c4138a9c16760b
Author: Benedict Elliott Smith
AuthorDate: Wed Jan 11 18:05:22 2023 +
Refactor Timestamp/TxnId (#22)
- Combine real and logical into a single 64-bit HLC
- Introduce 16 flag bits
- Pack epoch (48-bits), HLC (64-bits) and flags (16-bits) into two longs in
memory
---
.../src/main/java/accord/coordinate/CheckOn.java | 8 +-
.../main/java/accord/coordinate/CheckShards.java | 4 +-
.../main/java/accord/coordinate/Coordinate.java| 10 +-
.../src/main/java/accord/coordinate/Execute.java | 14 +-
.../src/main/java/accord/coordinate/FetchData.java | 8 +-
.../main/java/accord/coordinate/FindHomeKey.java | 2 +-
.../src/main/java/accord/coordinate/FindRoute.java | 2 +-
.../java/accord/coordinate/InformHomeOfTxn.java| 4 +-
.../main/java/accord/coordinate/Invalidate.java| 4 +-
.../main/java/accord/coordinate/MaybeRecover.java | 2 +-
.../src/main/java/accord/coordinate/Persist.java | 16 +-
.../src/main/java/accord/coordinate/Propose.java | 2 +-
.../src/main/java/accord/coordinate/Recover.java | 16 +-
.../java/accord/coordinate/RecoverWithHomeKey.java | 2 +-
.../java/accord/coordinate/RecoverWithRoute.java | 12 +-
.../src/main/java/accord/impl/InMemoryCommand.java | 14 --
.../java/accord/impl/InMemoryCommandStore.java | 15 +-
.../java/accord/impl/InMemoryCommandsForKey.java | 5 +-
.../main/java/accord/impl/SimpleProgressLog.java | 12 +-
.../src/main/java/accord/local/Command.java| 23 +--
accord-core/src/main/java/accord/local/Node.java | 39 +++--
.../src/main/java/accord/messages/Accept.java | 8 +-
.../src/main/java/accord/messages/Apply.java | 6 +-
.../java/accord/messages/BeginInvalidation.java| 5 +-
.../main/java/accord/messages/BeginRecovery.java | 6 +-
.../src/main/java/accord/messages/Commit.java | 20 +--
.../src/main/java/accord/messages/GetDeps.java | 4 +-
.../main/java/accord/messages/InformDurable.java | 4 +-
.../java/accord/messages/InformHomeDurable.java| 2 +-
.../main/java/accord/messages/InformOfTxnId.java | 7 +-
.../src/main/java/accord/messages/PreAccept.java | 2 +-
.../src/main/java/accord/messages/ReadData.java| 2 +-
.../src/main/java/accord/messages/TxnRequest.java | 12 +-
.../main/java/accord/messages/WaitOnCommit.java| 4 +-
.../main/java/accord/primitives/AbstractKeys.java | 4 +-
.../java/accord/primitives/AbstractRanges.java | 4 +-
.../src/main/java/accord/primitives/Ballot.java| 29 +++-
.../src/main/java/accord/primitives/Range.java | 2 +-
.../src/main/java/accord/primitives/Routable.java | 24 ++-
.../main/java/accord/primitives/RoutableKey.java | 2 +-
.../src/main/java/accord/primitives/Routables.java | 2 +-
.../src/main/java/accord/primitives/Timestamp.java | 182 ++---
.../src/main/java/accord/primitives/Txn.java | 24 ++-
.../src/main/java/accord/primitives/TxnId.java | 98 ++-
.../src/main/java/accord/primitives/Writes.java| 2 +-
.../main/java/accord/topology/TopologyManager.java | 4 +-
.../src/test/java/accord/burn/TopologyUpdates.java | 4 +-
.../java/accord/coordinate/CoordinateTest.java | 10 +-
.../java/accord/coordinate/TopologyChangeTest.java | 21 +--
.../src/test/java/accord/impl/TestAgent.java | 2 +-
.../src/test/java/accord/impl/list/ListAgent.java | 2 +-
.../test/java/accord/impl/list/ListRequest.java| 3 +-
.../test/java/accord/impl/mock/MockCluster.java| 6 +-
.../src/test/java/accord/local/CommandTest.java| 6 +-
.../src/test/java/accord/local/NodeTest.java | 31 ++--
.../test/java/accord/messages/PreAcceptTest.java | 18 +-
accord-core/src/test/java/accord/txn/DepsTest.java | 43 +++--
.../src/main/java/accord/maelstrom/Json.java | 20 +--
.../main/java/accord/maelstrom/MaelstromAgent.java | 2 +-
59 files changed, 550 insertions(+), 291 deletions(-)
diff --git a/accord-core/src/main/java/accord/coordinate/CheckOn.java
b/accord-core/src/main/java/accord/coordinate/CheckOn.java
index d37a827..a7ec61f 100644
--- a/accord-core/src/main/java/accord/coordinate/CheckOn.java
+++ b/accord-core/src/main/java/accord/coordinate/CheckOn.java
@@ -136,7 +136,7 @@ public class CheckOn extends CheckShards
public OnDone()
{
-Ranges localRanges =
node.topology().localRangesForEpochs(txnId.epoch, untilLocalEpoch);
+Ranges localRanges =
node.topology().localRangesForEpochs(txnId.epoch(), untilLocalEpoch);
PartialRoute selfRoute
[jira] [Updated] (CASSANDRA-18114) Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
[
https://issues.apache.org/jira/browse/CASSANDRA-18114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18114:
Fix Version/s: 4.2
(was: 5.x)
> Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
> ---
>
> Key: CASSANDRA-18114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18114
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.2
>
>
> {{CollectionSerializer}} and its subclasses have completely ignored
> {{ProtocolVersion}} for a very long time. It’s possible we may need to
> version their behavior in the future, but there’s no reason to keep the dead
> code in the meantime, as it causes confusion around whether code that uses
> these classes needs to provide a version.
--
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-18139) Revert changes to units output in FileUtils#stringifyFileSize post CASSANDRA-15234
[ https://issues.apache.org/jira/browse/CASSANDRA-18139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675650#comment-17675650 ] Caleb Rackliffe commented on CASSANDRA-18139: - bq. On the other hand flag or not we will break those people in a patch release. Not sure how many are those with new clusters using already that output though My two cents...probably few enough for it not to be an issue. +1 for a flag to opt-in to the new behavior > Revert changes to units output in FileUtils#stringifyFileSize post > CASSANDRA-15234 > -- > > Key: CASSANDRA-18139 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18139 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Priority: Normal > > As discussed in CASSANDRA-15234, FileUtils#stringifyFileSize is used in > nodetool output which can break people parsing the nodetool output -- 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-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default c
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675633#comment-17675633 ] Stefan Miklosovic commented on CASSANDRA-12525: --- [~xgerman42] please find the patch here: https://github.com/apache/cassandra/pull/2085/files I took what you did and finished the test, also all changes are squashed into one commit. Please go through it and verify my logic is correct. We might then ask for the second review. > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema, Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- 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-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17507:
--
Fix Version/s: 4.1.x
4.x
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:69)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:352)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:400)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:244)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:723)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:701)
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:159)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:86)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:106)
> at
> org.apache.cassandra.transport.Dispatcher.lambda$dispatch$0(Dispatcher.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> 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.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17507:
--
Test and Documentation Plan: New JVM upgrade dtests are included.
Status: Patch Available (was: Open)
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:69)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:352)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:400)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:244)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:723)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:701)
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:159)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:86)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:106)
> at
> org.apache.cassandra.transport.Dispatcher.lambda$dispatch$0(Dispatcher.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> 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.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675629#comment-17675629
]
Andres de la Peña edited comment on CASSANDRA-17507 at 1/11/23 3:48 PM:
I can confirm that 4.1 and trunk are also affected. Here are the patches for
all the branches:
||PR||CI||
|[4.0|https://github.com/apache/cassandra/pull/2082]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2543/workflows/cb16ec9d-8ec6-4914-a08a-92715bd15ff0]|
|[4.1|https://github.com/apache/cassandra/pull/2083]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2544/workflows/924c41ce-accb-44eb-be07-1fc678b1f4b2]|
|[trunk|https://github.com/apache/cassandra/pull/2084]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2542/workflows/16be8e22-b8d1-440f-93bd-a599b56e3093]|
I think that CI will fail for the new tests on the [4.0, 4.1] -> [4.1, trunk]
upgrade paths. That's because our CI script [generates the dtest artifacts from
the main
repo|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L2684-L2693],
and the branches there don't contain the serialization fix that we are
proposing here.
Reviewers can test it locally by generating the dtests artifacts of each
patched branch with {{{}ant dtest-jar{}}}, and copying all the generated
{{dtest-*.jar}} files into the {{build}} directory of the tested branch.
was (Author: adelapena):
I can confirm that 4.1 and trunk are also affected. Here are the patches for
all the branches:
||PR||CI||
|[4.0|https://github.com/apache/cassandra/pull/2082]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2543/workflows/cb16ec9d-8ec6-4914-a08a-92715bd15ff0]|
|[4.1|https://github.com/apache/cassandra/pull/2083]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2544/workflows/924c41ce-accb-44eb-be07-1fc678b1f4b2]|
|[trunk|https://github.com/apache/cassandra/pull/2084]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2542/workflows/16be8e22-b8d1-440f-93bd-a599b56e3093]|
I think that CI will fail for the new tests on the [4.0, 4.1] -> [4.1, trunk]
upgrade paths. That's because our CI scripts generates the dtest artifacts from
the main repo, and the branches there don't contain the serialization fix that
we are proposing here.
Reviewers can test it locally by generating the dtests artifacts of each
patched branch with {{{}ant dtest-jar{}}}, and copying all the generated
{{dtest-*.jar}} files into the {{build}} directory of the tested branch.
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
>
[jira] [Commented] (CASSANDRA-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675629#comment-17675629
]
Andres de la Peña commented on CASSANDRA-17507:
---
I can confirm that 4.1 and trunk are also affected. Here are the patches for
all the branches:
||PR||CI||
|[4.0|https://github.com/apache/cassandra/pull/2082]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2543/workflows/cb16ec9d-8ec6-4914-a08a-92715bd15ff0]|
|[4.1|https://github.com/apache/cassandra/pull/2083]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2544/workflows/924c41ce-accb-44eb-be07-1fc678b1f4b2]|
|[trunk|https://github.com/apache/cassandra/pull/2084]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2542/workflows/16be8e22-b8d1-440f-93bd-a599b56e3093]|
I think that CI will fail for the new tests on the [4.0, 4.1] -> [4.1, trunk]
upgrade paths. That's because our CI scripts generates the dtest artifacts from
the main repo, and the branches there don't contain the serialization fix that
we are proposing here.
Reviewers can test it locally by generating the dtests artifacts of each
patched branch with {{{}ant dtest-jar{}}}, and copying all the generated
{{dtest-*.jar}} files into the {{build}} directory of the tested branch.
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:69)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:352)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:400)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:244)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:723)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:701)
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:159)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
> at
>
[jira] [Comment Edited] (CASSANDRA-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675575#comment-17675575
]
Andres de la Peña edited comment on CASSANDRA-17507 at 1/11/23 1:55 PM:
I think I have found the cause of the bug when using protocol v3.
Cassandra 3.0 and 3.x with protocol v3 and compact storage don't serialize
single-column clusterings as single-element composites. Instead, single-column
clusterings values are written as they are, as it can be seen
[here|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/LegacyLayout.java#L477-L486].
However, Cassandra 4.0 always reads and writes single-column clusterings as
composites. This can be seen
[here|https://github.com/apache/cassandra/blob/cassandra-4.0.3/src/java/org/apache/cassandra/service/pager/PagingState.java#L434],
exactly where the reported exception is thrown.
I think the solution is modifying the code to read legacy formats in Cassandra
4.0 so it special cases single-column clusterings for compact storage:
||PR||CI||
|[4.0|https://github.com/apache/cassandra/pull/2082]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2540/workflows/22cfa989-31df-4fcc-a896-f46c8d77d364]|
If the approach looks good I'll prepare patches for 4.1 and trunk, that
probably are also affected.
was (Author: adelapena):
I think I have found the cause of the bug when using protocol v3.
Cassandra 3.0 and 3.x with protocol v3 and compact storage doesn't serialize
single-column clusterings as single-element composites. Instead, single-column
clusterings values are written as they are, as it can be seen
[here|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/LegacyLayout.java#L477-L486].
However, Cassandra 4.0 always reads clusterings as composites. This can be
seen
[here|https://github.com/apache/cassandra/blob/cassandra-4.0.3/src/java/org/apache/cassandra/service/pager/PagingState.java#L434],
exactly where the reported exception is thrown.
I think the solution is modifying the code to read legacy formats in Cassandra
4.0 so it special cases single-column clusterings for compact storage:
||PR||CI||
|[4.0|https://github.com/apache/cassandra/pull/2082]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2540/workflows/22cfa989-31df-4fcc-a896-f46c8d77d364]|
If the approach looks good I'll prepare patches for 4.1 and trunk, that
probably are also affected.
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
>
[jira] [Commented] (CASSANDRA-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675579#comment-17675579
]
Andres de la Peña commented on CASSANDRA-18032:
---
+1
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {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
