[jira] [Updated] (CASSANDRA-18948) Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18948:
Fix Version/s: 4.0.12
4.1.4
5.0-beta1
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0-rc)
Since Version: 4.0
Source Control Link:
https://github.com/apache/cassandra/commit/3ba6de70c74c842d0104dbd2dcef41c857198314
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Test failure:
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
>
> ---
>
> Key: CASSANDRA-18948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18948
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.12, 4.1.4, 5.0-beta1, 5.x
>
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/71/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testReplayLogic_compression_jdk17_arch_x86_64_python2_7/
> h3.
> {code:java}
> Error Message
> Missing old CDCIndexData in new set after replay:
> CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData in new set of
> indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214
> Stacktrace
> junit.framework.AssertionFailedError: Missing old CDCIndexData in new set
> after replay: CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData
> in new set of indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214 at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic(CommitLogSegmentManagerCDCTest.java:319)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {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-18948) Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18948:
Reviewers: Andres de la Peña (was: Andres de la Peña, Berenguer Blasi)
> Test failure:
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
>
> ---
>
> Key: CASSANDRA-18948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18948
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc, 5.x
>
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/71/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testReplayLogic_compression_jdk17_arch_x86_64_python2_7/
> h3.
> {code:java}
> Error Message
> Missing old CDCIndexData in new set after replay:
> CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData in new set of
> indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214
> Stacktrace
> junit.framework.AssertionFailedError: Missing old CDCIndexData in new set
> after replay: CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData
> in new set of indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214 at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic(CommitLogSegmentManagerCDCTest.java:319)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {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-18948) Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18948:
Status: Ready to Commit (was: Review In Progress)
> Test failure:
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
>
> ---
>
> Key: CASSANDRA-18948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18948
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc, 5.x
>
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/71/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testReplayLogic_compression_jdk17_arch_x86_64_python2_7/
> h3.
> {code:java}
> Error Message
> Missing old CDCIndexData in new set after replay:
> CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData in new set of
> indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214
> Stacktrace
> junit.framework.AssertionFailedError: Missing old CDCIndexData in new set
> after replay: CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData
> in new set of indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214 at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic(CommitLogSegmentManagerCDCTest.java:319)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {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-18948) Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18948:
Reviewers: Andres de la Peña, Berenguer Blasi (was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> Test failure:
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
>
> ---
>
> Key: CASSANDRA-18948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18948
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc, 5.x
>
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/71/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testReplayLogic_compression_jdk17_arch_x86_64_python2_7/
> h3.
> {code:java}
> Error Message
> Missing old CDCIndexData in new set after replay:
> CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData in new set of
> indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214
> Stacktrace
> junit.framework.AssertionFailedError: Missing old CDCIndexData in new set
> after replay: CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData
> in new set of indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214 at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic(CommitLogSegmentManagerCDCTest.java:319)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {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 (5c44922a5a -> 6cac24f581)
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 5c44922a5a Merge branch 'cassandra-4.0' into cassandra-4.1 new 3ba6de70c7 Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest new 6cac24f581 Merge branch 'cassandra-4.0' into cassandra-4.1 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: .../cassandra/db/commitlog/CommitLogSegment.java | 2 +- .../commitlog/CommitLogSegmentManagerCDCTest.java | 54 -- 2 files changed, 30 insertions(+), 26 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-5.0' 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 4083166870d115cb76247722ebe1166f20649715
Merge: ed5a224283 f48de8343c
Author: Bereng
AuthorDate: Mon Nov 20 07:38:31 2023 +0100
Merge branch 'cassandra-5.0' into trunk
* cassandra-5.0:
Test failure:
org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest
.../cassandra/db/commitlog/CommitLogSegment.java | 2 +-
.../commitlog/CommitLogSegmentManagerCDCTest.java | 54 --
2 files changed, 30 insertions(+), 26 deletions(-)
diff --cc src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
index 04a2c2c336,04a2c2c336..7a346acfd6
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
@@@ -61,7 -61,7 +61,7 @@@ public abstract class CommitLogSegmen
{
private final static long idBase;
--private CDCState cdcState = CDCState.PERMITTED;
++private volatile CDCState cdcState = CDCState.PERMITTED;
public enum CDCState
{
PERMITTED,
diff --cc
test/unit/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDCTest.java
index e964efa2d8,e964efa2d8..6fe3d0743b
---
a/test/unit/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDCTest.java
+++
b/test/unit/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDCTest.java
@@@ -42,7 -42,7 +42,6 @@@ import org.apache.cassandra.db.Keyspace
import org.apache.cassandra.db.RowUpdateBuilder;
import org.apache.cassandra.db.commitlog.CommitLogSegment.CDCState;
import org.apache.cassandra.exceptions.CDCWriteException;
--import org.apache.cassandra.io.util.FileUtils;
import org.apache.cassandra.schema.TableMetadata;
public class CommitLogSegmentManagerCDCTest extends CQLTester
@@@ -87,11 -87,11 +86,10 @@@
.forceBlockingFlush(ColumnFamilyStore.FlushReason.UNIT_TESTS);
CommitLog.instance.forceRecycleAllSegments();
cdcMgr.awaitManagementTasksCompletion();
--Assert.assertTrue("Expected files to be moved to overflow.",
getCDCRawCount() > 0);
++Assert.assertTrue("Expected files to be moved to overflow.",
getCDCRawFiles().length > 0);
// Simulate a CDC consumer reading files then deleting them
--for (File f : new
File(DatabaseDescriptor.getCDCLogLocation()).tryList())
--FileUtils.deleteWithConfirm(f);
++deleteCDCRawFiles();
// Update size tracker to reflect deleted files. Should flip flag
on current allocatingFrom to allow.
cdcMgr.updateCDCTotalSize();
@@@ -204,7 -204,7 +202,7 @@@
BufferedReader in = new BufferedReader(new FileReader(cdcIndexFile));
String input = in.readLine();
input = in.readLine();
--Assert.assertTrue("Expected COMPLETED in index file, got: " + input,
input.equals("COMPLETED"));
++Assert.assertEquals("Expected COMPLETED in index file, got: " +
input, "COMPLETED", input);
in.close();
}
@@@ -272,13 -272,13 +270,12 @@@
// Build up a list of expected index files after replay and then
clear out cdc_raw
List oldData = parseCDCIndexData();
--for (File f : new
File(DatabaseDescriptor.getCDCLogLocation()).tryList())
--FileUtils.deleteWithConfirm(f.absolutePath());
++deleteCDCRawFiles();
try
{
Assert.assertEquals("Expected 0 files in CDC folder after
deletion. ",
--0, new
File(DatabaseDescriptor.getCDCLogLocation()).tryList().length);
++0, getCDCRawFiles().length);
}
finally
{
@@@ -293,7 -293,7 +290,7 @@@
// Rough sanity check -> should be files there now.
Assert.assertTrue("Expected non-zero number of files in CDC folder
after restart.",
-- new
File(DatabaseDescriptor.getCDCLogLocation()).tryList().length > 0);
++ getCDCRawFiles().length > 0);
// Confirm all the old indexes in old are present and >= the original
offset, as we flag the entire segment
// as cdc written on a replay.
@@@ -307,6 -307,6 +304,7 @@@
{
Assert.assertTrue("New CDC index file expected to have >=
offset in old.", ncid.offset >= cid.offset);
found = true;
++break;
}
}
if (!found)
@@@ -327,7 -327,7 +325,10 @@@
for (CDCIndexData cid : oldData)
{
if (cid.fileName.equals(ncid.fileName))
++{
found = true;
++break;
++}
}
if (!found)
(cassandra) branch trunk updated (ed5a224283 -> 4083166870)
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 ed5a224283 Merge branch 'cassandra-5.0' into trunk new 3ba6de70c7 Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest new 6cac24f581 Merge branch 'cassandra-4.0' into cassandra-4.1 new f48de8343c Merge branch 'cassandra-4.1' into cassandra-5.0 new 4083166870 Merge branch 'cassandra-5.0' 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/commitlog/CommitLogSegment.java | 2 +- .../commitlog/CommitLogSegmentManagerCDCTest.java | 54 -- 2 files changed, 30 insertions(+), 26 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 6cac24f581e9f6b719f3c0f9bc5c9df2e03c682a
Merge: 5c44922a5a 3ba6de70c7
Author: Bereng
AuthorDate: Mon Nov 20 07:35:51 2023 +0100
Merge branch 'cassandra-4.0' into cassandra-4.1
* cassandra-4.0:
Test failure:
org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest
.../cassandra/db/commitlog/CommitLogSegment.java | 2 +-
.../commitlog/CommitLogSegmentManagerCDCTest.java | 54 --
2 files changed, 30 insertions(+), 26 deletions(-)
diff --cc
test/unit/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDCTest.java
index 3789b51714,21962c8b7b..9ad386ecbe
---
a/test/unit/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDCTest.java
+++
b/test/unit/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDCTest.java
@@@ -78,17 -94,13 +77,16 @@@ public class CommitLogSegmentManagerCDC
execute("INSERT INTO %s (idx, data) VALUES (1, '1');");
// Confirm that, on flush+recyle, we see files show up in cdc_raw
-
Keyspace.open(keyspace()).getColumnFamilyStore(currentTable()).forceBlockingFlush();
+CommitLogSegmentManagerCDC cdcMgr =
(CommitLogSegmentManagerCDC)CommitLog.instance.segmentManager;
+Keyspace.open(keyspace())
+.getColumnFamilyStore(currentTable())
+
.forceBlockingFlush(ColumnFamilyStore.FlushReason.UNIT_TESTS);
CommitLog.instance.forceRecycleAllSegments();
cdcMgr.awaitManagementTasksCompletion();
- Assert.assertTrue("Expected files to be moved to overflow.",
getCDCRawCount() > 0);
+ Assert.assertTrue("Expected files to be moved to overflow.",
getCDCRawFiles().length > 0);
// Simulate a CDC consumer reading files then deleting them
- for (File f : new
File(DatabaseDescriptor.getCDCLogLocation()).tryList())
- FileUtils.deleteWithConfirm(f);
+ deleteCDCRawFiles();
// Update size tracker to reflect deleted files. Should flip flag
on current allocatingFrom to allow.
cdcMgr.updateCDCTotalSize();
@@@ -336,9 -375,9 +337,9 @@@
List results = new ArrayList<>();
try
{
- for (File f : new
File(DatabaseDescriptor.getCDCLogLocation()).tryList())
+ for (File f : getCDCRawFiles())
{
-if (f.getName().contains("_cdc.idx"))
+if (f.name().contains("_cdc.idx"))
results.add(new CDCIndexData(f));
}
}
@@@ -356,16 -395,13 +357,12 @@@
CDCIndexData(File f) throws IOException
{
- String line = "";
+ String line;
-try (BufferedReader br = new BufferedReader(new
InputStreamReader(new FileInputStream(f
+try (BufferedReader br = new BufferedReader(new FileReader(f)))
{
line = br.readLine();
}
- catch (Exception e)
- {
- throw e;
- }
-
-fileName = f.getName();
+fileName = f.name();
offset = Integer.parseInt(line);
}
@@@ -407,107 -440,16 +401,117 @@@
}
}
+private void testWithNonblockingMode(Testable test) throws Throwable
+{
+boolean original = DatabaseDescriptor.getCDCBlockWrites();
+CommitLog.instance.setCDCBlockWrites(false);
+try
+{
+test.run();
+}
+finally
+{
+CommitLog.instance.setCDCBlockWrites(original);
+}
+}
+
+private void testWithCDCSpaceInMb(int size, Testable test) throws
Throwable
+{
+int origSize = (int) DatabaseDescriptor.getCDCTotalSpace() / 1024 /
1024;
+DatabaseDescriptor.setCDCTotalSpaceInMiB(size);
+try
+{
+test.run();
+}
+finally
+{
+DatabaseDescriptor.setCDCTotalSpaceInMiB(origSize);
+}
+}
+
+private String createTableAndBulkWrite() throws Throwable
+{
+return
createTableAndBulkWrite(DatabaseDescriptor.getCommitLogSegmentSize() / 3);
+}
+
+private String createTableAndBulkWrite(int mutationSize) throws Throwable
+{
+String tableName = createTable("CREATE TABLE %s (idx int, data text,
primary key(idx)) WITH cdc=true;");
+bulkWrite(tableName, mutationSize);
+return tableName;
+}
+
+private void bulkWrite(String tableName) throws Throwable
+{
+bulkWrite(tableName, DatabaseDescriptor.getCommitLogSegmentSize() /
3);
+}
+
+private void bulkWrite(String tableName, int mutationSize) throws
Throwable
(cassandra) 01/01: Merge branch 'cassandra-4.1' into cassandra-5.0
This is an automated email from the ASF dual-hosted git repository. bereng pushed a commit to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit f48de8343cd8be5ba6ba970251ddb8520b489611 Merge: b7b2aa5de5 6cac24f581 Author: Bereng AuthorDate: Mon Nov 20 07:37:14 2023 +0100 Merge branch 'cassandra-4.1' into cassandra-5.0 * cassandra-4.1: Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest - 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: Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest
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
The following commit(s) were added to refs/heads/cassandra-4.0 by this push:
new 3ba6de70c7 Test failure:
org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest
3ba6de70c7 is described below
commit 3ba6de70c74c842d0104dbd2dcef41c857198314
Author: Bereng
AuthorDate: Fri Nov 17 09:09:00 2023 +0100
Test failure:
org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest
patch by Berenguer Blasi; reviewed by Andres de la Peña for CASSANDRA-18948
---
.../cassandra/db/commitlog/CommitLogSegment.java | 2 +-
.../commitlog/CommitLogSegmentManagerCDCTest.java | 67 --
2 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
index 64b815e3de..c46cc629d0 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
@@ -59,7 +59,7 @@ public abstract class CommitLogSegment
{
private final static long idBase;
-private CDCState cdcState = CDCState.PERMITTED;
+private volatile CDCState cdcState = CDCState.PERMITTED;
public enum CDCState
{
PERMITTED,
diff --git
a/test/unit/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDCTest.java
b/test/unit/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDCTest.java
index 4128b7122e..21962c8b7b 100644
---
a/test/unit/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDCTest.java
+++
b/test/unit/org/apache/cassandra/db/commitlog/CommitLogSegmentManagerCDCTest.java
@@ -35,7 +35,6 @@ import org.apache.cassandra.db.Keyspace;
import org.apache.cassandra.db.RowUpdateBuilder;
import org.apache.cassandra.db.commitlog.CommitLogSegment.CDCState;
import org.apache.cassandra.exceptions.CDCWriteException;
-import org.apache.cassandra.io.util.FileUtils;
import org.apache.cassandra.schema.TableMetadata;
public class CommitLogSegmentManagerCDCTest extends CQLTester
@@ -68,7 +67,7 @@ public class CommitLogSegmentManagerCDCTest extends CQLTester
TableMetadata cfm = currentTableMetadata();
// Confirm that logic to check for whether or not we can allocate new
CDC segments works
-Integer originalCDCSize = DatabaseDescriptor.getCDCSpaceInMB();
+int originalCDCSize = DatabaseDescriptor.getCDCSpaceInMB();
try
{
DatabaseDescriptor.setCDCSpaceInMB(32);
@@ -98,11 +97,10 @@ public class CommitLogSegmentManagerCDCTest extends
CQLTester
Keyspace.open(keyspace()).getColumnFamilyStore(currentTable()).forceBlockingFlush();
CommitLog.instance.forceRecycleAllSegments();
cdcMgr.awaitManagementTasksCompletion();
-Assert.assertTrue("Expected files to be moved to overflow.",
getCDCRawCount() > 0);
+Assert.assertTrue("Expected files to be moved to overflow.",
getCDCRawFiles().length > 0);
// Simulate a CDC consumer reading files then deleting them
-for (File f : new
File(DatabaseDescriptor.getCDCLogLocation()).listFiles())
-FileUtils.deleteWithConfirm(f);
+deleteCDCRawFiles();
// Update size tracker to reflect deleted files. Should flip flag
on current allocatingFrom to allow.
cdcMgr.updateCDCTotalSize();
@@ -115,7 +113,7 @@ public class CommitLogSegmentManagerCDCTest extends
CQLTester
}
@Test
-public void testSegmentFlaggingOnCreation() throws Throwable
+public void testSegmentFlaggingOnCreation()
{
CommitLogSegmentManagerCDC cdcMgr =
(CommitLogSegmentManagerCDC)CommitLog.instance.segmentManager;
String ct = createTable("CREATE TABLE %s (idx int, data text, primary
key(idx)) WITH cdc=true;");
@@ -143,16 +141,13 @@ public class CommitLogSegmentManagerCDCTest extends
CQLTester
cdcMgr.awaitManagementTasksCompletion();
// Delete all files in cdc_raw
-for (File f : new
File(DatabaseDescriptor.getCDCLogLocation()).listFiles())
-f.delete();
+deleteCDCRawFiles();
cdcMgr.updateCDCTotalSize();
// Confirm cdc update process changes flag on active segment
expectCurrentCDCState(CDCState.PERMITTED);
// Clear out archived CDC files
-for (File f : new
File(DatabaseDescriptor.getCDCLogLocation()).listFiles()) {
-FileUtils.deleteWithConfirm(f);
-}
+deleteCDCRawFiles();
}
finally
{
@@ -179,8 +174,8 @@ public class CommitLogSegmentManagerCDCTest extends
CQLTester
// Read index value and confirm it's == end from last sync
(cassandra) branch cassandra-5.0 updated (b7b2aa5de5 -> f48de8343c)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from b7b2aa5de5 Fix DiskSpaceMetricsTest.testFlushSize new 3ba6de70c7 Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest new 6cac24f581 Merge branch 'cassandra-4.0' into cassandra-4.1 new f48de8343c Merge branch 'cassandra-4.1' into cassandra-5.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: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19002) Create / update tests to ensure commit logs and hints for all versions in MS are ingestible in 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787820#comment-17787820 ] Berenguer Blasi commented on CASSANDRA-19002: - Thx! ^ > Create / update tests to ensure commit logs and hints for all versions in MS > are ingestible in 5.0 > -- > > Key: CASSANDRA-19002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19002 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta1, 5.0, 5.1 > > Attachments: signature.asc, signature.asc > > Time Spent: 3h 20m > Remaining Estimate: 0h > > This is follow up of CASSANDRA-18314 -- 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-18926) SAI in-memory index does not include maximum term size check when adding terms
[
https://issues.apache.org/jira/browse/CASSANDRA-18926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787796#comment-17787796
]
Zhao Yang commented on CASSANDRA-18926:
---
The patch LGTM, thank you!
> SAI in-memory index does not include maximum term size check when adding terms
> --
>
> Key: CASSANDRA-18926
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18926
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Mike Adamson
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{SSTableIndexWriter}} rejects terms that exceed a maximum term size with
> a no-spam warning, but the {{TrieMemoryIndex}} does not do this.
> We should check term sizes when rows are added and issue client warnings when
> this happens. This still needs to happen in the {{SSTableIndexWriter}} to
> handle terms during an initial index build.
--
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-18944) Test failure: org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787685#comment-17787685
]
Michael Semb Wever commented on CASSANDRA-18944:
simulator tests are run on ci-cassandra now, should be appearing.
> Test failure:
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
> -
>
> Key: CASSANDRA-18944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18944
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> The simulator test
> {{org.apache.cassandra.simulator.test.ShortPaxosSimulationTest#simulationTest}}
> is flaky on 5.0 and trunk:
> *
> https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/332/workflows/946e28f4-2dec-4384-ac38-de011093f6c6/jobs/25735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3253/workflows/e48b49e9-cf36-412a-a811-d813031e6f01/jobs/83735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3254/workflows/69f451ef-fb39-48e4-b1d1-40ee4141b0c1/jobs/83739/tests
> {code}
> org.apache.cassandra.simulator.SimulationException: Failed on seed
> 0xb01206bb3b021127
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.net.NoPayload cannot be cast to class
> org.apache.cassandra.gms.GossipShutdown (org.apache.cassandra.net.NoPayload
> and org.apache.cassandra.gms.GossipShutdown are in unnamed module of loader
> org.apache.cassandra.distributed.shared.InstanceClassLoader @68801feb)
> at
> org.apache.cassandra.gms.GossipShutdown$Serializer.serialize(GossipShutdown.java:41)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:722)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:427)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$registerOutboundFilter$5(Instance.java:370)
> at
> org.apache.cassandra.net.OutboundSink$Filtered.accept(OutboundSink.java:54)
> at org.apache.cassandra.net.OutboundSink.accept(OutboundSink.java:70)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:449)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:419)
> at
> org.apache.cassandra.gms.Gossiper.unsafeSendShutdown(Gossiper.java:2634)
> at
> org.apache.cassandra.simulator.cluster.OnInstanceSendShutdown.lambda$invokableSendShutdown$1(OnInstanceSendShutdown.java:48)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at
> org.apache.cassandra.concurrent.SyncFutureTask$1.call(SyncFutureTask.java:46)
> at
> org.apache.cassandra.concurrent.SyncFutureTask.run(SyncFutureTask.java:68)
> at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$AbstractSingleThreadedExecutorPlus.lambda$new$0(InterceptingExecutor.java:584)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> The test failure can easily be reproduced on CircleCI with:
> {code}
> .circleci/generate.sh -sp \
> -e
> REPEATED_SIMULATOR_DTESTS=org.apache.cassandra.simulator.test.ShortPaxosSimulationTest
> \
> -e REPEATED_SIMULATOR_DTESTS_COUNT=100
> {code}
> Flakiness seems ~18%.
> The test failure is not reported on Butler because simulator tests are not
> run by Jenkins.
--
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-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787680#comment-17787680
]
James Hu edited comment on CASSANDRA-18839 at 11/19/23 10:54 PM:
-
[~bschoeni] IntelliJ says that SSLHandshakeException is never thrown in the
corresponding try block. Is that intended behavior? If so, I put together the
code below. Is ctx.channel().remoteAddress() what we were looking for in the
log? Also, I couldn't seem to find javadocs sites for Cassandra online - is
there a way to generate the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
was (Author: JIRAUSER303103):
[~bschoeni] IntelliJ says that SSLHandshakeException is never thrown in the
corresponding try block. Is that intended behavior? If so, I put together the
code below. Is ctx.channel().remoteAddress() what we were looking for in the
log? I couldn't seem to find javadocs sites for Cassandra online - is there a
way to generate the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
>
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787680#comment-17787680
]
James Hu edited comment on CASSANDRA-18839 at 11/19/23 10:52 PM:
-
[~bschoeni] IntelliJ says that SSLHandshakeException is never thrown in the
corresponding try block. Is that intended behavior? If so, I put together the
code below. Is ctx.channel().remoteAddress() what we were looking for in the
log? I couldn't seem to find javadocs sites for Cassandra online - is there a
way to generate the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
was (Author: JIRAUSER303103):
IntelliJ says that SSLHandshakeException is never thrown in the corresponding
try block. Is that intended behavior? If so, I put together the code below. Is
ctx.channel().remoteAddress() what we were looking for in the log? I couldn't
seem to find javadocs sites for Cassandra online - is there a way to generate
the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
>
[jira] [Commented] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787680#comment-17787680
]
James Hu commented on CASSANDRA-18839:
--
IntelliJ says that SSLHandshakeException is never thrown in the corresponding
try block. Is that intended behavior? If so, I put together the code below. Is
ctx.channel().remoteAddress() what we were looking for in the log? I couldn't
seem to find javadocs sites for Cassandra online - is there a way to generate
the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
> io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
> at
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787680#comment-17787680
]
James Hu edited comment on CASSANDRA-18839 at 11/19/23 10:51 PM:
-
IntelliJ says that SSLHandshakeException is never thrown in the corresponding
try block. Is that intended behavior? If so, I put together the code below. Is
ctx.channel().remoteAddress() what we were looking for in the log? I couldn't
seem to find javadocs sites for Cassandra online - is there a way to generate
the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
was (Author: JIRAUSER303103):
IntelliJ says that SSLHandshakeException is never thrown in the corresponding
try block. Is that intended behavior? If so, I put together the code below. Is
ctx.channel().remoteAddress() what we were looking for in the log? I couldn't
seem to find javadocs sites for Cassandra online - is there a way to generate
the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
>
[jira] [Commented] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787666#comment-17787666 ] Leo Toff commented on CASSANDRA-19015: -- [~smiklosovic] Thanks for the break down. Do you know what other committer might be interested in this work? Maybe Brandon since they commented here earlier. Also, where can I find the current list of Cassandra committers? The following seems to be outdated: https://cwiki.apache.org/confluence/display/CASSANDRA2/Committers > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787664#comment-17787664 ] Stefan Miklosovic edited comment on CASSANDRA-19015 at 11/19/23 8:48 PM: - The rules are that any ticket has to be reviewed and approved by two committers. If a committer is an author of the patch, one additional committer has to take a look. Since you are not a committer, but myself, we need to find some other committer who reviews as well. The way it normally works is that I may review (as I am a committer) and then I will ask around to invite another one. Then we do the builds and then we might approach the merging. was (Author: smiklosovic): The rules are that any ticket has to be reviewed and approved by two committers. If a committer is an author of the patch, one additional committer has to take a look. Since you are not a committer, expect myself, we need to find some other committer who reviews as well. The way it normally works is that I may review (as I am a committer) and then I will ask around to invite another one. Then we do the builds and then we might approach the merging. > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787664#comment-17787664 ] Stefan Miklosovic commented on CASSANDRA-19015: --- The rules are that any ticket has to be reviewed and approved by two committers. If a committer is an author of the patch, one additional committer has to take a look. Since you are not a committer, expect myself, we need to find some other committer who reviews as well. The way it normally works is that I may review (as I am a committer) and then I will ask around to invite another one. Then we do the builds and then we might approach the merging. > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19015: -- Reviewers: Stefan Miklosovic Status: Review In Progress (was: Patch Available) > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19015: -- Fix Version/s: 5.x > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787661#comment-17787661 ] Leo Toff edited comment on CASSANDRA-19015 at 11/19/23 8:16 PM: [~bschoeni] Yeah, see [PR#2919|https://github.com/apache/cassandra/pull/2919] Does a patch have to be submitted and reviewed first, prior to creating a PR? Or could it progress in parallel? Github seems to be more conducive for code reviews. was (Author: JIRAUSER303078): [~bschoeni] Yeah, see [PR#2919|https://github.com/apache/cassandra/pull/2919] > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787661#comment-17787661 ] Leo Toff edited comment on CASSANDRA-19015 at 11/19/23 8:12 PM: [~bschoeni] Yeah, see [PR#2919|https://github.com/apache/cassandra/pull/2919] was (Author: JIRAUSER303078): [~bschoeni] Yeah, see [PR#2919|[https://github.com/apache/cassandra/pull/2919]|https://github.com/apache/cassandra/pull/2919].] > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787661#comment-17787661 ] Leo Toff commented on CASSANDRA-19015: -- [~bschoeni] Yeah, see [PR#2919|[https://github.com/apache/cassandra/pull/2919]|https://github.com/apache/cassandra/pull/2919].] > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[
https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leo updated CASSANDRA-19015:
Test and Documentation Plan:
{{nodetool tablestats}} returns latencies and ratios in a more consistent
format:
{code:java}
Keyspace: system
Read Count: 18
Read Latency: 5.084 ms
Write Count: 22
Write Latency: 0.566 ms
Pending Flushes: 0
Table: IndexInfo
...
SSTable Compression Ratio: 1.146
...
Local read count: 1
Local read latency: 14.237 ms
Local write count: 1
Local write latency: 0.770 ms
Local read/write ratio: 1.000
...
Bloom filter false ratio: 0.000
...
Average live cells per slice (last five minutes): 61.43
Maximum live cells per slice (last five minutes): 72
Average tombstones per slice (last five minutes): 1.00
Maximum tombstones per slice (last five minutes): 1
Droppable tombstone ratio: 0.000{code}
Tests:
{code:java}
ant testsome -Dtest.name=org.apache.cassandra.utils.FBUtilitiesTest{code}
[^CASSANDRA-19015-3.txt]
was:
{{nodetool tablestats}} returns latencies and ratios in a more consistent
format:
{code:java}
Keyspace: system
Read Count: 18
Read Latency: 5.084 ms
Write Count: 22
Write Latency: 0.566 ms
Pending Flushes: 0
Table: IndexInfo
...
SSTable Compression Ratio: 1.146
...
Local read count: 1
Local read latency: 14.237 ms
Local write count: 1
Local write latency: 0.770 ms
Local read/write ratio: 1.000
...
Bloom filter false ratio: 0.000
...
Average live cells per slice (last five minutes): 61.43
Maximum live cells per slice (last five minutes): 72
Average tombstones per slice (last five minutes): 1.0
Maximum tombstones per slice (last five minutes): 1
Droppable tombstone ratio: 0.000{code}
Tests:
{code:java}
ant testsome -Dtest.name=org.apache.cassandra.utils.FBUtilitiesTest{code}
[^CASSANDRA-19015-2.txt]
> Nodetool 'tablestats' formatting uses inconsistent significant digits
> -
>
> Key: CASSANDRA-19015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19015
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Leo
>Priority: Low
> Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt,
> CASSANDRA-19015-3.txt, CASSANDRA-19015.txt
>
>
> Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant
> digits. Ratios use five or sixteen decimal places. Averages use 1 or 13
> decimal places.
> * milliseconds should use 3 decimal places
> * ratios should use 3 decimal places (tenths of a percent)
> * averages should use 1 or 2
> For readability, it would be helpful if large integers had comma separators.
> I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear
> if the exact disk size is somehow useful, as it may change minute-by-minute,
> if not, rounding would be best, or displaying both Space used (live):
> 1,463,210,998,523 (1,463GiB)
> Total number of tables: 83
>
> Keyspace : X
> Read Count: 1007337271
> Read Latency: 8.485891803649942 ms
> Write Count: 67550181
> Write Latency: 0.02556443163342523 ms
> Pending Flushes: 0
> Table: Y
> SSTable count: 7183
> Old SSTable count: 0
> SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0]
> Space used (live): 1463210998523
> Space used (total): 1463210998523
> Space used by snapshots (total): 0
> Off heap memory used (total): 607419608
> SSTable Compression Ratio: 0.3146620992793412
> Number of partitions (estimate): 24784137
> Memtable cell count: 106067
> Memtable data size: 248539982
> Memtable off heap memory used: 0
> Memtable switch count: 256
> Local read count: 865440924
> Local read latency: 6.857 ms
> Local write count: 13881409
> Local write latency: 0.037 ms
> Pending flushes: 0
> Percent repaired: 0.0
> Bytes repaired: 0.000KiB
> Bytes unrepaired: 4315.386GiB
> Bytes pending repair: 0.000KiB
> Bloom filter false positives: 11027855
> Bloom filter false ratio: 0.01099
> Bloom filter space used: 33590024
> Bloom filter off heap memory used: 33532560
> Index summary off heap memory used: 8174024
>
[jira] [Updated] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leo updated CASSANDRA-19015: Attachment: CASSANDRA-19015-3.txt > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo >Priority: Low > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt > > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787636#comment-17787636 ] Brad Schoening commented on CASSANDRA-19015: [~zaaath] ok, that's fine. Do you know how to create a Pull Request from a fork of the github repo? > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo >Priority: Low > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015.txt > > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[
https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787631#comment-17787631
]
Leo edited comment on CASSANDRA-19015 at 11/19/23 5:32 PM:
---
[~bschoeni] Yes, prettyPrintRatio(Object ratioObj) signature could be changed
to prettyPrintRatio(Number ratio), but I can't completely eliminate the ifs.
And actually, I'd rather stick with prettyPrintRatio(Object ratioObj).
Here's why: String.format raises an exception when format specifiers don't
match the format arguments like in:
{code:java}
jshell> String.format("%.3f ms", (Number)123)
| Exception java.util.IllegalFormatConversionException: f != java.lang.Integer
{code}
And then there is also the "null" case.
So because sstableCompressionRatio and bloomFilterFalseRatio are untyped, we
have two options:
1. Branch type casting
2. Handle IllegalFormatConversionException exception
And the third option is to refactor StatsTable.sstableCompressionRatio and
StatsTable.bloomFilterFalseRatio to be typed as "double". I assume that the
third option is off-the-table since it might result in too many changes.
So I went with the first option. Let me know how you want me to handle the
situation.
was (Author: JIRAUSER303078):
[~bschoeni] Yes, prettyPrintRatio(Object ratioObj) signature could be changed
to prettyPrintRatio(Number ratio), but I can't completely eliminate the ifs.
And actually, I'd rather stick with prettyPrintRatio(Object ratioObj).
Here's why: String.format raises an exception when format specifiers don't
match the format arguments like in:
{code:java}
jshell> String.format("%.3f ms", (Number)123)
| Exception java.util.IllegalFormatConversionException: f != java.lang.Integer
{code}
And then there is also the "null" case.
So because sstableCompressionRatio and bloomFilterFalseRatio are untyped, we
have two options:
- Branch type casting
- Handle IllegalFormatConversionException exception
And the third option is to refactor StatsTable.sstableCompressionRatio and
StatsTable.bloomFilterFalseRatio to be typed as "double". I assume that the
third option is off-the-table since it might result in too many changes.
So I went with the first option. Let me know how you want me to handle the
situation.
> Nodetool 'tablestats' formatting uses inconsistent significant digits
> -
>
> Key: CASSANDRA-19015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19015
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Leo
>Priority: Low
> Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt,
> CASSANDRA-19015.txt
>
>
> Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant
> digits. Ratios use five or sixteen decimal places. Averages use 1 or 13
> decimal places.
> * milliseconds should use 3 decimal places
> * ratios should use 3 decimal places (tenths of a percent)
> * averages should use 1 or 2
> For readability, it would be helpful if large integers had comma separators.
> I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear
> if the exact disk size is somehow useful, as it may change minute-by-minute,
> if not, rounding would be best, or displaying both Space used (live):
> 1,463,210,998,523 (1,463GiB)
> Total number of tables: 83
>
> Keyspace : X
> Read Count: 1007337271
> Read Latency: 8.485891803649942 ms
> Write Count: 67550181
> Write Latency: 0.02556443163342523 ms
> Pending Flushes: 0
> Table: Y
> SSTable count: 7183
> Old SSTable count: 0
> SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0]
> Space used (live): 1463210998523
> Space used (total): 1463210998523
> Space used by snapshots (total): 0
> Off heap memory used (total): 607419608
> SSTable Compression Ratio: 0.3146620992793412
> Number of partitions (estimate): 24784137
> Memtable cell count: 106067
> Memtable data size: 248539982
> Memtable off heap memory used: 0
> Memtable switch count: 256
> Local read count: 865440924
> Local read latency: 6.857 ms
> Local write count: 13881409
> Local write latency: 0.037 ms
> Pending flushes: 0
> Percent repaired: 0.0
> Bytes repaired: 0.000KiB
> Bytes unrepaired: 4315.386GiB
> Bytes pending repair: 0.000KiB
> Bloom filter false positives: 11027855
> Bloom filter false ratio: 0.01099
> Bloom filter space used: 33590024
> Bloom filter off heap memory used: 33532560
> Index summary off heap memory used: 8174024
> Compression metadata off
[jira] [Commented] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787634#comment-17787634
]
Brad Schoening commented on CASSANDRA-18839:
Catching SSLHandshakeException in decode() should be sufficient and moving
source.release() to a new finally block.
{code:java}
try
{
ProtocolVersion version = getConnectionVersion(ctx);
.
}
catch (SSLHandshakeException ex)
{
log a msg here and return
}
catch (Throwable ex)
{
source.release();
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
> io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
>
[jira] [Comment Edited] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[
https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787631#comment-17787631
]
Leo edited comment on CASSANDRA-19015 at 11/19/23 5:32 PM:
---
[~bschoeni] Yes, prettyPrintRatio(Object ratioObj) signature could be changed
to prettyPrintRatio(Number ratio), but I can't completely eliminate the ifs.
And actually, I'd rather stick with prettyPrintRatio(Object ratioObj).
Here's why: String.format raises an exception when format specifiers don't
match the format arguments like in:
{code:java}
jshell> String.format("%.3f ms", (Number)123)
| Exception java.util.IllegalFormatConversionException: f != java.lang.Integer
{code}
And then there is also the "null" case.
So because sstableCompressionRatio and bloomFilterFalseRatio are untyped, we
have two options:
- Branch type casting
- Handle IllegalFormatConversionException exception
And the third option is to refactor StatsTable.sstableCompressionRatio and
StatsTable.bloomFilterFalseRatio to be typed as "double". I assume that the
third option is off-the-table since it might result in too many changes.
So I went with the first option. Let me know how you want me to handle the
situation.
was (Author: JIRAUSER303078):
[~bschoeni] Yes, prettyPrintRatio(Object ratioObj) signature could be changed
to prettyPrintRatio(Number ratio), but I can't completely eliminate the ifs.
That's because String.format raises an exception when format specifiers don't
match the format arguments like in:
{code:java}
jshell> String.format("%.3f ms", (Number)123)
| Exception java.util.IllegalFormatConversionException: f != java.lang.Integer
{code}
So because sstableCompressionRatio and bloomFilterFalseRatio are untyped, we
have two options:
- Branch type casting
- Handle IllegalFormatConversionException exception
And the third option is to refactor StatsTable.sstableCompressionRatio and
StatsTable.bloomFilterFalseRatio to be typed as "double". I assume that the
third option is off-the-table since it might result in too many changes.
So I went with the first option. Let me know how you want me to handle the
situation.
> Nodetool 'tablestats' formatting uses inconsistent significant digits
> -
>
> Key: CASSANDRA-19015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19015
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Leo
>Priority: Low
> Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt,
> CASSANDRA-19015.txt
>
>
> Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant
> digits. Ratios use five or sixteen decimal places. Averages use 1 or 13
> decimal places.
> * milliseconds should use 3 decimal places
> * ratios should use 3 decimal places (tenths of a percent)
> * averages should use 1 or 2
> For readability, it would be helpful if large integers had comma separators.
> I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear
> if the exact disk size is somehow useful, as it may change minute-by-minute,
> if not, rounding would be best, or displaying both Space used (live):
> 1,463,210,998,523 (1,463GiB)
> Total number of tables: 83
>
> Keyspace : X
> Read Count: 1007337271
> Read Latency: 8.485891803649942 ms
> Write Count: 67550181
> Write Latency: 0.02556443163342523 ms
> Pending Flushes: 0
> Table: Y
> SSTable count: 7183
> Old SSTable count: 0
> SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0]
> Space used (live): 1463210998523
> Space used (total): 1463210998523
> Space used by snapshots (total): 0
> Off heap memory used (total): 607419608
> SSTable Compression Ratio: 0.3146620992793412
> Number of partitions (estimate): 24784137
> Memtable cell count: 106067
> Memtable data size: 248539982
> Memtable off heap memory used: 0
> Memtable switch count: 256
> Local read count: 865440924
> Local read latency: 6.857 ms
> Local write count: 13881409
> Local write latency: 0.037 ms
> Pending flushes: 0
> Percent repaired: 0.0
> Bytes repaired: 0.000KiB
> Bytes unrepaired: 4315.386GiB
> Bytes pending repair: 0.000KiB
> Bloom filter false positives: 11027855
> Bloom filter false ratio: 0.01099
> Bloom filter space used: 33590024
> Bloom filter off heap memory used: 33532560
> Index summary off heap memory used: 8174024
> Compression metadata off heap memory used: 565713024
> Compacted partition minimum bytes: 36
> Compacted partition
[jira] [Comment Edited] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[
https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787631#comment-17787631
]
Leo edited comment on CASSANDRA-19015 at 11/19/23 5:19 PM:
---
[~bschoeni] Yes, prettyPrintRatio(Object ratioObj) signature could be changed
to prettyPrintRatio(Number ratio), but I can't completely eliminate the ifs.
That's because String.format raises an exception when format specifiers don't
match the format arguments like in:
{code:java}
jshell> String.format("%.3f ms", (Number)123)
| Exception java.util.IllegalFormatConversionException: f != java.lang.Integer
{code}
So because sstableCompressionRatio and bloomFilterFalseRatio are untyped, we
have two options:
- Branch type casting
- Handle IllegalFormatConversionException exception
And the third option is to refactor StatsTable.sstableCompressionRatio and
StatsTable.bloomFilterFalseRatio to be typed as "double". I assume that the
third option is off-the-table since it might result in too many changes.
So I went with the first option. Let me know how you want me to handle the
situation.
was (Author: JIRAUSER303078):
[~bschoeni] Yes, prettyPrintRatio(Object ratioObj) signature could be changed
to prettyPrintRatio(Number ratio), but I can't completely eliminate the ifs.
That's because String.format raises an exception when format specifiers don't
match the format arguments like in:
{code:java}
jshell> String.format("%.3f ms", (Integer)123)
| Exception java.util.IllegalFormatConversionException: f != java.lang.Integer
{code}
So because sstableCompressionRatio and bloomFilterFalseRatio are untyped, we
have two options:
- Branch type casting
- Handle IllegalFormatConversionException exception
And the third option is to refactor StatsTable.sstableCompressionRatio and
StatsTable.bloomFilterFalseRatio to be typed as "double". I assume that the
third option is off-the-table since it might result in too many changes.
So I went with the first option. Let me know how you want me to handle the
situation.
> Nodetool 'tablestats' formatting uses inconsistent significant digits
> -
>
> Key: CASSANDRA-19015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19015
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Leo
>Priority: Low
> Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt,
> CASSANDRA-19015.txt
>
>
> Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant
> digits. Ratios use five or sixteen decimal places. Averages use 1 or 13
> decimal places.
> * milliseconds should use 3 decimal places
> * ratios should use 3 decimal places (tenths of a percent)
> * averages should use 1 or 2
> For readability, it would be helpful if large integers had comma separators.
> I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear
> if the exact disk size is somehow useful, as it may change minute-by-minute,
> if not, rounding would be best, or displaying both Space used (live):
> 1,463,210,998,523 (1,463GiB)
> Total number of tables: 83
>
> Keyspace : X
> Read Count: 1007337271
> Read Latency: 8.485891803649942 ms
> Write Count: 67550181
> Write Latency: 0.02556443163342523 ms
> Pending Flushes: 0
> Table: Y
> SSTable count: 7183
> Old SSTable count: 0
> SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0]
> Space used (live): 1463210998523
> Space used (total): 1463210998523
> Space used by snapshots (total): 0
> Off heap memory used (total): 607419608
> SSTable Compression Ratio: 0.3146620992793412
> Number of partitions (estimate): 24784137
> Memtable cell count: 106067
> Memtable data size: 248539982
> Memtable off heap memory used: 0
> Memtable switch count: 256
> Local read count: 865440924
> Local read latency: 6.857 ms
> Local write count: 13881409
> Local write latency: 0.037 ms
> Pending flushes: 0
> Percent repaired: 0.0
> Bytes repaired: 0.000KiB
> Bytes unrepaired: 4315.386GiB
> Bytes pending repair: 0.000KiB
> Bloom filter false positives: 11027855
> Bloom filter false ratio: 0.01099
> Bloom filter space used: 33590024
> Bloom filter off heap memory used: 33532560
> Index summary off heap memory used: 8174024
> Compression metadata off heap memory used: 565713024
> Compacted partition minimum bytes: 36
> Compacted partition maximum bytes: 17797419593
> Compacted partition mean bytes: 189740
> Average live cells per slice
[jira] [Commented] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[
https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787631#comment-17787631
]
Leo commented on CASSANDRA-19015:
-
[~bschoeni] Yes, prettyPrintRatio(Object ratioObj) signature could be changed
to prettyPrintRatio(Number ratio), but I can't completely eliminate the ifs.
That's because String.format raises an exception when format specifiers don't
match the format arguments like in:
{code:java}
jshell> String.format("%.3f ms", (Integer)123)
| Exception java.util.IllegalFormatConversionException: f != java.lang.Integer
{code}
So because sstableCompressionRatio and bloomFilterFalseRatio are untyped, we
have two options:
- Branch type casting
- Handle IllegalFormatConversionException exception
And the third option is to refactor StatsTable.sstableCompressionRatio and
StatsTable.bloomFilterFalseRatio to be typed as "double". I assume that the
third option is off-the-table since it might result in too many changes.
So I went with the first option. Let me know how you want me to handle the
situation.
> Nodetool 'tablestats' formatting uses inconsistent significant digits
> -
>
> Key: CASSANDRA-19015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19015
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Leo
>Priority: Low
> Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt,
> CASSANDRA-19015.txt
>
>
> Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant
> digits. Ratios use five or sixteen decimal places. Averages use 1 or 13
> decimal places.
> * milliseconds should use 3 decimal places
> * ratios should use 3 decimal places (tenths of a percent)
> * averages should use 1 or 2
> For readability, it would be helpful if large integers had comma separators.
> I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear
> if the exact disk size is somehow useful, as it may change minute-by-minute,
> if not, rounding would be best, or displaying both Space used (live):
> 1,463,210,998,523 (1,463GiB)
> Total number of tables: 83
>
> Keyspace : X
> Read Count: 1007337271
> Read Latency: 8.485891803649942 ms
> Write Count: 67550181
> Write Latency: 0.02556443163342523 ms
> Pending Flushes: 0
> Table: Y
> SSTable count: 7183
> Old SSTable count: 0
> SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0]
> Space used (live): 1463210998523
> Space used (total): 1463210998523
> Space used by snapshots (total): 0
> Off heap memory used (total): 607419608
> SSTable Compression Ratio: 0.3146620992793412
> Number of partitions (estimate): 24784137
> Memtable cell count: 106067
> Memtable data size: 248539982
> Memtable off heap memory used: 0
> Memtable switch count: 256
> Local read count: 865440924
> Local read latency: 6.857 ms
> Local write count: 13881409
> Local write latency: 0.037 ms
> Pending flushes: 0
> Percent repaired: 0.0
> Bytes repaired: 0.000KiB
> Bytes unrepaired: 4315.386GiB
> Bytes pending repair: 0.000KiB
> Bloom filter false positives: 11027855
> Bloom filter false ratio: 0.01099
> Bloom filter space used: 33590024
> Bloom filter off heap memory used: 33532560
> Index summary off heap memory used: 8174024
> Compression metadata off heap memory used: 565713024
> Compacted partition minimum bytes: 36
> Compacted partition maximum bytes: 17797419593
> Compacted partition mean bytes: 189740
> Average live cells per slice (last five minutes): 1443.2146104466253
> Maximum live cells per slice (last five minutes): 105778
> Average tombstones per slice (last five minutes): 1.0
> Maximum tombstones per slice (last five minutes): 1
> Dropped Mutations: 0
> Droppable tombstone ratio: 0.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787626#comment-17787626
]
James Hu edited comment on CASSANDRA-18839 at 11/19/23 4:50 PM:
[~bschoeni] Do you mean that an SSLHandshakeException handler should already be
in PreV5Handlers.java? I didn't seem to see anything explicitly in that file. I
was thinking it might make sense to add a case to
logClientNetworkingExceptions() at
[https://github.com/apache/cassandra/blob/ed5a22428355765df5da94151413fc59538afef5/src/java/org/apache/cassandra/transport/ExceptionHandlers.java#L113-L141]
to catch/log the SSLHandshakeException. I'm still new to Cassandra dev and
open source in general, so please let me know if I'm way off the mark here.
was (Author: JIRAUSER303103):
[~bschoeni] Do you mean that an SSLHandshakeException handler should already be
in PreV5Handlers.java? I didn't seem to see anything explicitly in that file. I
was thinking it might make sense to add a case to
logClientNetworkingExceptions() at
[https://github.com/apache/cassandra/blob/ed5a22428355765df5da94151413fc59538afef5/src/java/org/apache/cassandra/transport/ExceptionHandlers.java#L113-L141]
to catch/log the SSLHandshakeException. I'm still new to Cassandra dev and
open source in general, so please let me know if I'm way off the mark here.
{code:java}
{code}
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
>
[jira] [Commented] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787626#comment-17787626
]
James Hu commented on CASSANDRA-18839:
--
[~bschoeni] Do you mean that an SSLHandshakeException handler should already be
in PreV5Handlers.java? I didn't seem to see anything explicitly in that file. I
was thinking it might make sense to add a case to
logClientNetworkingExceptions() at
[https://github.com/apache/cassandra/blob/ed5a22428355765df5da94151413fc59538afef5/src/java/org/apache/cassandra/transport/ExceptionHandlers.java#L113-L141]
to catch/log the SSLHandshakeException. I'm still new to Cassandra dev and
open source in general, so please let me know if I'm way off the mark here.
{code:java}
{code}
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
> io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
>
[jira] [Commented] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787618#comment-17787618
]
Brad Schoening commented on CASSANDRA-18839:
[~jameshu15869] Yes, this is still an open issue and that is the correct file.
It should have a handler for SSLHandshakeException.
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
> io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 15 common frames omitted {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-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787605#comment-17787605 ] Brad Schoening commented on CASSANDRA-19015: [~zaaath] For prettyPrintRatio, could the signature just have Number, ie., prettyPrintRatio(Number ratioObj) and eliminate the if? For prettyPrintAverage, I would use suggest a fixed number of decimal places, say 2. > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo >Priority: Low > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015.txt > > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787604#comment-17787604
]
James Hu commented on CASSANDRA-18839:
--
Hi, I'm new to the Cassandra dev community. Is this issue still open? If so, is
the PreV5Handlers.decode() method referring to the one in PreV5Handlers.java[
(https://github.com/apache/cassandra/blob/ed5a22428355765df5da94151413fc59538afef5/src/java/org/apache/cassandra/transport/PreV5Handlers.java#L256-L277?|https://github.com/apache/cassandra/blob/ed5a22428355765df5da94151413fc59538afef5/src/java/org/apache/cassandra/transport/PreV5Handlers.java#L256-L277])?
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
> io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 15 common frames omitted {code}
--
This message was sent by
[jira] [Commented] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[
https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787573#comment-17787573
]
Leo commented on CASSANDRA-19015:
-
{\{prettyPrintAverage}} is implemented as well. It uses 1 or 2 decimal places
depending on how many are available.
"Test and Documentation Plan" has been updated.
> Nodetool 'tablestats' formatting uses inconsistent significant digits
> -
>
> Key: CASSANDRA-19015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19015
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Leo
>Priority: Low
> Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt,
> CASSANDRA-19015.txt
>
>
> Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant
> digits. Ratios use five or sixteen decimal places. Averages use 1 or 13
> decimal places.
> * milliseconds should use 3 decimal places
> * ratios should use 3 decimal places (tenths of a percent)
> * averages should use 1 or 2
> For readability, it would be helpful if large integers had comma separators.
> I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear
> if the exact disk size is somehow useful, as it may change minute-by-minute,
> if not, rounding would be best, or displaying both Space used (live):
> 1,463,210,998,523 (1,463GiB)
> Total number of tables: 83
>
> Keyspace : X
> Read Count: 1007337271
> Read Latency: 8.485891803649942 ms
> Write Count: 67550181
> Write Latency: 0.02556443163342523 ms
> Pending Flushes: 0
> Table: Y
> SSTable count: 7183
> Old SSTable count: 0
> SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0]
> Space used (live): 1463210998523
> Space used (total): 1463210998523
> Space used by snapshots (total): 0
> Off heap memory used (total): 607419608
> SSTable Compression Ratio: 0.3146620992793412
> Number of partitions (estimate): 24784137
> Memtable cell count: 106067
> Memtable data size: 248539982
> Memtable off heap memory used: 0
> Memtable switch count: 256
> Local read count: 865440924
> Local read latency: 6.857 ms
> Local write count: 13881409
> Local write latency: 0.037 ms
> Pending flushes: 0
> Percent repaired: 0.0
> Bytes repaired: 0.000KiB
> Bytes unrepaired: 4315.386GiB
> Bytes pending repair: 0.000KiB
> Bloom filter false positives: 11027855
> Bloom filter false ratio: 0.01099
> Bloom filter space used: 33590024
> Bloom filter off heap memory used: 33532560
> Index summary off heap memory used: 8174024
> Compression metadata off heap memory used: 565713024
> Compacted partition minimum bytes: 36
> Compacted partition maximum bytes: 17797419593
> Compacted partition mean bytes: 189740
> Average live cells per slice (last five minutes): 1443.2146104466253
> Maximum live cells per slice (last five minutes): 105778
> Average tombstones per slice (last five minutes): 1.0
> Maximum tombstones per slice (last five minutes): 1
> Dropped Mutations: 0
> Droppable tombstone ratio: 0.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[
https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leo updated CASSANDRA-19015:
Test and Documentation Plan:
{{nodetool tablestats}} returns latencies and ratios in a more consistent
format:
{code:java}
Keyspace: system
Read Count: 18
Read Latency: 5.084 ms
Write Count: 22
Write Latency: 0.566 ms
Pending Flushes: 0
Table: IndexInfo
...
SSTable Compression Ratio: 1.146
...
Local read count: 1
Local read latency: 14.237 ms
Local write count: 1
Local write latency: 0.770 ms
Local read/write ratio: 1.000
...
Bloom filter false ratio: 0.000
...
Average live cells per slice (last five minutes): 61.43
Maximum live cells per slice (last five minutes): 72
Average tombstones per slice (last five minutes): 1.0
Maximum tombstones per slice (last five minutes): 1
Droppable tombstone ratio: 0.000{code}
Tests:
{code:java}
ant testsome -Dtest.name=org.apache.cassandra.utils.FBUtilitiesTest{code}
[^CASSANDRA-19015-2.txt]
was:
{{nodetool tablestats}} returns latencies and ratios in a more consistent
format:
{code:java}
Keyspace: system
Read Count: 18
Read Latency: 5.084 ms
Write Count: 22
Write Latency: 0.566 ms
Pending Flushes: 0
Table: IndexInfo
...
SSTable Compression Ratio: 1.146
...
Local read count: 1
Local read latency: 14.237 ms
Local write count: 1
Local write latency: 0.770 ms
Local read/write ratio: 1.000
...
Bloom filter false ratio: 0.000
...
Droppable tombstone ratio: 0.000
...{code}
TODO:
* prettyPrintAverage
[^CASSANDRA-19015-1.txt]
> Nodetool 'tablestats' formatting uses inconsistent significant digits
> -
>
> Key: CASSANDRA-19015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19015
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Leo
>Priority: Low
> Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt,
> CASSANDRA-19015.txt
>
>
> Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant
> digits. Ratios use five or sixteen decimal places. Averages use 1 or 13
> decimal places.
> * milliseconds should use 3 decimal places
> * ratios should use 3 decimal places (tenths of a percent)
> * averages should use 1 or 2
> For readability, it would be helpful if large integers had comma separators.
> I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear
> if the exact disk size is somehow useful, as it may change minute-by-minute,
> if not, rounding would be best, or displaying both Space used (live):
> 1,463,210,998,523 (1,463GiB)
> Total number of tables: 83
>
> Keyspace : X
> Read Count: 1007337271
> Read Latency: 8.485891803649942 ms
> Write Count: 67550181
> Write Latency: 0.02556443163342523 ms
> Pending Flushes: 0
> Table: Y
> SSTable count: 7183
> Old SSTable count: 0
> SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0]
> Space used (live): 1463210998523
> Space used (total): 1463210998523
> Space used by snapshots (total): 0
> Off heap memory used (total): 607419608
> SSTable Compression Ratio: 0.3146620992793412
> Number of partitions (estimate): 24784137
> Memtable cell count: 106067
> Memtable data size: 248539982
> Memtable off heap memory used: 0
> Memtable switch count: 256
> Local read count: 865440924
> Local read latency: 6.857 ms
> Local write count: 13881409
> Local write latency: 0.037 ms
> Pending flushes: 0
> Percent repaired: 0.0
> Bytes repaired: 0.000KiB
> Bytes unrepaired: 4315.386GiB
> Bytes pending repair: 0.000KiB
> Bloom filter false positives: 11027855
> Bloom filter false ratio: 0.01099
> Bloom filter space used: 33590024
> Bloom filter off heap memory used: 33532560
> Index summary off heap memory used: 8174024
> Compression metadata off heap memory used: 565713024
> Compacted partition minimum bytes: 36
> Compacted partition maximum bytes: 17797419593
> Compacted partition mean bytes: 189740
> Average live cells per slice (last five minutes): 1443.2146104466253
> Maximum live cells per slice (last five minutes): 105778
>
[jira] [Updated] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leo updated CASSANDRA-19015: Attachment: CASSANDRA-19015-2.txt > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo >Priority: Low > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015.txt > > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
