[jira] [Commented] (CASSANDRA-18466) Paxos only repair is treated as an incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-18466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757630#comment-17757630
]
Ningzi Zhan commented on CASSANDRA-18466:
-
Hi! Everyone, I have pushed the nodetool test in [PR
2531|https://github.com/apache/cassandra/pull/2531]. Please take a look if you
have time~
> Paxos only repair is treated as an incremental repair
> -
>
> Key: CASSANDRA-18466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Andrew
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Paxos only repair tries to continue or is treated as an incremental repair.
> This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for
> enabling paxos_state_purging. The repair was in preparation mode triggered
> multiple anti-compactions on the nodes. Running the command with --full
> behaves in the expected way, ie. only the paxos data is repaired and it's
> finished within a few seconds.
> {code:java}
> nodetool repair --paxos-only // This does not behave as expected, does it
> complete quickly and seems to be waiting on anticompactions
> {code}
> {code:java}
> nodetool repair --full --paxos-only // Completes within a few seconds as
> expected
> {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-18466) Paxos only repair is treated as an incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-18466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748693#comment-17748693
]
Ningzi Zhan commented on CASSANDRA-18466:
-
The log from nodetool repair shows the repair options, and the log has
{{incremental}} to show which kind of repair will run. I am not sure if it can
be counted as a test.
> Paxos only repair is treated as an incremental repair
> -
>
> Key: CASSANDRA-18466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Andrew
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Paxos only repair tries to continue or is treated as an incremental repair.
> This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for
> enabling paxos_state_purging. The repair was in preparation mode triggered
> multiple anti-compactions on the nodes. Running the command with --full
> behaves in the expected way, ie. only the paxos data is repaired and it's
> finished within a few seconds.
> {code:java}
> nodetool repair --paxos-only // This does not behave as expected, does it
> complete quickly and seems to be waiting on anticompactions
> {code}
> {code:java}
> nodetool repair --full --paxos-only // Completes within a few seconds as
> expected
> {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-18466) Paxos only repair is treated as an incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-18466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748356#comment-17748356
]
Ningzi Zhan commented on CASSANDRA-18466:
-
I have changed the Paxos-only repair to full repair in the default setting.
Here is the pull request link [PR
2531|https://github.com/apache/cassandra/pull/2531]. The PR is for version 4.1,
and the patch for trunk should be the same. Please take a look if you have time!
> Paxos only repair is treated as an incremental repair
> -
>
> Key: CASSANDRA-18466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Andrew
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Paxos only repair tries to continue or is treated as an incremental repair.
> This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for
> enabling paxos_state_purging. The repair was in preparation mode triggered
> multiple anti-compactions on the nodes. Running the command with --full
> behaves in the expected way, ie. only the paxos data is repaired and it's
> finished within a few seconds.
> {code:java}
> nodetool repair --paxos-only // This does not behave as expected, does it
> complete quickly and seems to be waiting on anticompactions
> {code}
> {code:java}
> nodetool repair --full --paxos-only // Completes within a few seconds as
> expected
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18466) Paxos only repair is treated as an incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-18466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748300#comment-17748300
]
Ningzi Zhan edited comment on CASSANDRA-18466 at 7/28/23 12:10 AM:
---
-I have changed the Paxos-only repair to full repair in the default setting.
Here is the pull request link [PR
2527|https://github.com/apache/cassandra/pull/2527] Please take a look if you
are available.-
was (Author: JIRAUSER299826):
I have changed the Paxos-only repair to full repair in the default setting.
Here is the pull request link [PR 2527|
https://github.com/apache/cassandra/pull/2527] Please take a look if you are
available.
> Paxos only repair is treated as an incremental repair
> -
>
> Key: CASSANDRA-18466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Andrew
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Paxos only repair tries to continue or is treated as an incremental repair.
> This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for
> enabling paxos_state_purging. The repair was in preparation mode triggered
> multiple anti-compactions on the nodes. Running the command with --full
> behaves in the expected way, ie. only the paxos data is repaired and it's
> finished within a few seconds.
> {code:java}
> nodetool repair --paxos-only // This does not behave as expected, does it
> complete quickly and seems to be waiting on anticompactions
> {code}
> {code:java}
> nodetool repair --full --paxos-only // Completes within a few seconds as
> expected
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18466) Paxos only repair is treated as an incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-18466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748300#comment-17748300
]
Ningzi Zhan edited comment on CASSANDRA-18466 at 7/27/23 7:08 PM:
--
I have changed the Paxos-only repair to full repair in the default setting.
Here is the pull request link [PR 2527|
https://github.com/apache/cassandra/pull/2527] Please take a look if you are
available.
was (Author: JIRAUSER299826):
I have changed the Paxos-only repair to full repair in the default setting.
Here is the pull request link [PR
2527|[https://github.com/apache/cassandra/pull/2527].] Please take a look if
you are available.
> Paxos only repair is treated as an incremental repair
> -
>
> Key: CASSANDRA-18466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Andrew
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Paxos only repair tries to continue or is treated as an incremental repair.
> This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for
> enabling paxos_state_purging. The repair was in preparation mode triggered
> multiple anti-compactions on the nodes. Running the command with --full
> behaves in the expected way, ie. only the paxos data is repaired and it's
> finished within a few seconds.
> {code:java}
> nodetool repair --paxos-only // This does not behave as expected, does it
> complete quickly and seems to be waiting on anticompactions
> {code}
> {code:java}
> nodetool repair --full --paxos-only // Completes within a few seconds as
> expected
> {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-18466) Paxos only repair is treated as an incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-18466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan updated CASSANDRA-18466:
Test and Documentation Plan: Test on CI
Status: Patch Available (was: In Progress)
I have changed the Paxos-only repair to full repair in the default setting.
Here is the pull request link [PR
2527|[https://github.com/apache/cassandra/pull/2527].] Please take a look if
you are available.
> Paxos only repair is treated as an incremental repair
> -
>
> Key: CASSANDRA-18466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18466
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Andrew
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Paxos only repair tries to continue or is treated as an incremental repair.
> This happened on 4.1.0 and 4.1.1 when trying to run repair in preparation for
> enabling paxos_state_purging. The repair was in preparation mode triggered
> multiple anti-compactions on the nodes. Running the command with --full
> behaves in the expected way, ie. only the paxos data is repaired and it's
> finished within a few seconds.
> {code:java}
> nodetool repair --paxos-only // This does not behave as expected, does it
> complete quickly and seems to be waiting on anticompactions
> {code}
> {code:java}
> nodetool repair --full --paxos-only // Completes within a few seconds as
> expected
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18570) Fix org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-18570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740346#comment-17740346
]
Ningzi Zhan edited comment on CASSANDRA-18570 at 7/5/23 11:29 PM:
--
Agree! I ran the test using the commit[
a2dc44f072|https://github.com/apache/cassandra/commit/a2dc44f0725b02294071e67d0cab57a7629f25a1]
to reproduce the error, but there is no error message related to it.
was (Author: JIRAUSER299826):
Agree! I ran it using the commit[
a2dc44f072|https://github.com/apache/cassandra/commit/a2dc44f0725b02294071e67d0cab57a7629f25a1]
to reproduce the error, but there is no error message related to it.
> Fix
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
>
> ---
>
> Key: CASSANDRA-18570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18570
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 5.x
>
>
> h1.
> {code:java}
> Regression
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
> (from org.apache.cassandra.transport.DriverBurnTest-.jdk17)
> Failing for the past 1 build (Since #1590 ) Took 30 sec. Failed 5 times
> in the last 30 runs. Flakiness: 24%, Stability: 83% Stacktrace
> junit.framework.AssertionFailedError at
> org.apache.cassandra.transport.DriverBurnTest.perfTest(DriverBurnTest.java:425)
> at
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression(DriverBurnTest.java:316)
> 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}
> The test is flaky since recently, failing every other time in Jenkins (burn
> tests are not running in CircleCI) First seen with run #1572 this commit -
> CASSANDRA-18025
> CC [~stefan.miklosovic] and [~brandon.williams]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18570) Fix org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-18570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740346#comment-17740346
]
Ningzi Zhan edited comment on CASSANDRA-18570 at 7/5/23 11:28 PM:
--
Agree! I ran it using the commit[
a2dc44f072|https://github.com/apache/cassandra/commit/a2dc44f0725b02294071e67d0cab57a7629f25a1]
to reproduce the error, but there is no error message related to it.
was (Author: JIRAUSER299826):
Agree! I ran it using the commit[commit
a2dc44f072|https://github.com/apache/cassandra/commit/a2dc44f0725b02294071e67d0cab57a7629f25a1]
to reproduce the error, but there is no error message related to it.
> Fix
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
>
> ---
>
> Key: CASSANDRA-18570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18570
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 5.x
>
>
> h1.
> {code:java}
> Regression
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
> (from org.apache.cassandra.transport.DriverBurnTest-.jdk17)
> Failing for the past 1 build (Since #1590 ) Took 30 sec. Failed 5 times
> in the last 30 runs. Flakiness: 24%, Stability: 83% Stacktrace
> junit.framework.AssertionFailedError at
> org.apache.cassandra.transport.DriverBurnTest.perfTest(DriverBurnTest.java:425)
> at
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression(DriverBurnTest.java:316)
> 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}
> The test is flaky since recently, failing every other time in Jenkins (burn
> tests are not running in CircleCI) First seen with run #1572 this commit -
> CASSANDRA-18025
> CC [~stefan.miklosovic] and [~brandon.williams]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18570) Fix org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-18570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740346#comment-17740346
]
Ningzi Zhan commented on CASSANDRA-18570:
-
Agree! I ran it using the commit[commit
a2dc44f072|https://github.com/apache/cassandra/commit/a2dc44f0725b02294071e67d0cab57a7629f25a1]
to reproduce the error, but there is no error message related to it.
> Fix
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
>
> ---
>
> Key: CASSANDRA-18570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18570
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 5.x
>
>
> h1.
> {code:java}
> Regression
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
> (from org.apache.cassandra.transport.DriverBurnTest-.jdk17)
> Failing for the past 1 build (Since #1590 ) Took 30 sec. Failed 5 times
> in the last 30 runs. Flakiness: 24%, Stability: 83% Stacktrace
> junit.framework.AssertionFailedError at
> org.apache.cassandra.transport.DriverBurnTest.perfTest(DriverBurnTest.java:425)
> at
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression(DriverBurnTest.java:316)
> 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}
> The test is flaky since recently, failing every other time in Jenkins (burn
> tests are not running in CircleCI) First seen with run #1572 this commit -
> CASSANDRA-18025
> CC [~stefan.miklosovic] and [~brandon.williams]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18570) Fix org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-18570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan reassigned CASSANDRA-18570:
---
Assignee: Ningzi Zhan
> Fix
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
>
> ---
>
> Key: CASSANDRA-18570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18570
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 5.x
>
>
> h1.
> {code:java}
> Regression
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
> (from org.apache.cassandra.transport.DriverBurnTest-.jdk17)
> Failing for the past 1 build (Since #1590 ) Took 30 sec. Failed 5 times
> in the last 30 runs. Flakiness: 24%, Stability: 83% Stacktrace
> junit.framework.AssertionFailedError at
> org.apache.cassandra.transport.DriverBurnTest.perfTest(DriverBurnTest.java:425)
> at
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression(DriverBurnTest.java:316)
> 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}
> The test is flaky since recently, failing every other time in Jenkins (burn
> tests are not running in CircleCI) First seen with run #1572 this commit -
> CASSANDRA-18025
> CC [~stefan.miklosovic] and [~brandon.williams]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732649#comment-17732649
]
Ningzi Zhan commented on CASSANDRA-17818:
-
Thank you everyone!
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 3.11.16, 4.0.11, 4.1.3, 5.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, but the code is the same in 4.0, 4.1,
> trunk:
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732279#comment-17732279
]
Ningzi Zhan edited comment on CASSANDRA-17818 at 6/13/23 11:37 PM:
---
Yes! It is! [~e.dimitrova]
was (Author: JIRAUSER299826):
Yes! It is!
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, but the code is the same in 4.0, 4.1,
> trunk:
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732279#comment-17732279
]
Ningzi Zhan commented on CASSANDRA-17818:
-
Yes! It is!
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, but the code is the same in 4.0, 4.1,
> trunk:
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731799#comment-17731799
]
Ningzi Zhan commented on CASSANDRA-17818:
-
Hi! [~e.dimitrova], [~brandon.williams] , [~maxwellguo] I have submitted new
commits in the original PR. Please feel free to look into it if you are
available. Any opinions are welcome.
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, but the code is the same in 4.0, 4.1,
> trunk:
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731071#comment-17731071
]
Ningzi Zhan commented on CASSANDRA-17818:
-
Thanks for the CI!
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, but the code is the same in 4.0, 4.1,
> trunk:
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731060#comment-17731060
]
Ningzi Zhan commented on CASSANDRA-17818:
-
Sorry, I am a little confused here. I have submitted the modification for
version 3.11 and version 4.0 in the original PR, which are slightly different.
Do you mean to combine these two?
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, but the code is the same in 4.0, 4.1,
> trunk:
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731056#comment-17731056
]
Ningzi Zhan commented on CASSANDRA-17818:
-
Hi! I make some improvements to the pull request. Please take a look if you are
available
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, but the code is the same in 4.0, 4.1,
> trunk:
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730755#comment-17730755
]
Ningzi Zhan edited comment on CASSANDRA-17818 at 6/8/23 10:25 PM:
--
The patch is submitted through PR
For version 3.11, the PR is [#2398
|https://github.com/apache/cassandra/pull/2398]
For version 4.0 or more advance, the PR is
[#2399|https://github.com/apache/cassandra/pull/2399]
I don't have access to circle CI right now, so I might need someone to help me
run the tests for all branches. Thank you!!
was (Author: JIRAUSER299826):
The patch is submitted through PR
For version 3.11, the PR is [#2398
|https://github.com/apache/cassandra/pull/2398]
For version 4.0 or more advance, the PR is
[#2399|https://github.com/apache/cassandra/pull/2399]
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, but the code is the same in 4.0, 4.1,
> trunk:
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan updated CASSANDRA-17818:
Test and Documentation Plan: test on CI
Status: Patch Available (was: In Progress)
The patch is submitted through PR
For version 3.11, the PR is [#2398
|https://github.com/apache/cassandra/pull/2398]
For version 4.0 or more advance, the PR is
[#2399|https://github.com/apache/cassandra/pull/2399]
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, but the code is the same in 4.0, 4.1,
> trunk:
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan reassigned CASSANDRA-17818:
---
Assignee: Ningzi Zhan
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, but the code is the same in 4.0, 4.1,
> trunk:
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724395#comment-17724395
]
Ningzi Zhan commented on CASSANDRA-18400:
-
[A new
commit|https://github.com/apache/cassandra/pull/2353/commits/c3cb55b1a4a17ceae6e6224f46e63e1cf9b3929c]
about NaN stuff has been submitted. !Screen Shot 2023-05-19 at
12.59.46.png|width=1066,height=80!
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png, Screen Shot
> 2023-05-19 at 12.59.46.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
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-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan updated CASSANDRA-18400:
Attachment: Screen Shot 2023-05-19 at 12.59.46.png
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png, Screen Shot
> 2023-05-19 at 12.59.46.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
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] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[ https://issues.apache.org/jira/browse/CASSANDRA-18400 ]
Ningzi Zhan deleted comment on CASSANDRA-18400:
-
was (Author: JIRAUSER299826):
[A new
commit|https://github.com/apache/cassandra/pull/2353/commits/c3cb55b1a4a17ceae6e6224f46e63e1cf9b3929c]
about NaN stuff has been submitted.
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png, Screen Shot
> 2023-05-19 at 12.59.46.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
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-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724393#comment-17724393
]
Ningzi Zhan commented on CASSANDRA-18400:
-
[A new
commit|https://github.com/apache/cassandra/pull/2353/commits/c3cb55b1a4a17ceae6e6224f46e63e1cf9b3929c]
about NaN stuff has been submitted.
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
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-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724360#comment-17724360
]
Ningzi Zhan commented on CASSANDRA-18400:
-
I restored the NaN of the hit rate in the [new
commit|https://github.com/apache/cassandra/pull/2353/files#diff-6f350ce37d440d2c826232c1985a3ef63d87d9c9b4a208f6a4ab5227cd55ac82].
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
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-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan updated CASSANDRA-18400:
Test and Documentation Plan: run CI (was: [Patch is
here|https://github.com/apache/cassandra/pull/2353])
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
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-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan updated CASSANDRA-18400:
Test and Documentation Plan: [Patch is
here|https://github.com/apache/cassandra/pull/2353]
Status: Patch Available (was: In Progress)
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
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-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724343#comment-17724343
]
Ningzi Zhan commented on CASSANDRA-18400:
-
1. For network cache info:
{quote}Network Cache should report a line similar to the above:
Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ? requests, ?
recent hit rate
{quote}
Since the Network cache is not precisely a cache, it is more like a pool of
buffers. Only reporting capacity and size should be enough. So the network
cache info looks like this.
{quote}Network Cache : size ? MiB, capacity ? MiB
{quote}
The capacity is the network cache total threshold, which corresponds to
{_}NETWORKING_MEMORY_USAGE_THRESHOLD{_}, and the size is the size of allocated
pooled buffers.
2. The NaN hit rate in the row and the counter cache is caused by dividing by
zero, but the zero comes from {*}_zero requests_{*}. In this case, I changed
the hit rate to 0 when the hit rate was NaN. I am not sure if it is valid to do
that.
After the patch, the final Nodetool info will look like this:
!Screen Shot 2023-05-18 at 13.57.45.png|width=1094,height=83!
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
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] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[ https://issues.apache.org/jira/browse/CASSANDRA-18400 ]
Ningzi Zhan deleted comment on CASSANDRA-18400:
-
was (Author: JIRAUSER299826):
1. For network cache info:
{quote}Network Cache should report a line similar to the above:
Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ? requests, ?
recent hit rate
{quote}
Since the Network cache is not precisely a cache, it is more like a pool of
buffers. Only reporting capacity and size should be enough. So the network
cache info looks like this.
{quote}Network Cache : size ? MiB, capacity ? MiB
{quote}
The capacity is the network cache total threshold, which corresponds to
{_}NETWORKING_MEMORY_USAGE_THRESHOLD{_}, and the size is the size of allocated
pooled buffers.
2. The NaN hit rate in the row and the counter cache is caused by dividing by
zero, but the zero comes from {*}_zero requests_{*}. In this case, I changed
the hit rate to 0 when the hit rate was NaN. I am not sure if it is valid to do
that.
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
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-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan updated CASSANDRA-18400:
Attachment: Screen Shot 2023-05-18 at 13.57.45.png
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
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-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724342#comment-17724342
]
Ningzi Zhan commented on CASSANDRA-18400:
-
1. For network cache info:
{quote}Network Cache should report a line similar to the above:
Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ? requests, ?
recent hit rate
{quote}
Since the Network cache is not precisely a cache, it is more like a pool of
buffers. Only reporting capacity and size should be enough. So the network
cache info looks like this.
{quote}Network Cache : size ? MiB, capacity ? MiB
{quote}
The capacity is the network cache total threshold, which corresponds to
{_}NETWORKING_MEMORY_USAGE_THRESHOLD{_}, and the size is the size of allocated
pooled buffers.
2. The NaN hit rate in the row and the counter cache is caused by dividing by
zero, but the zero comes from {*}_zero requests_{*}. In this case, I changed
the hit rate to 0 when the hit rate was NaN. I am not sure if it is valid to do
that.
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan reassigned CASSANDRA-18400:
---
Assignee: Ningzi Zhan
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
>
--
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-18420) Connection without username not logged in auditlog
[
https://issues.apache.org/jira/browse/CASSANDRA-18420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717292#comment-17717292
]
Ningzi Zhan edited comment on CASSANDRA-18420 at 4/27/23 4:36 PM:
--
In the [cqlsh protocol: Initial
handshake|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#:~:text=2.3%20Protocol%20Negotiation-,2.3.1%20Initial%20Handshake,-In%20order%20to],
it suggests that the client needs to send the STARTUP message and then wait
for the AUTHENTICATE message from the Cassandra server. If there is no username
in the STARTUP message, there is no way that the Cassandra server can send the
AUTHENTICATE message. Therefore, the client just deals with this non-username
scenario itself. If there is no username, the client will end the connection
itself so the server won't receive the message and write it into the audit log.
And the non-username is doomed to fail, so it might be OK that let the client
handle it.
was (Author: JIRAUSER299826):
In the[cqlsh protocol: Initial
handshake|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#:~:text=2.3%20Protocol%20Negotiation-,2.3.1%20Initial%20Handshake,-In%20order%20to],
it suggests that the client needs to send the STARTUP message and then wait
for the AUTHENTICATE message from the Cassandra server. If there is no username
in the STARTUP message, there is no way that the Cassandra server can send the
AUTHENTICATE message. Therefore, the client just deals with this non-username
scenario itself. If there is no username, the client will end the connection
itself so the server won't receive the message and write it into the audit log.
And the non-username is doomed to fail, so it might be OK that let the client
handle it.
> Connection without username not logged in auditlog
> ---
>
> Key: CASSANDRA-18420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18420
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Yakir Gibraltar
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> Hi,
> If making connection *without username* to cassandra cluster with
> PasswordAuthenticator enabled,
> Connection will fail but not logged on auditlog.
> How to reproduce:
> # Enable "authenticator: PasswordAuthenticator" on cluster
> # Enable audit : "nodetool enableauditlog"
> # Open a new screen and run "auditlogviewer -f /audit/"
> # Try to connect, and connection will fail:
> {code:java}
> [root@c1 ~]# cqlsh
> Connection error: ('Unable to connect to any servers', {'127.0.0.1:9042':
> AuthenticationFailed('Remote end requires authentication',)}){code}
> # *But nothing in auditlogviewer*.
> Connection with incorrect usernames or password logged correct on auditlog ,
> the problem only on connection without username.
> How it's affecting:
> # Security reason, hard to find unauthorized connections attempt .
> # When migrating cluster into PasswordAuthenticator, hard to find
> applications that didn't add username/password.
> Thank you.
--
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-18420) Connection without username not logged in auditlog
[
https://issues.apache.org/jira/browse/CASSANDRA-18420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717292#comment-17717292
]
Ningzi Zhan commented on CASSANDRA-18420:
-
In the[cqlsh protocol: Initial
handshake|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#:~:text=2.3%20Protocol%20Negotiation-,2.3.1%20Initial%20Handshake,-In%20order%20to],
it suggests that the client needs to send the STARTUP message and then wait
for the AUTHENTICATE message from the Cassandra server. If there is no username
in the STARTUP message, there is no way that the Cassandra server can send the
AUTHENTICATE message. Therefore, the client just deals with this non-username
scenario itself. If there is no username, the client will end the connection
itself so the server won't receive the message and write it into the audit log.
And the non-username is doomed to fail, so it might be OK that let the client
handle it.
> Connection without username not logged in auditlog
> ---
>
> Key: CASSANDRA-18420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18420
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Yakir Gibraltar
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> Hi,
> If making connection *without username* to cassandra cluster with
> PasswordAuthenticator enabled,
> Connection will fail but not logged on auditlog.
> How to reproduce:
> # Enable "authenticator: PasswordAuthenticator" on cluster
> # Enable audit : "nodetool enableauditlog"
> # Open a new screen and run "auditlogviewer -f /audit/"
> # Try to connect, and connection will fail:
> {code:java}
> [root@c1 ~]# cqlsh
> Connection error: ('Unable to connect to any servers', {'127.0.0.1:9042':
> AuthenticationFailed('Remote end requires authentication',)}){code}
> # *But nothing in auditlogviewer*.
> Connection with incorrect usernames or password logged correct on auditlog ,
> the problem only on connection without username.
> How it's affecting:
> # Security reason, hard to find unauthorized connections attempt .
> # When migrating cluster into PasswordAuthenticator, hard to find
> applications that didn't add username/password.
> Thank you.
--
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-18420) Connection without username not logged in auditlog
[
https://issues.apache.org/jira/browse/CASSANDRA-18420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717292#comment-17717292
]
Ningzi Zhan edited comment on CASSANDRA-18420 at 4/27/23 4:36 PM:
--
In the [cqlsh protocol: Initial
handshake|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#:~:text=2.3%20Protocol%20Negotiation-,2.3.1%20Initial%20Handshake,-In%20order%20to],
it suggests that the client needs to send the STARTUP message and then wait
for the AUTHENTICATE message from the Cassandra server. If there is no username
in the STARTUP message, there is no way that the Cassandra server can send the
AUTHENTICATE message. Therefore, the client just deals with this non-username
scenario itself. If there is no username, the client will end the connection
itself so the server won't receive the message and write it into the audit log.
And the non-username is doomed to fail, so it might be OK that let the client
handle it?
was (Author: JIRAUSER299826):
In the [cqlsh protocol: Initial
handshake|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#:~:text=2.3%20Protocol%20Negotiation-,2.3.1%20Initial%20Handshake,-In%20order%20to],
it suggests that the client needs to send the STARTUP message and then wait
for the AUTHENTICATE message from the Cassandra server. If there is no username
in the STARTUP message, there is no way that the Cassandra server can send the
AUTHENTICATE message. Therefore, the client just deals with this non-username
scenario itself. If there is no username, the client will end the connection
itself so the server won't receive the message and write it into the audit log.
And the non-username is doomed to fail, so it might be OK that let the client
handle it.
> Connection without username not logged in auditlog
> ---
>
> Key: CASSANDRA-18420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18420
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Yakir Gibraltar
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> Hi,
> If making connection *without username* to cassandra cluster with
> PasswordAuthenticator enabled,
> Connection will fail but not logged on auditlog.
> How to reproduce:
> # Enable "authenticator: PasswordAuthenticator" on cluster
> # Enable audit : "nodetool enableauditlog"
> # Open a new screen and run "auditlogviewer -f /audit/"
> # Try to connect, and connection will fail:
> {code:java}
> [root@c1 ~]# cqlsh
> Connection error: ('Unable to connect to any servers', {'127.0.0.1:9042':
> AuthenticationFailed('Remote end requires authentication',)}){code}
> # *But nothing in auditlogviewer*.
> Connection with incorrect usernames or password logged correct on auditlog ,
> the problem only on connection without username.
> How it's affecting:
> # Security reason, hard to find unauthorized connections attempt .
> # When migrating cluster into PasswordAuthenticator, hard to find
> applications that didn't add username/password.
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18420) Connection without username not logged in auditlog
[
https://issues.apache.org/jira/browse/CASSANDRA-18420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan reassigned CASSANDRA-18420:
---
Assignee: Ningzi Zhan
> Connection without username not logged in auditlog
> ---
>
> Key: CASSANDRA-18420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18420
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Yakir Gibraltar
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> Hi,
> If making connection *without username* to cassandra cluster with
> PasswordAuthenticator enabled,
> Connection will fail but not logged on auditlog.
> How to reproduce:
> # Enable "authenticator: PasswordAuthenticator" on cluster
> # Enable audit : "nodetool enableauditlog"
> # Open a new screen and run "auditlogviewer -f /audit/"
> # Try to connect, and connection will fail:
> {code:java}
> [root@c1 ~]# cqlsh
> Connection error: ('Unable to connect to any servers', {'127.0.0.1:9042':
> AuthenticationFailed('Remote end requires authentication',)}){code}
> # *But nothing in auditlogviewer*.
> Connection with incorrect usernames or password logged correct on auditlog ,
> the problem only on connection without username.
> How it's affecting:
> # Security reason, hard to find unauthorized connections attempt .
> # When migrating cluster into PasswordAuthenticator, hard to find
> applications that didn't add username/password.
> Thank you.
--
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
