[jira] [Updated] (CASSANDRA-18588) Slow builds due to checkstyle
[ https://issues.apache.org/jira/browse/CASSANDRA-18588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18588: Reviewers: Michael Semb Wever > Slow builds due to checkstyle > - > > Key: CASSANDRA-18588 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18588 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1.x, 5.x > > > Builds are terribly slow atm due to checkstyle. But there's an option to > cache results and only run on the latest changed files to avoid running over > the same files over and over again. > This brings build times from the current 1m30s to the old 5s. -- 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-18588) Slow builds due to checkstyle
[ https://issues.apache.org/jira/browse/CASSANDRA-18588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18588: Reviewers: Maxim Muzafarov, Michael Semb Wever (was: Michael Semb Wever) > Slow builds due to checkstyle > - > > Key: CASSANDRA-18588 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18588 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1.x, 5.x > > > Builds are terribly slow atm due to checkstyle. But there's an option to > cache results and only run on the latest changed files to avoid running over > the same files over and over again. > This brings build times from the current 1m30s to the old 5s. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated: Slow builds due to checkstyle
This is an automated email from the ASF dual-hosted git repository. bereng pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-4.1 by this push: new b7c00d7d13 Slow builds due to checkstyle b7c00d7d13 is described below commit b7c00d7d1391d0cfce770da29e570adf0f528fe0 Author: Bereng AuthorDate: Tue Jun 13 13:26:54 2023 +0200 Slow builds due to checkstyle patch by Berenguer Blasi; reviewed by Maxim Muzafarov, Michael Semb Wever for CASSANDRA-18588 --- checkstyle.xml | 2 ++ checkstyle_test.xml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/checkstyle.xml b/checkstyle.xml index 053cc735ab..1520b0a34c 100644 --- a/checkstyle.xml +++ b/checkstyle.xml @@ -23,6 +23,8 @@ + + diff --git a/checkstyle_test.xml b/checkstyle_test.xml index d237827f44..96de3d548d 100644 --- a/checkstyle_test.xml +++ b/checkstyle_test.xml @@ -23,6 +23,8 @@ + + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (41a669a100 -> 43d90928a8)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 41a669a100 Deduplicate the MixedMode* upgrade jvm-dtests new b7c00d7d13 Slow builds due to checkstyle new 43d90928a8 Merge branch 'cassandra-4.1' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: checkstyle.xml | 2 ++ checkstyle_test.xml | 2 ++ 2 files changed, 4 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. bereng pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 43d90928a8cc0f83bba7eede051890981a65fc72 Merge: 41a669a100 b7c00d7d13 Author: Bereng AuthorDate: Wed Jun 14 10:15:02 2023 +0200 Merge branch 'cassandra-4.1' into trunk * cassandra-4.1: Slow builds due to checkstyle checkstyle.xml | 2 ++ checkstyle_test.xml | 2 ++ 2 files changed, 4 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18588) Slow builds due to checkstyle
[ https://issues.apache.org/jira/browse/CASSANDRA-18588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18588: Status: Ready to Commit (was: Review In Progress) > Slow builds due to checkstyle > - > > Key: CASSANDRA-18588 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18588 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1.x, 5.x > > > Builds are terribly slow atm due to checkstyle. But there's an option to > cache results and only run on the latest changed files to avoid running over > the same files over and over again. > This brings build times from the current 1m30s to the old 5s. -- 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-18588) Slow builds due to checkstyle
[ https://issues.apache.org/jira/browse/CASSANDRA-18588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18588: Status: Review In Progress (was: Needs Committer) > Slow builds due to checkstyle > - > > Key: CASSANDRA-18588 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18588 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1.x, 5.x > > > Builds are terribly slow atm due to checkstyle. But there's an option to > cache results and only run on the latest changed files to avoid running over > the same files over and over again. > This brings build times from the current 1m30s to the old 5s. -- 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-18588) Slow builds due to checkstyle
[ https://issues.apache.org/jira/browse/CASSANDRA-18588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18588: Fix Version/s: 4.1.3 5.0 (was: 5.x) (was: 4.1.x) Source Control Link: https://github.com/apache/cassandra/commit/b7c00d7d1391d0cfce770da29e570adf0f528fe0 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Slow builds due to checkstyle > - > > Key: CASSANDRA-18588 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18588 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1.3, 5.0 > > > Builds are terribly slow atm due to checkstyle. But there's an option to > cache results and only run on the latest changed files to avoid running over > the same files over and over again. > This brings build times from the current 1m30s to the old 5s. -- 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-18560) Incorrect IP used for gossip across DCs with prefer_local=true
[
https://issues.apache.org/jira/browse/CASSANDRA-18560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732449#comment-17732449
]
Maciej Sokol commented on CASSANDRA-18560:
--
Hey Brandon,
The issue is that streaming uses OutboundConnectionSettings::connectTo()
directly without checking if it's local DC or not. Also it completely ignores
prefer_local so the problem exists even with prefer_local=false.
Using OutboundConnectionSettings.withConnectTo(using connectTo):
[NettyStreamingMessageSender.java#L241|https://github.com/apache/cassandra/blob/5143bd81e82c35ce686dd40860ec2aebe30aaf22/src/java/org/apache/cassandra/streaming/async/NettyStreamingMessageSender.java#L241]
Using OutboundConnectionSettings.withDefaults(which uses connectTo):
[DefaultConnectionFactory.java#L49|https://github.com/apache/cassandra/blob/5143bd81e82c35ce686dd40860ec2aebe30aaf22/src/java/org/apache/cassandra/streaming/DefaultConnectionFactory.java#L49]
ConnectTo (the connectTo is always null in case of streaming):
[OutboundConnectionSettings.java#L451|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/net/OutboundConnectionSettings.java#L451]
> Incorrect IP used for gossip across DCs with prefer_local=true
> --
>
> Key: CASSANDRA-18560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18560
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brad Vernon
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> After installing a new node using 4.0.10 we experienced a situation where the
> new node attempted to connect to the private ip of a random number of nodes
> remote DCs which are only accessible via public ip for cross dc
> communications.
> The only impact was new nodes outbound connections, inbound from pre-4.0.10
> were not affected. system.peers_v2 (below) showed that the preferred_ip and
> preferred_port as null, only those in 4.0.10 nodes dc have perferred_ip
> values as expected.
> We believe the issue originated with
> https://issues.apache.org/jira/browse/CASSANDRA-16718
> Details on cluster:
> * All nodes have public IP configured as well as private IP
> * Listen/rpc addressrs are configured for private ip, broadcast is public IP
> * prefer_local=true is enabled for all nodes
> The log that showed the connection failing:
> {code:java}
> INFO [Messaging-EventLoop-3-8] 2023-06-01 00:14:21,565 NoSpamLogger.java:92
> -
> /99.81.:7000->/44.208.:7000-URGENT_MESSAGES-[no-channel]
> failed to connectio.netty.channel.ConnectTimeoutException: connection timed
> out: /10.26.5.11:7000 at
> io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe$2.run(AbstractEpollChannel.java:576){code}
> 99 and 44 instances can only access each other using public ips.
> gossipinfo output from 4.0.10 node
> {code:java}
> /44.208.
> generation:1661113358
> heartbeat:25267691
> LOAD:25267683:1.7882044268E10
> SCHEMA:24692061:e98b918d-499f-3ccc-8dbe-5af31f685bda
> DC:13:us-east-1
> RACK:15:1a
> RELEASE_VERSION:6:4.0.5
> NET_VERSION:2:12
> HOST_ID:3:9a41e668-060d-4cfe-bb1e-013f5116422d
> RPC_READY:1407:true
> INTERNAL_ADDRESS_AND_PORT:9:10.26.5.11:7000
> NATIVE_ADDRESS_AND_PORT:4:44.208.:9042
> STATUS_WITH_PORT:1393:NORMAL,-2262036356854762881
> SSTABLE_VERSIONS:7:big-nb
> TOKENS:1392: {code}
> Peers output from 4.0.10 node:
> {code:java}
>peer | peer_port | data_center | host_id
> | native_address | native_port | preferred_ip | preferred_port |
> rack | release_version | schema_version |
> tokens+---+-+--++-+--++--+-+--+---
> 44.208. | 7000 | us-east-1 |
> 9a41e668-060d-4cfe-bb1e-013f5116422d | 44.208. |9042 |
> null | null | 1a | 4.0.5 |
> e98b918d-499f-3ccc-8dbe-5af31f685bda |{'-2262036356854762881',
> '-4197710115038136897', '-7072386316096662315', '2085255826742630980',
> '249732489387853170', '4976300208126705818', '7187184456885833289',
> '8777189009399731927'} {code}
> To solve temporarily we routed outbound traffic to the private ip to public
> using iptables which resulted in successful outbound connections.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
--
[jira] [Comment Edited] (CASSANDRA-18560) Incorrect IP used for gossip across DCs with prefer_local=true
[
https://issues.apache.org/jira/browse/CASSANDRA-18560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732449#comment-17732449
]
Maciej Sokol edited comment on CASSANDRA-18560 at 6/14/23 8:49 AM:
---
Hey Brandon,
The issue is that streaming uses OutboundConnectionSettings::connectTo()
directly without checking if it's local DC or not. Also it completely ignores
prefer_local so the problem exists even with prefer_local=false.
Using OutboundConnectionSettings.withConnectTo(using connectTo):
[NettyStreamingMessageSender.java#L241|https://github.com/apache/cassandra/blob/5143bd81e82c35ce686dd40860ec2aebe30aaf22/src/java/org/apache/cassandra/streaming/async/NettyStreamingMessageSender.java#L241]
Using OutboundConnectionSettings.withDefaults(which uses connectTo):
[DefaultConnectionFactory.java#L49|https://github.com/apache/cassandra/blob/5143bd81e82c35ce686dd40860ec2aebe30aaf22/src/java/org/apache/cassandra/streaming/DefaultConnectionFactory.java#L49]
withDefaults:
[OutboundConnectionSettings.java#L481|https://github.com/apache/cassandra/blob/5143bd81e82c35ce686dd40860ec2aebe30aaf22/src/java/org/apache/cassandra/net/OutboundConnectionSettings.java#L481]
ConnectTo (the connectTo is always null in case of streaming):
[OutboundConnectionSettings.java#L451|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/net/OutboundConnectionSettings.java#L451]
was (Author: JIRAUSER285315):
Hey Brandon,
The issue is that streaming uses OutboundConnectionSettings::connectTo()
directly without checking if it's local DC or not. Also it completely ignores
prefer_local so the problem exists even with prefer_local=false.
Using OutboundConnectionSettings.withConnectTo(using connectTo):
[NettyStreamingMessageSender.java#L241|https://github.com/apache/cassandra/blob/5143bd81e82c35ce686dd40860ec2aebe30aaf22/src/java/org/apache/cassandra/streaming/async/NettyStreamingMessageSender.java#L241]
Using OutboundConnectionSettings.withDefaults(which uses connectTo):
[DefaultConnectionFactory.java#L49|https://github.com/apache/cassandra/blob/5143bd81e82c35ce686dd40860ec2aebe30aaf22/src/java/org/apache/cassandra/streaming/DefaultConnectionFactory.java#L49]
ConnectTo (the connectTo is always null in case of streaming):
[OutboundConnectionSettings.java#L451|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/net/OutboundConnectionSettings.java#L451]
> Incorrect IP used for gossip across DCs with prefer_local=true
> --
>
> Key: CASSANDRA-18560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18560
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brad Vernon
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> After installing a new node using 4.0.10 we experienced a situation where the
> new node attempted to connect to the private ip of a random number of nodes
> remote DCs which are only accessible via public ip for cross dc
> communications.
> The only impact was new nodes outbound connections, inbound from pre-4.0.10
> were not affected. system.peers_v2 (below) showed that the preferred_ip and
> preferred_port as null, only those in 4.0.10 nodes dc have perferred_ip
> values as expected.
> We believe the issue originated with
> https://issues.apache.org/jira/browse/CASSANDRA-16718
> Details on cluster:
> * All nodes have public IP configured as well as private IP
> * Listen/rpc addressrs are configured for private ip, broadcast is public IP
> * prefer_local=true is enabled for all nodes
> The log that showed the connection failing:
> {code:java}
> INFO [Messaging-EventLoop-3-8] 2023-06-01 00:14:21,565 NoSpamLogger.java:92
> -
> /99.81.:7000->/44.208.:7000-URGENT_MESSAGES-[no-channel]
> failed to connectio.netty.channel.ConnectTimeoutException: connection timed
> out: /10.26.5.11:7000 at
> io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe$2.run(AbstractEpollChannel.java:576){code}
> 99 and 44 instances can only access each other using public ips.
> gossipinfo output from 4.0.10 node
> {code:java}
> /44.208.
> generation:1661113358
> heartbeat:25267691
> LOAD:25267683:1.7882044268E10
> SCHEMA:24692061:e98b918d-499f-3ccc-8dbe-5af31f685bda
> DC:13:us-east-1
> RACK:15:1a
> RELEASE_VERSION:6:4.0.5
> NET_VERSION:2:12
> HOST_ID:3:9a41e668-060d-4cfe-bb1e-013f5116422d
> RPC_READY:1407:true
> INTERNAL_ADDRESS_AND_PORT:9:10.26.5.11:7000
> NATIVE_ADDRESS_AND_PORT:4:44.208.:9042
> STATUS_WITH_PORT:1393:NORMAL,-2262036356854762881
> SSTABLE_VERSIONS:7:big-nb
> TOKENS:1392: {code}
> Peers output from 4.0.10 node:
> {code:java}
>peer | peer_port | da
[jira] [Commented] (CASSANDRA-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732474#comment-17732474 ] Brandon Williams commented on CASSANDRA-18555: -- I don't think we need to persist any state here, if decom fails then you are free to try again so saving the failed state doesn't make sense since there is no logic based on it. I think we are overdoing this, the original problem can be summarized as "JMX times out so I can't tell if the node is still decommissioning" which led to proposing a new command to essentially allow retrying the query. Let's take a step back. If the node is in the decom process even if the nodeool process times out, can this state not be seen from nodetool status? If it has failed should it not be reflected there too? Why isn't status sufficient here? Gossip is already the de facto way to get this information and being is used to convey that decom has begun so I don't see why it shouldn't be used to indicate it has failed. > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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&focusedCommentId=17732479#comment-17732479
]
Brandon Williams commented on CASSANDRA-17818:
--
||Branch||CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1062/workflows/1343d6d5-f051-4c8c-bc82-7fcb02bafe7d]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1064/workflows/3a3710c1-ad49-4760-8f64-0d33e3b1fe27],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1064/workflows/b4076402-7fcd-4819-8e65-b39ad129aab7]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1065/workflows/4a325eaf-a010-4e01-a637-45469988a271]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1063/workflows/4e7058ba-bc12-4866-a95d-92ccd4c98676],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1063/workflows/6e40adbb-08f4-45a7-998e-90225fcbaa1d]|
> 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] [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&focusedCommentId=17732479#comment-17732479
]
Brandon Williams edited comment on CASSANDRA-17818 at 6/14/23 9:57 AM:
---
||Branch||CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1062/workflows/1343d6d5-f051-4c8c-bc82-7fcb02bafe7d]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1064/workflows/3a3710c1-ad49-4760-8f64-0d33e3b1fe27],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1064/workflows/b4076402-7fcd-4819-8e65-b39ad129aab7]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1065/workflows/4a325eaf-a010-4e01-a637-45469988a271],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1065/workflows/6dbe8ee6-a336-46a2-a6cb-21e2dd1cbb2e]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1063/workflows/4e7058ba-bc12-4866-a95d-92ccd4c98676],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1063/workflows/6e40adbb-08f4-45a7-998e-90225fcbaa1d]|
was (Author: brandon.williams):
||Branch||CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1062/workflows/1343d6d5-f051-4c8c-bc82-7fcb02bafe7d]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1064/workflows/3a3710c1-ad49-4760-8f64-0d33e3b1fe27],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1064/workflows/b4076402-7fcd-4819-8e65-b39ad129aab7]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1065/workflows/4a325eaf-a010-4e01-a637-45469988a271]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1063/workflows/4e7058ba-bc12-4866-a95d-92ccd4c98676],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1063/workflows/6e40adbb-08f4-45a7-998e-90225fcbaa1d]|
> 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 uni
[jira] [Updated] (CASSANDRA-18596) Assertion error when describing mv as table
[
https://issues.apache.org/jira/browse/CASSANDRA-18596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18596:
-
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Component/s: Feature/Materialized Views
Discovered By: User Report
Fix Version/s: 4.0.x
4.1.x
5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Assertion error when describing mv as table
> ---
>
> Key: CASSANDRA-18596
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18596
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Maciej Sokol
>Assignee: Maciej Sokol
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> When describing materialized view as a table Cassandra gets an assertion
> error.
> Steps to reproduce:
> CREATE KEYSPACE test WITH replication = \{'class': 'NetworkTopologyStrategy',
> 'datacenter1': '3'} AND durable_writes = true;
> CREATE TABLE test.table1 (key1 text,key2 int,value int,PRIMARY KEY (key1,
> key2));
> CREATE MATERIALIZED VIEW test.table1_by_value AS SELECT key1, key2, value
> FROM test.table1 WHERE value IS NOT NULL AND key1 IS NOT NULL AND key2 IS NOT
> NULL PRIMARY KEY(value, key1, key2);
> DESCRIBE MATERIALIZED VIEW test.table1;
> DESCRIBE TABLE test.table1_by_value;
> DESCRIBE TABLE test.non_existing;
>
> From the above the "DESCRIBE TABLE test.table1_by_value;" throws an assertion
> error while "DESCRIBE TABLE test.non_existing;" returns a meaningful error
> msg.
--
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-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732490#comment-17732490
]
Stefan Miklosovic commented on CASSANDRA-18305:
---
After looking more closer to it, I do not think that 'compaction throughput
ratio' is computed correctly or that figure even make sense.
I think the original idea behind this was what if a node is compacting
SSTables, there would be a percentage, like 20%, if it compacts with speed
around 12 MBps. However, if you look into CompactionManager, there is:
private final RateLimiter compactionRateLimiter =
RateLimiter.create(Double.MAX_VALUE);
And then we get the rate like:
{code}
public double getCompactionRate()
{
return compactionRateLimiter.getRate();
}
{code}
This should be changed to
{code}
public double getCompactionRate()
{
return getRateLimiter().getRate();
}
{code}
because getRateLimiter() is setting the rates based on how DatabaseDescriptor
is configured:
{code}
public RateLimiter getRateLimiter()
{
setRate(DatabaseDescriptor.getCompactionThroughputMbPerSec());
return compactionRateLimiter;
}
{code}
and then
{code}
public void setRate(final double throughPutMbPerSec)
{
double throughput = throughPutMbPerSec * 1024.0 * 1024.0;
// if throughput is set to 0, throttling is disabled
if (throughput == 0 || StorageService.instance.isBootstrapMode())
throughput = Double.MAX_VALUE;
if (compactionRateLimiter.getRate() != throughput)
compactionRateLimiter.setRate(throughput);
}
{code}
Secondly, once this is done, what did we actually obtained by calling
CompactionManagerMBean and having `getCompactionRate()` as a double? We just
got the maximum throughput allowed.
But this does not mean that we got _the actual throughput_. We just got the max
possible. So further computing the percentage will not make sense because we
always get 100%.
This in the patch
{code}
double configured = probe.getCompactionThroughput();
double actual = probe.getCompactionRate() / (1024 * 1024);
{code}
these are basically same figures and they will not change over time, regardless
how "fast" we compact. As of now I do not know about any way how to get "the
realtime compaction speed" so I think it is better if we omit this completely.
There are also these metrics which are not covered currently:
BytesCompacted
CompactionsAborted
CompactionsReduced
SSTablesDroppedFromCompaction
BytesCompacted metric tracks the total amount of bytes Cassandra node compacted
since its start. We may probably convert it to something human readable instead
of just "bytes" which are hard to parse to something meaningful over time.
CompactionsAborted is self-explanatory.
CompactionsReduced and SSTablesDroppedFromCompaction are interesting metrics.
They are set in CompactionTask.buildCompactionCandidatesForAvailableDiskSpace.
That method checks if it has enough disk space for the compaction.
CompactionsReduced is increased if it evaluates that some SSTables will be
skipped from compaction because if it was compacted it would not fit into the
disk.
The second metric, SSTablesDroppedFromCompaction, is a counter which adds the
number of sstables which were left out from a particular compaction because
they would not fit into the disk.
This all should be in the output too.
CompactionsAborted, CompactionsReduced and SSTablesDroppedFromCompaction where
not added in NodeProbe.getCompactionMetric so I added them there too.
So, right now, it looks like this:
{code}
$ ./bin/nodetool compactionstats
concurrent compactors2
pending compaction tasks 0
ks tb 3
ks tb2 5
compactions completed51
data compacted 8.99 KiB
compactions aborted 0
compactions reduced 0
sstables dropped from compaction 0
minute rate 0.60/second
5 minute rate0.60/second
15 minute rate 0.60/second
mean rate0.42/second
compaction throughput (MBps) 64.0
{code}
I pushed the changes to the same PR (1) as this commit (2)
[~manish.c.ghildi...@gmail.com] feel free to take it again and just tweak the
tests. I know it might be little bit frustrating we are returning to this but
it is how it is ... Please tell us you are ok with this, if you are busy we may
help you with that too.
(1) https://github.com/apache/cassandra/pull/2393/files
(2)
https://github.com/apache/cassandra/pull/2393/commits/02b128c1f17f5880ced21007389366385a52ecf8
> Enhance nodetool compactionstats with existing MBean metrics
> -
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732493#comment-17732493
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
[~smiklosovic] , I agree with your point regarding compaction throughput and I
have raised it on other PR(for 5.0).
I would integrate above recommended changes, and create a separate PR for 4.1
too. Also, would make these changes for 5.0 PR too.
I would be able to do it on weekend though.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Commented] (CASSANDRA-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732494#comment-17732494 ] Stefan Miklosovic commented on CASSANDRA-18555: --- [~brandon.williams] If you checked the whole communication (which you probably havent but I dont blame you for that as that is understandable), I was thinking about propagating this to "nodetool status" too. So it would be seen from every node in the cluster, basically. That would be the purest solution but I abandoned it in favor of saving the state as I did not want to mess with Gossip as that seems to be way more complex. We would need to add bunch of logic around this. This seems to be way simpler as we just persist it into already existing column in a table and it seems like natural fit. Why do you think there is no logic behind that? If we save that it has decommissioned, what is wrong with saving an information that it failed to do so? If it is not persisted, if we fail to decommission and we kill the instance and it is started again, what state that node is actually in? Because right now its bootstrap state would be still "completed" but it might partially decommission itself which is quite dangerous, isnt it? > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18586) CQLSH formatting output is incorrect when querying the system properties virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-18586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732498#comment-17732498
]
Maxim Muzafarov commented on CASSANDRA-18586:
-
[~bschoeni] I don't have that much experience with Cassandra's tools, so I
can't suggest the best solution we might have, but from a user's point of view,
this task can be split down into two subtasks:
- If the vertical line display is enabled ({{{}EXPAND ON{}}} command), I think
we just need to limit the number of dashes for each row representation (or have
other symbols to separate rows) to make the end result look more natural.
Example:
-- This is how it looks now:
[https://gist.github.com/Mmuzaf/d59c4f70d4a0f07ea0720fb575830e15]
-- This is how it could look, so from my point of view it should be enough to
have a simple line break or a symbol for {{{}@Row 1{}}}:
[https://gist.github.com/Mmuzaf/645f2bc0f83e6159dcf998c2906d8397]
- If the horizontal display is enabled ({{{}EXPAND OFF{}}} command), the
closest thing we might have is the {{.width}} command in sqlite (to limit the
column size). I'm not sure if this will work for us, as I haven't delved into
the cqlsh source code.
[https://www.w3resource.com/sqlite/sqlite-dot-commands.php#width]
> CQLSH formatting output is incorrect when querying the system properties
> virtual table
> --
>
> Key: CASSANDRA-18586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18586
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Maxim Muzafarov
>Priority: Normal
> Attachments: image-2023-06-12-19-01-34-086.png
>
>
> cqlsh produces incorrect output for the following query:
> {code:java}
> select * from system_views.system_properties;{code}
> See the screenshot:
> !image-2023-06-12-19-01-34-086.png|width=318,height=314!
> The reason for this is that the {{java.class.path}} system property has a
> very long string representation value, so it breaks the formatting of the
> query result. Changing the output format from horizontal query output to
> vertical [1] doesn't help either.
> The formatting must be fixed.
> [1]
> [https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/cqlsh_commands/cqlshExpand.html]
--
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-18586) CQLSH formatting output is incorrect when querying the system properties virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-18586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732498#comment-17732498
]
Maxim Muzafarov edited comment on CASSANDRA-18586 at 6/14/23 11:49 AM:
---
[~bschoeni] I don't have that much experience with Cassandra's tools, so I
can't suggest the best solution we might have, but from a user's point of view,
this task can be split down into two subtasks:
- If the vertical line display is enabled ({{{}EXPAND ON{}}} command), I think
we just need to limit the number of dashes for each row representation (or have
other symbols to separate rows) to make the end result look more natural (or
calculate the number of dashes for each row individually). Example:
-- This is how it looks now:
[https://gist.github.com/Mmuzaf/d59c4f70d4a0f07ea0720fb575830e15]
-- This is how it could look, so from my point of view it should be enough to
have a simple line break or a symbol for {{{}@Row 1{}}}:
[https://gist.github.com/Mmuzaf/645f2bc0f83e6159dcf998c2906d8397]
- If the horizontal display is enabled ({{{}EXPAND OFF{}}} command), the
closest thing we might have is the {{.width}} command in sqlite (to limit the
column size). I'm not sure if this will work for us, as I haven't delved into
the cqlsh source code.
[https://www.w3resource.com/sqlite/sqlite-dot-commands.php#width]
was (Author: mmuzaf):
[~bschoeni] I don't have that much experience with Cassandra's tools, so I
can't suggest the best solution we might have, but from a user's point of view,
this task can be split down into two subtasks:
- If the vertical line display is enabled ({{{}EXPAND ON{}}} command), I think
we just need to limit the number of dashes for each row representation (or have
other symbols to separate rows) to make the end result look more natural.
Example:
-- This is how it looks now:
[https://gist.github.com/Mmuzaf/d59c4f70d4a0f07ea0720fb575830e15]
-- This is how it could look, so from my point of view it should be enough to
have a simple line break or a symbol for {{{}@Row 1{}}}:
[https://gist.github.com/Mmuzaf/645f2bc0f83e6159dcf998c2906d8397]
- If the horizontal display is enabled ({{{}EXPAND OFF{}}} command), the
closest thing we might have is the {{.width}} command in sqlite (to limit the
column size). I'm not sure if this will work for us, as I haven't delved into
the cqlsh source code.
[https://www.w3resource.com/sqlite/sqlite-dot-commands.php#width]
> CQLSH formatting output is incorrect when querying the system properties
> virtual table
> --
>
> Key: CASSANDRA-18586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18586
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Maxim Muzafarov
>Priority: Normal
> Attachments: image-2023-06-12-19-01-34-086.png
>
>
> cqlsh produces incorrect output for the following query:
> {code:java}
> select * from system_views.system_properties;{code}
> See the screenshot:
> !image-2023-06-12-19-01-34-086.png|width=318,height=314!
> The reason for this is that the {{java.class.path}} system property has a
> very long string representation value, so it breaks the formatting of the
> query result. Changing the output format from horizontal query output to
> vertical [1] doesn't help either.
> The formatting must be fixed.
> [1]
> [https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/cqlsh_commands/cqlshExpand.html]
--
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-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732500#comment-17732500
]
Stefan Miklosovic commented on CASSANDRA-18305:
---
[~manish.c.ghildi...@gmail.com] great! Thank you for your perseverance.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Commented] (CASSANDRA-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732543#comment-17732543 ] Brandon Williams commented on CASSANDRA-18555: -- bq. If you checked the whole communication I did... I think here's where the disconnect is: bq. If it is not persisted, if we fail to decommission and we kill the instance and it is started again, what state that node is actually in? The state it was in before starting decom: a normal member of the ring. If you accidentally begin a decommission and restart the node to get out of it, this is what you would expect. bq. partially decommission itself which is quite dangerous, isnt it? No. Barring space issues, a node can attempt to decom as many times as it needs to until it completes. We shouldn't be changing this behavior, and so persisting in the bootstrap state doesn't make sense. We only persist when decom completes so that we can prevent it from rejoining, but retrying failures is allowed. > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732547#comment-17732547
]
Brandon Williams commented on CASSANDRA-18305:
--
bq. As of now I do not know about any way how to get "the realtime compaction
speed" so I think it is better if we omit this completely.
I looked into guava's RateLimiter and... I agree. This doesn't work like I
thought and it's going to be painful to get this information, it's not readily
accessible right now. Thanks for catching this!
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {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] [Updated] (CASSANDRA-18285) [CircleCI] Add JDK 11 Java and Python upgrade tests in trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18285: Status: Ready to Commit (was: Review In Progress) > [CircleCI] Add JDK 11 Java and Python upgrade tests in trunk > > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. -This has to be added not only in trunk,, > but also 4.1- > This ticket will be used for trunk. A separate one will be opened for 4.0 > and 4.1. > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18543) Waiting for gossip to settle does not wait for live endpoints
[ https://issues.apache.org/jira/browse/CASSANDRA-18543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18543: - Status: Ready to Commit (was: Review In Progress) > Waiting for gossip to settle does not wait for live endpoints > - > > Key: CASSANDRA-18543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18543 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Cameron Zemek >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x > > Attachments: gossip.patch, gossip4.patch > > Time Spent: 40m > Remaining Estimate: 0h > > When a node starts it will get endpoint states (via shadow round) but have > all nodes marked as down. The problem is the wait to settle only checks the > size of endpoint states is stable before starting Native transport. Once > native transport starts it will receive queries and fail consistency levels > such as LOCAL_QUORUM since it still thinks nodes are down. > This is problem for a number of large clusters for our customers. The cluster > has quorum but due to this issue a node restart is causing a bunch of query > errors. > My initial solution to this was to only check live endpoints size in addition > to size of endpoint states. This worked but I noticed in testing this fix > that there also a lot of duplication of checking the same node (via Echo > messages) for liveness. So the patch also removes this duplication of > checking node is UP in markAlive. > The final problem I found while testing is sometimes could still not see a > change in live endpoints due to only 1 second polling, so the patch allows > for overridding the settle parameters. I could not reliability reproduce this > but think its worth providing a way to override these hardcoded values. -- 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-18543) Waiting for gossip to settle does not wait for live endpoints
[ https://issues.apache.org/jira/browse/CASSANDRA-18543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732548#comment-17732548 ] Brandon Williams commented on CASSANDRA-18543: -- +1 > Waiting for gossip to settle does not wait for live endpoints > - > > Key: CASSANDRA-18543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18543 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Cameron Zemek >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x > > Attachments: gossip.patch, gossip4.patch > > Time Spent: 40m > Remaining Estimate: 0h > > When a node starts it will get endpoint states (via shadow round) but have > all nodes marked as down. The problem is the wait to settle only checks the > size of endpoint states is stable before starting Native transport. Once > native transport starts it will receive queries and fail consistency levels > such as LOCAL_QUORUM since it still thinks nodes are down. > This is problem for a number of large clusters for our customers. The cluster > has quorum but due to this issue a node restart is causing a bunch of query > errors. > My initial solution to this was to only check live endpoints size in addition > to size of endpoint states. This worked but I noticed in testing this fix > that there also a lot of duplication of checking the same node (via Echo > messages) for liveness. So the patch also removes this duplication of > checking node is UP in markAlive. > The final problem I found while testing is sometimes could still not see a > change in live endpoints due to only 1 second polling, so the patch allows > for overridding the settle parameters. I could not reliability reproduce this > but think its worth providing a way to override these hardcoded values. -- 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&focusedCommentId=17732479#comment-17732479
]
Brandon Williams edited comment on CASSANDRA-17818 at 6/14/23 1:57 PM:
---
||Branch||CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1062/workflows/1343d6d5-f051-4c8c-bc82-7fcb02bafe7d]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1064/workflows/3a3710c1-ad49-4760-8f64-0d33e3b1fe27],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1064/workflows/b4076402-7fcd-4819-8e65-b39ad129aab7]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1065/workflows/4a325eaf-a010-4e01-a637-45469988a271],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1065/workflows/6dbe8ee6-a336-46a2-a6cb-21e2dd1cbb2e]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1063/workflows/4e7058ba-bc12-4866-a95d-92ccd4c98676],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1063/workflows/6e40adbb-08f4-45a7-998e-90225fcbaa1d]|
No surprises.
was (Author: brandon.williams):
||Branch||CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1062/workflows/1343d6d5-f051-4c8c-bc82-7fcb02bafe7d]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1064/workflows/3a3710c1-ad49-4760-8f64-0d33e3b1fe27],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1064/workflows/b4076402-7fcd-4819-8e65-b39ad129aab7]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1065/workflows/4a325eaf-a010-4e01-a637-45469988a271],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1065/workflows/6dbe8ee6-a336-46a2-a6cb-21e2dd1cbb2e]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17818-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1063/workflows/4e7058ba-bc12-4866-a95d-92ccd4c98676],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1063/workflows/6e40adbb-08f4-45a7-998e-90225fcbaa1d]|
> 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 w
[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&focusedCommentId=17732551#comment-17732551
]
Maxwell Guo commented on CASSANDRA-17818:
-
so it seems we can commit if [~e.dimitrova] +1
> 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732552#comment-17732552 ] Stefan Miklosovic commented on CASSANDRA-18555: --- Aha ... well, to put my way of thinking under scrutiny, so let's imagine that a decommission fails, we kill the node and we start it again (that scenario itself is quite improbable but anyway). My point is that "this is dangerous so we need to save the state". OK, so we save the state, we see that the previous decommission has failed and now what? Like ... what are we going to do about that? What other possible course of action we could take when we see a node has failed to decommission but to try to decommission it again? So the fact that it failed to decommission _and to persist this state until a possible restart_ is kind of useless. If decommission means to be repeatable if it fails in the middle, as you suggested, that knowing this across restarts is not helpful. Whole decommissioning logic is basically about two methods in StorageService: startLeaving() and unbootstrap(). startLeaving just gossips that status will be LEAVING so other nodes know this. unbootstrap is repairing some paxos topology, starts batchlog replay, hints replay and it streams data to other nodes, all of which seems to be repeatable without issues. I do not see any dtest which would test failed decommission so we would see it is indeed repeatable operation. I check what it would take to gossip unsuccessful decommission operation. I dont have a clue how complex that would be but my gut feeling is that it wont be so easy. Let's see. > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732555#comment-17732555 ] Maxwell Guo commented on CASSANDRA-18555: - it seems when decommission failed the state in system table keep complete status and we can do it repeatable . > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732558#comment-17732558 ] Brandon Williams commented on CASSANDRA-18555: -- bq. I do not see any dtest which would test failed decommission I found [this one|https://github.com/apache/cassandra-dtest/blob/trunk/topology_test.py#L212]. Maybe we don't need to go whole hog here and gossip a new state, I'm not sure the utility of being able to observe a failed decom globally outweighs the cost. I almost feel like adding the nodetool command was the simplest solution, but not wanting to proliferation nodetool commands is valid. > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732558#comment-17732558 ] Brandon Williams edited comment on CASSANDRA-18555 at 6/14/23 2:18 PM: --- bq. I do not see any dtest which would test failed decommission I found [this one|https://github.com/apache/cassandra-dtest/blob/trunk/topology_test.py#L212]. Maybe we don't need to go whole hog here and gossip a new state, I'm not sure the utility of being able to observe a failed decom globally outweighs the cost. I almost feel like adding the nodetool command was the simplest solution, but not wanting to proliferate nodetool commands is valid. was (Author: brandon.williams): bq. I do not see any dtest which would test failed decommission I found [this one|https://github.com/apache/cassandra-dtest/blob/trunk/topology_test.py#L212]. Maybe we don't need to go whole hog here and gossip a new state, I'm not sure the utility of being able to observe a failed decom globally outweighs the cost. I almost feel like adding the nodetool command was the simplest solution, but not wanting to proliferation nodetool commands is valid. > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18285) [CircleCI] Add JDK 11 Java and Python upgrade tests in trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18285: Fix Version/s: 5.0 (was: 5.x) > [CircleCI] Add JDK 11 Java and Python upgrade tests in trunk > > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0 > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. -This has to be added not only in trunk,, > but also 4.1- > This ticket will be used for trunk. A separate one will be opened for 4.0 > and 4.1. > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18285) [CircleCI] Add JDK 11 Java and Python upgrade tests in trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732560#comment-17732560 ] Ekaterina Dimitrova commented on CASSANDRA-18285: - Committed to https://github.com/apache/cassandra [43d90928a8..1d961679a0 trunk -> trunk|https://github.com/apache/cassandra/commit/1d961679a0ab76043e610e45aa7089e81fd64aa1] > [CircleCI] Add JDK 11 Java and Python upgrade tests in trunk > > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. -This has to be added not only in trunk,, > but also 4.1- > This ticket will be used for trunk. A separate one will be opened for 4.0 > and 4.1. > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (43d90928a8 -> 1d961679a0)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 43d90928a8 Merge branch 'cassandra-4.1' into trunk add 1d961679a0 Switch Java and Python upgrade tests from running on JDK8 to JDK11 in CircleCI patch by Ekaterina Dimitrova; reviewed by Berenguer Blasi for CASSANDRA-18285 No new revisions were added by this update. Summary of changes: .circleci/config.yml | 1193 +-- .circleci/config.yml.FREE | 1193 +-- .circleci/config.yml.PAID | 1199 ++-- .circleci/config_11_and_17.yml | 978 .circleci/config_11_and_17.yml.FREE| 978 .circleci/config_11_and_17.yml.PAID| 978 .circleci/config_template.yml | 146 +-- .circleci/config_template.yml.PAID.patch | 86 +- .circleci/config_template_11_and_17.yml| 144 ++- .circleci/config_template_11_and_17.yml.PAID.patch | 89 +- .circleci/generate.sh |4 +- .circleci/generate_11_and_17.sh| 16 + 12 files changed, 5068 insertions(+), 1936 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18285) [CircleCI] Add JDK 11 Java and Python upgrade tests in trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18285: Source Control Link: https://github.com/apache/cassandra/commit/1d961679a0ab76043e610e45aa7089e81fd64aa1 Resolution: Fixed Status: Resolved (was: Ready to Commit) > [CircleCI] Add JDK 11 Java and Python upgrade tests in trunk > > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0 > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. -This has to be added not only in trunk,, > but also 4.1- > This ticket will be used for trunk. A separate one will be opened for 4.0 > and 4.1. > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732564#comment-17732564 ] Stefan Miklosovic commented on CASSANDRA-18555: --- The compromise would consist of putting it into nodetool info so we use already existing nodetool command but we would not save the state to table. It would be visible it failed to decommission as long as Cassandra process runs. > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732564#comment-17732564 ] Stefan Miklosovic edited comment on CASSANDRA-18555 at 6/14/23 2:31 PM: The compromise would consist of putting it into nodetool info so we use already existing nodetool command but we would not save the state to table. It would be visible it failed to decommission as long as Cassandra process runs. So in practice, an operator would see "ah, this node is leaving as it would be in UL (I think that's right)" but if an operator sees that it takes too long and something is probably going on as it is stuck in UL for eternity, there would be nodetool info to see what the state of the decommission is / what state that node is in - and there would be DECOMMISSION_FAILED. was (Author: smiklosovic): The compromise would consist of putting it into nodetool info so we use already existing nodetool command but we would not save the state to table. It would be visible it failed to decommission as long as Cassandra process runs. > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732565#comment-17732565 ] Brandon Williams commented on CASSANDRA-18555: -- If there is a corresponding JMX endpoint to query that we display in nodetool info, I think that works. Then there's a way for a human to check without adding any clutter, and a way to programmatically check too. > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18555: - Status: Open (was: Patch Available) > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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&focusedCommentId=17732573#comment-17732573
]
Ekaterina Dimitrova commented on CASSANDRA-17818:
-
I just approved the PRs with the following comment:
{code:java}
LGTM, +1
Just a typo, and a few names need to be corrected on commit; thank you!{code}
The changes that need to be done are marked in the 3.11 PR, but the same will
apply to the rest of the Cassandra branches.
CI also LGTM.
Thank you for your work, [~qannap]
> 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: 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] [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
]
Ekaterina Dimitrova updated CASSANDRA-17818:
Status: Ready to Commit (was: Review In Progress)
> 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: 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] [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&focusedCommentId=17732574#comment-17732574
]
Ekaterina Dimitrova commented on CASSANDRA-17818:
-
[~brandon.williams] as you already have the branches, do you mind committing,
please?
Also, please, remember to add Tomek as a co-author. Thank you!
> 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: 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] [Updated] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18540:
Status: Ready to Commit (was: Review In Progress)
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, after
> 2021-Apr JDK8 dropped TLSv1.1 which led to a fix in
> [cassandra-build|https://github.com/apache/cassandra-builds/commit/d1a3a0c59b3c5c17697d6a6656cd5d4f3a1cdbe9]
> docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
--
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-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732575#comment-17732575
]
Ekaterina Dimitrova commented on CASSANDRA-18540:
-
{quote}but didn't think a
[multiplexer|https://app.circleci.com/pipelines/github/driftx/cassandra/1061/workflows/648e3ed0-32f3-43ff-930e-c05b1bfa9f9e/jobs/29939]
check on trunk would hurt just to be sure we haven't introduced any flakiness.
{quote}
I was thinking it is pretty deterministic, but you are right that world of
Cassandra never stops to surprise us. Good call, thanks!
Starting commit soon
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, after
> 2021-Apr JDK8 dropped TLSv1.1 which led to a fix in
> [cassandra-build|https://github.com/apache/cassandra-builds/commit/d1a3a0c59b3c5c17697d6a6656cd5d4f3a1cdbe9]
> docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
--
[jira] [Updated] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18540:
Fix Version/s: 4.0.x
4.1.x
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, after
> 2021-Apr JDK8 dropped TLSv1.1 which led to a fix in
> [cassandra-build|https://github.com/apache/cassandra-builds/commit/d1a3a0c59b3c5c17697d6a6656cd5d4f3a1cdbe9]
> docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
--
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-18190) ECJ upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732577#comment-17732577
]
Ekaterina Dimitrova commented on CASSANDRA-18190:
-
{quote}With this ticket, can we also please move the
{{eclipse_compiler.properties}} into the {{.build/}} directory. Its location is
defined in {{build.xml}}
{quote}
Yes
> ECJ upgrade
> ---
>
> Key: CASSANDRA-18190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18190
> Project: Cassandra
> Issue Type: Task
> Components: Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> During testing it was identified that we will need to update ECJ for the Java
> UDF functions in order to bring Java 17 in.
> It seems the compiler artifacts are moved from
> [here|https://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj ]
> to [here|https://mvnrepository.com/artifact/org.eclipse.jdt/ecj] and there is
> change of license from EPL1.0 to EPL2.0 too. But if I read correctly
> [here|https://www.apache.org/legal/resolved.html#weak-copyleft-licenses] that
> should not affect us
> Further testing and review of all changes between artifacts to be done.
> ECJ is used for the eclipse-warnings and Java UDFs
--
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-18479) Add basic text tokenisation and analysis
[ https://issues.apache.org/jira/browse/CASSANDRA-18479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson reassigned CASSANDRA-18479: Assignee: Mike Adamson > Add basic text tokenisation and analysis > > > Key: CASSANDRA-18479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18479 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > > [CASSANDRA-16092|https://issues.apache.org/jira/browse/CASSANDRA-16092] > removed support for any text analysis or tokenisation. > SAI currently supports the following analyzers: > * normalize - text normalization using NFC normalization > * case_sensitive - allow control over the case sensitivity of an index > * ascii - allow ascii folding of text -- 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-18490) Add checksum validation to all index components on startup, full rebuild and streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-18490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson reassigned CASSANDRA-18490: Assignee: (was: Mike Adamson) > Add checksum validation to all index components on startup, full rebuild and > streaming > -- > > Key: CASSANDRA-18490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18490 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Mike Adamson >Priority: Normal > Fix For: NA > > > The SAI code currently does not checksum validate per-column index data files > at any point. It does checksum validate per-sstable components after a full > rebuild and it checksum validates the per-column metadata on opening. > We should checksum validate all index components on startup, full rebuild and > streaming. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732588#comment-17732588 ] Stefan Miklosovic commented on CASSANDRA-18555: --- [~chovatia.jayd...@gmail.com] I try to model this as just discussed. Thank you for your patience! > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-18555: - Assignee: Stefan Miklosovic (was: Jaydeepkumar Chovatia) > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732589#comment-17732589 ] Jaydeepkumar Chovatia commented on CASSANDRA-18555: --- [~smiklosovic] [~brandon.williams] If you look at the original Pull request, then it does exactly what you have just proposed. It does not persist in any state and provides a JMX endpoint. It has been tested and working in my production environment for more than a year now without any issues. Please look at this and let us know your comments: [https://github.com/apache/cassandra/pull/2374] > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732589#comment-17732589 ] Jaydeepkumar Chovatia edited comment on CASSANDRA-18555 at 6/14/23 3:35 PM: [~smiklosovic] [~brandon.williams] If you look at the original Pull request, then it does not persist in any state and provides a JMX endpoint. It has been tested and working in my production environment for more than a year now without any issues. Please look at this and let us know your comments: [https://github.com/apache/cassandra/pull/2374] was (Author: chovatia.jayd...@gmail.com): [~smiklosovic] [~brandon.williams] If you look at the original Pull request, then it does exactly what you have just proposed. It does not persist in any state and provides a JMX endpoint. It has been tested and working in my production environment for more than a year now without any issues. Please look at this and let us know your comments: [https://github.com/apache/cassandra/pull/2374] > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732589#comment-17732589 ] Jaydeepkumar Chovatia edited comment on CASSANDRA-18555 at 6/14/23 3:36 PM: [~smiklosovic] [~brandon.williams] If you look at the original Pull request, then it does not persist in any state and provides a JMX endpoint. It has been tested and working in my production environment for more than a year now without any issues. [https://github.com/apache/cassandra/pull/2374] was (Author: chovatia.jayd...@gmail.com): [~smiklosovic] [~brandon.williams] If you look at the original Pull request, then it does not persist in any state and provides a JMX endpoint. It has been tested and working in my production environment for more than a year now without any issues. Please look at this and let us know your comments: [https://github.com/apache/cassandra/pull/2374] > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18597) Update BlockBalancedTreeWriter to take advantage of Lucene improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-18597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18597: - Component/s: Feature/SAI > Update BlockBalancedTreeWriter to take advantage of Lucene improvements > --- > > Key: CASSANDRA-18597 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18597 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Priority: Normal > > There have been improvements to the Lucene BKDWriter implementation for the > one-dimensional case that could be used to improve the > BlockBalancedTreeWriter. Specifically > [LUCENE-9358|https://issues.apache.org/jira/browse/LUCENE-9358] removes the > need for the rotateToTree method by writing the balanced tree in the correct > format while it is being built. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18597) Update BlockBalancedTreeWriter to take advantage of Lucene improvements
Mike Adamson created CASSANDRA-18597: Summary: Update BlockBalancedTreeWriter to take advantage of Lucene improvements Key: CASSANDRA-18597 URL: https://issues.apache.org/jira/browse/CASSANDRA-18597 Project: Cassandra Issue Type: Improvement Reporter: Mike Adamson There have been improvements to the Lucene BKDWriter implementation for the one-dimensional case that could be used to improve the BlockBalancedTreeWriter. Specifically [LUCENE-9358|https://issues.apache.org/jira/browse/LUCENE-9358] removes the need for the rotateToTree method by writing the balanced tree in the correct format while it is being built. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18598) Use trie in BlockBalancedTreeRamBuffer
Mike Adamson created CASSANDRA-18598: Summary: Use trie in BlockBalancedTreeRamBuffer Key: CASSANDRA-18598 URL: https://issues.apache.org/jira/browse/CASSANDRA-18598 Project: Cassandra Issue Type: Improvement Reporter: Mike Adamson The BlockBalancedTreeRamBuffer currently doesn't sort terms as they are added so the terms need sorting before they are added to the BlockBalancedTree. If we used a trie in place of the ByteBlockPool the terms would be sorted. They could also take advantage of the prefix compression in the trie which would allow larger segments on disk. If the requirement to sort was removed from the BlockBalancedTree we could remove the PointValues implementations that are needed by the Lucene sorter. This could allow for significant simplification of the codebase during the write phase. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[
https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732601#comment-17732601
]
Stefan Miklosovic commented on CASSANDRA-18555:
---
[~chovatia.jayd...@gmail.com] yeah I think we need to return back to that and
tweak few things around + propagate it to nodetool info. I do not see that in
your PR.
I will keep you as a co-author to reflect your ideas you contributed.
The PR is here [https://github.com/apache/cassandra/pull/2390/files]
It looks like this in nodetool info:
{code:java}
Bootstrap state: COMPLETED
Decommission failed: false
{code}
When decommission failed it will be:
{code:java}
Bootstrap state: COMPLETED
Decommission failed: true
{code}
and when it is decommissioned it will be:
{code:java}
Bootstrap state: DECOMMISSIONED
Decommission failed: false
{code}
There is also interesting cornercase when we try to decommission a node which
was already decommissioned successfully. That should just return and log and no
additional logic should be executed.
There is also "isDecommissionFailed" on StorageServiceMBean added to query this
via JMX in general.
I will kindly re-assign you to this ticket and ask you to see if it works for
you as you are the person who are going to use this feature primarily.
> A new nodetool/JMX command that tells whether node's decommission failed or
> not
> ---
>
> Key: CASSANDRA-18555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18555
> Project: Cassandra
> Issue Type: Task
> Components: Observability/JMX
>Reporter: Jaydeepkumar Chovatia
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently, when a node is being decommissioned and if any failure happens,
> then an exception is thrown back to the caller.
> But Cassandra's decommission takes considerable time ranging from minutes to
> hours to days. There are various scenarios in that the caller may need to
> probe the status again:
> * The caller times out
> * It is not possible to keep the caller hanging for such a long time
> And If the caller does not know what happened internally, then it cannot
> retry, etc., leading to other issues.
> So, in this ticket, I am going to add a new nodetool/JMX command that can be
> invoked by the caller anytime, and it will return the correct status.
> It might look like a smaller change, but when we need to operate Cassandra at
> scale in a large-scale fleet, then this becomes a bottleneck and require
> constant operator intervention.
--
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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-18555: - Assignee: Jaydeepkumar Chovatia (was: Stefan Miklosovic) > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18555: -- Test and Documentation Plan: added jvm dtest + ci (was: Pending) Status: Patch Available (was: In Progress) > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732602#comment-17732602 ] Brandon Williams commented on CASSANDRA-18555: -- bq. There is also interesting cornercase when we try to decommission a node which was already decommissioned successfully. I assume you must be passing -Dcassandra.override_decommission to do this? > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[
https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732609#comment-17732609
]
Stefan Miklosovic commented on CASSANDRA-18555:
---
AFAIK that property is there if you want to join a node which was
decommissioned. I am talking about decommissioning a node which you
decommissioned and you want to execute decommissioning again.
The trunk's logic is like this:
{code:java}
private void prepareToJoin() throws ConfigurationException
{
if (!joined)
{
Map appStates = new
EnumMap<>(ApplicationState.class);
if (SystemKeyspace.wasDecommissioned())
{
if (OVERRIDE_DECOMMISSION.getBoolean())
{
logger.warn("This node was decommissioned, but overriding by
operator request.");
SystemKeyspace.setBootstrapState(SystemKeyspace.BootstrapState.COMPLETED);
}
else
{
throw new ConfigurationException("This node was decommissioned
and will not rejoin the ring unless -D" + OVERRIDE_DECOMMISSION.getKey() +
"=true has been set, or all
existing data is removed and the node is bootstrapped again");
}
}
{code}
> A new nodetool/JMX command that tells whether node's decommission failed or
> not
> ---
>
> Key: CASSANDRA-18555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18555
> Project: Cassandra
> Issue Type: Task
> Components: Observability/JMX
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Normal
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently, when a node is being decommissioned and if any failure happens,
> then an exception is thrown back to the caller.
> But Cassandra's decommission takes considerable time ranging from minutes to
> hours to days. There are various scenarios in that the caller may need to
> probe the status again:
> * The caller times out
> * It is not possible to keep the caller hanging for such a long time
> And If the caller does not know what happened internally, then it cannot
> retry, etc., leading to other issues.
> So, in this ticket, I am going to add a new nodetool/JMX command that can be
> invoked by the caller anytime, and it will return the correct status.
> It might look like a smaller change, but when we need to operate Cassandra at
> scale in a large-scale fleet, then this becomes a bottleneck and require
> constant operator intervention.
--
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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[
https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732609#comment-17732609
]
Stefan Miklosovic edited comment on CASSANDRA-18555 at 6/14/23 4:18 PM:
AFAIK that property is there if you want to join a node which was
decommissioned. I am talking about decommissioning a node which you
decommissioned and you want to execute decommissioning again - all of this is
done while Cassandra process is still running.
The trunk's logic is like this:
{code:java}
private void prepareToJoin() throws ConfigurationException
{
if (!joined)
{
Map appStates = new
EnumMap<>(ApplicationState.class);
if (SystemKeyspace.wasDecommissioned())
{
if (OVERRIDE_DECOMMISSION.getBoolean())
{
logger.warn("This node was decommissioned, but overriding by
operator request.");
SystemKeyspace.setBootstrapState(SystemKeyspace.BootstrapState.COMPLETED);
}
else
{
throw new ConfigurationException("This node was decommissioned
and will not rejoin the ring unless -D" + OVERRIDE_DECOMMISSION.getKey() +
"=true has been set, or all
existing data is removed and the node is bootstrapped again");
}
}
{code}
was (Author: smiklosovic):
AFAIK that property is there if you want to join a node which was
decommissioned. I am talking about decommissioning a node which you
decommissioned and you want to execute decommissioning again.
The trunk's logic is like this:
{code:java}
private void prepareToJoin() throws ConfigurationException
{
if (!joined)
{
Map appStates = new
EnumMap<>(ApplicationState.class);
if (SystemKeyspace.wasDecommissioned())
{
if (OVERRIDE_DECOMMISSION.getBoolean())
{
logger.warn("This node was decommissioned, but overriding by
operator request.");
SystemKeyspace.setBootstrapState(SystemKeyspace.BootstrapState.COMPLETED);
}
else
{
throw new ConfigurationException("This node was decommissioned
and will not rejoin the ring unless -D" + OVERRIDE_DECOMMISSION.getKey() +
"=true has been set, or all
existing data is removed and the node is bootstrapped again");
}
}
{code}
> A new nodetool/JMX command that tells whether node's decommission failed or
> not
> ---
>
> Key: CASSANDRA-18555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18555
> Project: Cassandra
> Issue Type: Task
> Components: Observability/JMX
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Normal
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently, when a node is being decommissioned and if any failure happens,
> then an exception is thrown back to the caller.
> But Cassandra's decommission takes considerable time ranging from minutes to
> hours to days. There are various scenarios in that the caller may need to
> probe the status again:
> * The caller times out
> * It is not possible to keep the caller hanging for such a long time
> And If the caller does not know what happened internally, then it cannot
> retry, etc., leading to other issues.
> So, in this ticket, I am going to add a new nodetool/JMX command that can be
> invoked by the caller anytime, and it will return the correct status.
> It might look like a smaller change, but when we need to operate Cassandra at
> scale in a large-scale fleet, then this becomes a bottleneck and require
> constant operator intervention.
--
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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732612#comment-17732612 ] Jaydeepkumar Chovatia commented on CASSANDRA-18555: --- [~smiklosovic] The latest pull request (https://github.com/apache/cassandra/pull/2390/files) you have shared perfectly works for me. > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732615#comment-17732615 ] Jaydeepkumar Chovatia commented on CASSANDRA-18555: --- [Stefan Miklosovic|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=smiklosovic], Do you want me to modify my pull request (https://github.com/apache/cassandra/pull/2374), or do we want to go ahead with your pull request (https://github.com/apache/cassandra/pull/2390/files)? > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18599) Cassandra Analytics - Upgrade to use JUnit 5
Doug Rohrer created CASSANDRA-18599: --- Summary: Cassandra Analytics - Upgrade to use JUnit 5 Key: CASSANDRA-18599 URL: https://issues.apache.org/jira/browse/CASSANDRA-18599 Project: Cassandra Issue Type: Improvement Reporter: Doug Rohrer For future work, we’d like to use some features only available in JUnit 5 (TestTemplates being the immediate need). Upgrade cassandra-analytics dependencies to JUnit 5 and fix any test issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (5143bd81e8 -> 2fcdaa5b76)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 5143bd81e8 Track the amount of read data per row new 1eccb2bc1f Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column new 2fcdaa5b76 Merge branch 'cassandra-3.11' into cassandra-4.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../statements/schema/CreateTableStatement.java| 10 +++- .../schema/CreateTableValidationTest.java | 59 ++ 3 files changed, 68 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 2fcdaa5b76b77106108579cad60226130492e37d
Merge: 5143bd81e8 1eccb2bc1f
Author: Brandon Williams
AuthorDate: Wed Jun 14 11:34:51 2023 -0500
Merge branch 'cassandra-3.11' into cassandra-4.0
CHANGES.txt| 1 +
.../statements/schema/CreateTableStatement.java| 10 +++-
.../schema/CreateTableValidationTest.java | 59 ++
3 files changed, 68 insertions(+), 2 deletions(-)
diff --cc CHANGES.txt
index e0ffe9061e,942651a37e..a7c17c7dcb
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,7 +1,10 @@@
-3.11.16
+4.0.11
+ * Track the amount of read data per row (CASSANDRA-18513)
+ * Fix Down nodes counter in nodetool describecluster (CASSANDRA-18512)
+ * Remove unnecessary shuffling of GossipDigests in
Gossiper#makeRandomGossipDigest (CASSANDRA-18546)
+Merged from 3.11:
+ * Fix error message handling when trying to use CLUSTERING ORDER with
non-clustering column (CASSANDRA-17818
* Add keyspace and table name to exception message during ColumnSubselection
deserialization (CASSANDRA-18346)
- * Remove unnecessary String.format invocation in QueryProcessor when getting
a prepared statement from cache (CASSANDRA-17202)
Merged from 3.0:
* Suppress CVE-2023-2976 (CASSANDRA-18562)
* Remove dh_python use in Debian packaging (CASSANDRA-18558)
diff --cc
src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java
index 1339ba39f7,00..78b9d6e52e
mode 100644,00..100644
---
a/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java
+++
b/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java
@@@ -1,529 -1,0 +1,535 @@@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.cql3.statements.schema;
+
+import java.util.*;
++import java.util.stream.Collectors;
+
+import com.google.common.collect.ImmutableSet;
+
+import org.apache.commons.lang3.StringUtils;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import org.apache.cassandra.audit.AuditLogContext;
+import org.apache.cassandra.audit.AuditLogEntryType;
+import org.apache.cassandra.auth.DataResource;
+import org.apache.cassandra.auth.IResource;
+import org.apache.cassandra.auth.Permission;
+import org.apache.cassandra.config.DatabaseDescriptor;
+import org.apache.cassandra.cql3.*;
+import org.apache.cassandra.db.marshal.*;
+import org.apache.cassandra.exceptions.AlreadyExistsException;
+import org.apache.cassandra.schema.*;
+import org.apache.cassandra.schema.Keyspaces.KeyspacesDiff;
+import org.apache.cassandra.service.ClientState;
+import org.apache.cassandra.service.reads.repair.ReadRepairStrategy;
+import org.apache.cassandra.transport.Event.SchemaChange;
+import org.apache.cassandra.transport.Event.SchemaChange.Change;
+import org.apache.cassandra.transport.Event.SchemaChange.Target;
+
+import static java.util.Comparator.comparing;
+
+import static com.google.common.collect.Iterables.concat;
+
+public final class CreateTableStatement extends AlterSchemaStatement
+{
+private static final Logger logger =
LoggerFactory.getLogger(CreateTableStatement.class);
+private final String tableName;
+
+private final Map rawColumns;
+private final Set staticColumns;
+private final List partitionKeyColumns;
+private final List clusteringColumns;
+
+private final LinkedHashMap clusteringOrder;
+private final TableAttributes attrs;
+
+private final boolean ifNotExists;
+private final boolean useCompactStorage;
+
+public CreateTableStatement(String keyspaceName,
+String tableName,
+
+Map
rawColumns,
+Set staticColumns,
+List partitionKeyColumns,
+List clusteringColumns,
+
+LinkedHashMap
clusteringOrder,
+
[cassandra] branch cassandra-4.1 updated (b7c00d7d13 -> 1f6b37d189)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from b7c00d7d13 Slow builds due to checkstyle new 1eccb2bc1f Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column new 2fcdaa5b76 Merge branch 'cassandra-3.11' into cassandra-4.0 new 1f6b37d189 Merge branch 'cassandra-4.0' into cassandra-4.1 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../statements/schema/CreateTableStatement.java| 10 +++- .../schema/CreateTableValidationTest.java | 59 ++ 3 files changed, 68 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into cassandra-4.1
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 1f6b37d18994ffd35b9dd62b5877f403cbb95cc8 Merge: b7c00d7d13 2fcdaa5b76 Author: Brandon Williams AuthorDate: Wed Jun 14 11:35:40 2023 -0500 Merge branch 'cassandra-4.0' into cassandra-4.1 CHANGES.txt| 1 + .../statements/schema/CreateTableStatement.java| 10 +++- .../schema/CreateTableValidationTest.java | 59 ++ 3 files changed, 68 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated: Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new 1eccb2bc1f Fix error message handling when trying to use CLUSTERING
ORDER with non-clustering column
1eccb2bc1f is described below
commit 1eccb2bc1ff69817b2fc8d16a4707b64d8b514e7
Author: ningzi.zhan
AuthorDate: Thu Jun 8 14:59:17 2023 -0700
Fix error message handling when trying to use CLUSTERING ORDER with
non-clustering column
Patch by Ningzi Zhan and Tomasz Lasica; reviewed by brandonwilliams,
edimitrova and Maxwell Guo for CASSANDRA-17818
Co-Authored-By: Tomek Lasica
---
CHANGES.txt| 1 +
.../cql3/statements/CreateTableStatement.java | 12 -
.../schema/CreateTableValidationTest.java | 59 ++
3 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index cd7fe124ea..942651a37e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.11.16
+ * Fix error message handling when trying to use CLUSTERING ORDER with
non-clustering column (CASSANDRA-17818
* Add keyspace and table name to exception message during ColumnSubselection
deserialization (CASSANDRA-18346)
* Remove unnecessary String.format invocation in QueryProcessor when getting
a prepared statement from cache (CASSANDRA-17202)
Merged from 3.0:
diff --git
a/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
index 90ed288f1e..ba6a153691 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java
@@ -20,6 +20,8 @@ package org.apache.cassandra.cql3.statements;
import java.nio.ByteBuffer;
import java.util.*;
import java.util.regex.Pattern;
+import java.util.stream.Collectors;
+
import com.google.common.collect.HashMultiset;
import com.google.common.collect.Multiset;
import org.apache.commons.lang3.StringUtils;
@@ -342,8 +344,14 @@ public class CreateTableStatement extends
SchemaAlteringStatement
// If we give a clustering order, we must explicitly do so for all
aliases and in the order of the PK
if (!properties.definedOrdering.isEmpty())
{
-if (properties.definedOrdering.size() > columnAliases.size())
-throw new InvalidRequestException("Only clustering key
columns can be defined in CLUSTERING ORDER directive");
+List nonClusterColumn =
properties.definedOrdering.keySet().stream()
+
.filter((id) -> !columnAliases.contains(id))
+
.collect(Collectors.toList());
+
+if (!nonClusterColumn.isEmpty())
+{
+throw new InvalidRequestException("Only clustering key
columns can be defined in CLUSTERING ORDER directive: " + nonClusterColumn + "
are not clustering columns");
+}
int i = 0;
for (ColumnIdentifier id : properties.definedOrdering.keySet())
diff --git
a/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java
b/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java
index 9708552382..7ff313c425 100644
--- a/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java
+++ b/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java
@@ -20,8 +20,11 @@ package org.apache.cassandra.schema;
import org.apache.cassandra.cql3.CQLTester;
import org.apache.cassandra.exceptions.ConfigurationException;
+import org.apache.cassandra.exceptions.InvalidRequestException;
+
import org.junit.Test;
+import static org.assertj.core.api.Assertions.assertThatExceptionOfType;
import static org.junit.Assert.fail;
public class CreateTableValidationTest extends CQLTester
@@ -48,4 +51,60 @@ public class CreateTableValidationTest extends CQLTester
// sanity check
createTable("CREATE TABLE %s (a int PRIMARY KEY, b int) WITH
bloom_filter_fp_chance = 0.1");
}
+
+@Test
+public void testCreateTableOnSelectedClusteringColumn()
+{
+createTable("CREATE TABLE %s (pk int, ck1 int, ck2 int, v int, PRIMARY
KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC);");
+}
+
+@Test
+public void testCreateTableOnAllClusteringColumns()
+{
+createTable("CREATE TABLE %s (pk int, ck1 int, ck2 int, v int, PRIMARY
KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC);");
+}
+@Test
+public void testCreateTableErrorOnNonClusteringKey()
+{
+String expectedMessage =
[cassandra] branch trunk updated (1d961679a0 -> 4f5cb2a6fa)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 1d961679a0 Switch Java and Python upgrade tests from running on JDK8 to JDK11 in CircleCI patch by Ekaterina Dimitrova; reviewed by Berenguer Blasi for CASSANDRA-18285 new 1eccb2bc1f Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column new 2fcdaa5b76 Merge branch 'cassandra-3.11' into cassandra-4.0 new 1f6b37d189 Merge branch 'cassandra-4.0' into cassandra-4.1 new 4f5cb2a6fa Merge branch 'cassandra-4.1' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../statements/schema/CreateTableStatement.java| 10 +++- .../schema/CreateTableValidationTest.java | 59 ++ 3 files changed, 68 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 4f5cb2a6fa287ab2d388c636655d6e764c648084
Merge: 1d961679a0 1f6b37d189
Author: Brandon Williams
AuthorDate: Wed Jun 14 11:36:02 2023 -0500
Merge branch 'cassandra-4.1' into trunk
CHANGES.txt| 1 +
.../statements/schema/CreateTableStatement.java| 10 +++-
.../schema/CreateTableValidationTest.java | 59 ++
3 files changed, 68 insertions(+), 2 deletions(-)
diff --cc
src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java
index 45f23e9bfc,3799178747..6e93929d78
---
a/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java
+++
b/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java
@@@ -18,9 -18,8 +18,10 @@@
package org.apache.cassandra.cql3.statements.schema;
import java.util.*;
+ import java.util.stream.Collectors;
+import javax.annotation.Nullable;
+
import com.google.common.collect.ImmutableSet;
import org.apache.commons.lang3.StringUtils;
@@@ -255,13 -244,18 +256,18 @@@ public final class CreateTableStatemen
clusteringColumns.forEach(column ->
{
-CQL3Type type = columns.remove(column);
+ColumnProperties columnProperties = columns.remove(column);
boolean reverse = !clusteringOrder.getOrDefault(column, true);
-clusteringTypes.add(reverse ?
ReversedType.getInstance(type.getType()) : type.getType());
+clusteringColumnProperties.add(reverse ?
columnProperties.withReversedType() : columnProperties);
});
- if (clusteringOrder.size() > clusteringColumns.size())
- throw ire("Only clustering columns can be defined in CLUSTERING
ORDER directive");
+ List nonClusterColumn =
clusteringOrder.keySet().stream()
+ .filter((id)
-> !clusteringColumns.contains(id))
+
.collect(Collectors.toList());
+ if (!nonClusterColumn.isEmpty())
+ {
+ throw ire("Only clustering key columns can be defined in
CLUSTERING ORDER directive: " + nonClusterColumn + " are not clustering
columns");
+ }
int n = 0;
for (ColumnIdentifier id : clusteringOrder.keySet())
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[
https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732630#comment-17732630
]
Stefan Miklosovic commented on CASSANDRA-18555:
---
I will go with mine. I have few cosmetic fixes to add.
For example, if we do this in the console:
{code:java}
$ nodetool decommission
$ nodetool decommission{code}
If the first invocation finishes OK, I think we should log on the second
invocation that it is already decommissioned. What value there is in executing
decommissioning after it is successfully decommissioned?
With the current patch, the second operation returns immediately. But a user is
not notified about the fact it was decommissioned already.
On the other hand if we want to follow *nix principles, this should not emit
anything as, technically, it decommissioned for the second time too. But I
think that a user may find it handy to know that it was already decommissioned
so executing it for the second time will not achieve anything.
> A new nodetool/JMX command that tells whether node's decommission failed or
> not
> ---
>
> Key: CASSANDRA-18555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18555
> Project: Cassandra
> Issue Type: Task
> Components: Observability/JMX
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Normal
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently, when a node is being decommissioned and if any failure happens,
> then an exception is thrown back to the caller.
> But Cassandra's decommission takes considerable time ranging from minutes to
> hours to days. There are various scenarios in that the caller may need to
> probe the status again:
> * The caller times out
> * It is not possible to keep the caller hanging for such a long time
> And If the caller does not know what happened internally, then it cannot
> retry, etc., leading to other issues.
> So, in this ticket, I am going to add a new nodetool/JMX command that can be
> invoked by the caller anytime, and it will return the correct status.
> It might look like a smaller change, but when we need to operate Cassandra at
> scale in a large-scale fleet, then this becomes a bottleneck and require
> constant operator intervention.
--
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
]
Brandon Williams updated CASSANDRA-17818:
-
Fix Version/s: 3.11.16
4.0.11
4.1.3
5.0
(was: 3.11.x)
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/1eccb2bc1ff69817b2fc8d16a4707b64d8b514e7
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, -nits + tomek. Thanks folks!
> 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] [Commented] (CASSANDRA-18599) Cassandra Analytics - Upgrade to use JUnit 5
[ https://issues.apache.org/jira/browse/CASSANDRA-18599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732639#comment-17732639 ] Brandon Williams commented on CASSANDRA-18599: -- Note that adding deps requires ML discussion. > Cassandra Analytics - Upgrade to use JUnit 5 > > > Key: CASSANDRA-18599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18599 > Project: Cassandra > Issue Type: Improvement >Reporter: Doug Rohrer >Priority: Normal > > For future work, we’d like to use some features only available in JUnit 5 > (TestTemplates being the immediate need). > Upgrade cassandra-analytics dependencies to JUnit 5 and fix any test issues. -- 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-18254) sstabledump for secondary index sstable error
[ https://issues.apache.org/jira/browse/CASSANDRA-18254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18254: -- Resolution: (was: Won't Fix) Status: Open (was: Resolved) > sstabledump for secondary index sstable error > - > > Key: CASSANDRA-18254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18254 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index, Local/SSTable, Tool/sstable >Reporter: Maxwell Guo >Assignee: Maxwell Guo >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0, 4.1.x, 5.0 > > Time Spent: 1h > Remaining Estimate: 0h > > As [CASSANDRA-17698|https://issues.apache.org/jira/browse/CASSANDRA-17698] > described , for older branches we open a new ticket and fixed just > JSON-printing the failing clustering key as raw bytes. > for Cassandra version that can change the sstable version (may be 5.0) , the > patch for CASSANDRA-17698 will be applied. -- 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-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732575#comment-17732575
]
Ekaterina Dimitrova edited comment on CASSANDRA-18540 at 6/14/23 4:47 PM:
--
{quote}but didn't think a
[multiplexer|https://app.circleci.com/pipelines/github/driftx/cassandra/1061/workflows/648e3ed0-32f3-43ff-930e-c05b1bfa9f9e/jobs/29939]
check on trunk would hurt just to be sure we haven't introduced any flakiness.
{quote}
I was thinking it was pretty deterministic, but you are correct that the world
of Cassandra never stops to surprise us. Good call, thanks!
Starting commit soon
was (Author: e.dimitrova):
{quote}but didn't think a
[multiplexer|https://app.circleci.com/pipelines/github/driftx/cassandra/1061/workflows/648e3ed0-32f3-43ff-930e-c05b1bfa9f9e/jobs/29939]
check on trunk would hurt just to be sure we haven't introduced any flakiness.
{quote}
I was thinking it is pretty deterministic, but you are right that world of
Cassandra never stops to surprise us. Good call, thanks!
Starting commit soon
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, after
> 2021-Apr JDK8 dropped TLSv1.1 which led to a fix in
> [cassandra-build|https://github.com/apache/cassandra-builds/commit/d1a3a0c59b3c5c17697d6a6656cd5d4f3a1cdbe9]
> docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work
[jira] [Updated] (CASSANDRA-18254) sstabledump for secondary index sstable error
[ https://issues.apache.org/jira/browse/CASSANDRA-18254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18254: -- Fix Version/s: 5.x (was: 5.0) > sstabledump for secondary index sstable error > - > > Key: CASSANDRA-18254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18254 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index, Local/SSTable, Tool/sstable >Reporter: Maxwell Guo >Assignee: Maxwell Guo >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0, 4.1.x, 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > As [CASSANDRA-17698|https://issues.apache.org/jira/browse/CASSANDRA-17698] > described , for older branches we open a new ticket and fixed just > JSON-printing the failing clustering key as raw bytes. > for Cassandra version that can change the sstable version (may be 5.0) , the > patch for CASSANDRA-17698 will be applied. -- 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-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732643#comment-17732643
]
Andres de la Peña commented on CASSANDRA-17698:
---
[~maxwellguo] Thanks for the changes.
I have added a couple of suggestions on the PR, put them on [this
commit|https://github.com/adelapena/cassandra/commit/989058a17ed5475a24766b52dd2dae19116560e7],
and started CI:
||Branch||CI||
|[trunk|https://github.com/adelapena/cassandra/commits/17698-trunk-review-feedback]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2959/workflows/d7bc1213-5a98-48fe-bffc-a20cea35cfef]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2959/workflows/d1f162cf-9ffa-4da0-9ff7-d9a3b5a35477]|
I'm also reopening CASSANDRA-18254, since we don't have a fix nor a workaround
for 3.0, 3.11, 4.0 and 4.1, nor for 5.0 in compatibility mode.
[~blambov] [~smiklosovic] are you ok with the changes?
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 12h 50m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {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-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18540:
-
Reviewers: Brandon Williams, Ekaterina Dimitrova (was: Ekaterina Dimitrova)
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, after
> 2021-Apr JDK8 dropped TLSv1.1 which led to a fix in
> [cassandra-build|https://github.com/apache/cassandra-builds/commit/d1a3a0c59b3c5c17697d6a6656cd5d4f3a1cdbe9]
> docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
--
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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732644#comment-17732644 ] Jaydeepkumar Chovatia commented on CASSANDRA-18555: --- Sounds good! > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18599) Cassandra Analytics - Upgrade to use JUnit 5
[ https://issues.apache.org/jira/browse/CASSANDRA-18599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732645#comment-17732645 ] Josh McKenzie commented on CASSANDRA-18599: --- Not to be pedantic (which is always how the best pedantry starts), but does that same bar hold for _upgrading_ an existing library vs. adding? We're pretty slow on the draw upgrading deps and also pretty unstructured. Might be worth revisiting and thinking about in general. > Cassandra Analytics - Upgrade to use JUnit 5 > > > Key: CASSANDRA-18599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18599 > Project: Cassandra > Issue Type: Improvement >Reporter: Doug Rohrer >Priority: Normal > > For future work, we’d like to use some features only available in JUnit 5 > (TestTemplates being the immediate need). > Upgrade cassandra-analytics dependencies to JUnit 5 and fix any test issues. -- 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-18599) Cassandra Analytics - Upgrade to use JUnit 5
[ https://issues.apache.org/jira/browse/CASSANDRA-18599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732646#comment-17732646 ] Brandon Williams commented on CASSANDRA-18599: -- Ah, yeah, I wouldn't hold it for upgrades (and we haven't been, afaik) so nevermind me. > Cassandra Analytics - Upgrade to use JUnit 5 > > > Key: CASSANDRA-18599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18599 > Project: Cassandra > Issue Type: Improvement >Reporter: Doug Rohrer >Priority: Normal > > For future work, we’d like to use some features only available in JUnit 5 > (TestTemplates being the immediate need). > Upgrade cassandra-analytics dependencies to JUnit 5 and fix any test issues. -- 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-18599) Cassandra Analytics - Upgrade to use JUnit 5
[ https://issues.apache.org/jira/browse/CASSANDRA-18599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732650#comment-17732650 ] Doug Rohrer commented on CASSANDRA-18599: - Also note that this is only for the Analytics library, not Cassandra itself, in case that wasn't clear. > Cassandra Analytics - Upgrade to use JUnit 5 > > > Key: CASSANDRA-18599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18599 > Project: Cassandra > Issue Type: Improvement >Reporter: Doug Rohrer >Priority: Normal > > For future work, we’d like to use some features only available in JUnit 5 > (TestTemplates being the immediate need). > Upgrade cassandra-analytics dependencies to JUnit 5 and fix any test issues. -- 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&focusedCommentId=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] [Commented] (CASSANDRA-18599) Cassandra Analytics - Upgrade to use JUnit 5
[ https://issues.apache.org/jira/browse/CASSANDRA-18599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732651#comment-17732651 ] Ekaterina Dimitrova commented on CASSANDRA-18599: - The only case I've seen people starting ML threads about upgrading a dependency is if there will be breaking changes or if we will add new transitive dependencies. > Cassandra Analytics - Upgrade to use JUnit 5 > > > Key: CASSANDRA-18599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18599 > Project: Cassandra > Issue Type: Improvement >Reporter: Doug Rohrer >Priority: Normal > > For future work, we’d like to use some features only available in JUnit 5 > (TestTemplates being the immediate need). > Upgrade cassandra-analytics dependencies to JUnit 5 and fix any test issues. -- 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-18599) Cassandra Analytics - Upgrade to use JUnit 5
[
https://issues.apache.org/jira/browse/CASSANDRA-18599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732653#comment-17732653
]
Ekaterina Dimitrova commented on CASSANDRA-18599:
-
{quote}Also note that this is only for the Analytics library, not Cassandra
itself, in case that wasn't clear.
{quote}
CASSANDRA-16630 will be for Cassandra, and it seems like an adventure.
> Cassandra Analytics - Upgrade to use JUnit 5
>
>
> Key: CASSANDRA-18599
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18599
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Doug Rohrer
>Priority: Normal
>
> For future work, we’d like to use some features only available in JUnit 5
> (TestTemplates being the immediate need).
> Upgrade cassandra-analytics dependencies to JUnit 5 and fix any test issues.
--
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-18599) Cassandra Analytics - Upgrade to use JUnit 5
[ https://issues.apache.org/jira/browse/CASSANDRA-18599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732655#comment-17732655 ] Doug Rohrer commented on CASSANDRA-18599: - Yeah - just the analytics project was a bit of a challenge, but it's nowhere near as large as C* itself. > Cassandra Analytics - Upgrade to use JUnit 5 > > > Key: CASSANDRA-18599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18599 > Project: Cassandra > Issue Type: Improvement >Reporter: Doug Rohrer >Priority: Normal > > For future work, we’d like to use some features only available in JUnit 5 > (TestTemplates being the immediate need). > Upgrade cassandra-analytics dependencies to JUnit 5 and fix any test issues. -- 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
[GitHub] [cassandra-analytics] JeetKunDoug opened a new pull request, #5: CASSANDRA-18599 Upgrade to JUnit 5
JeetKunDoug opened a new pull request, #5: URL: https://github.com/apache/cassandra-analytics/pull/5 For future work, we’d like to use some features only available in JUnit 5 (TestTemplates being the immediate need). Upgrade cassandra-analytics dependencies to JUnit 5 and fix any test issues. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (2497a48b2 -> d6573be6a)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 2497a48b2 generate docs for 1b144e50 new d6573be6a generate docs for 1b144e50 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (2497a48b2) \ N -- N -- N refs/heads/asf-staging (d6573be6a) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (2fcdaa5b76 -> c37bcbf7e9)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 2fcdaa5b76 Merge branch 'cassandra-3.11' into cassandra-4.0 add c37bcbf7e9 Include TLSv1.2 in negotiatedProtocolMustBeAcceptedProtocolTest Add a comment about the use of disabled TLSv1.1 with JDK 8 and higher to negotiatedProtocolMustBeAcceptedProtocolTest No new revisions were added by this update. Summary of changes: .../test/InternodeEncryptionOptionsTest.java | 19 +++ .../test/NativeTransportEncryptionOptionsTest.java| 17 ++--- 2 files changed, 29 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (1f6b37d189 -> 622397e7e5)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 1f6b37d189 Merge branch 'cassandra-4.0' into cassandra-4.1 add c37bcbf7e9 Include TLSv1.2 in negotiatedProtocolMustBeAcceptedProtocolTest Add a comment about the use of disabled TLSv1.1 with JDK 8 and higher to negotiatedProtocolMustBeAcceptedProtocolTest add 622397e7e5 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: .../test/InternodeEncryptionOptionsTest.java | 19 +++ .../test/NativeTransportEncryptionOptionsTest.java| 17 ++--- 2 files changed, 29 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (4f5cb2a6fa -> a55d4183f5)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 4f5cb2a6fa Merge branch 'cassandra-4.1' into trunk add c37bcbf7e9 Include TLSv1.2 in negotiatedProtocolMustBeAcceptedProtocolTest Add a comment about the use of disabled TLSv1.1 with JDK 8 and higher to negotiatedProtocolMustBeAcceptedProtocolTest add 622397e7e5 Merge branch 'cassandra-4.0' into cassandra-4.1 new a55d4183f5 Merge branch 'cassandra-4.1' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../test/InternodeEncryptionOptionsTest.java | 19 +++ .../test/NativeTransportEncryptionOptionsTest.java| 17 ++--- 2 files changed, 29 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit a55d4183f507fab7b254a827af0ee6cc821c5674 Merge: 4f5cb2a6fa 622397e7e5 Author: Ekaterina Dimitrova AuthorDate: Wed Jun 14 14:09:32 2023 -0400 Merge branch 'cassandra-4.1' into trunk .../test/InternodeEncryptionOptionsTest.java | 19 +++ .../test/NativeTransportEncryptionOptionsTest.java| 17 ++--- 2 files changed, 29 insertions(+), 7 deletions(-) diff --cc test/distributed/org/apache/cassandra/distributed/test/NativeTransportEncryptionOptionsTest.java index 5f2caaf695,e5f1a2174a..c8e9de69f0 --- a/test/distributed/org/apache/cassandra/distributed/test/NativeTransportEncryptionOptionsTest.java +++ b/test/distributed/org/apache/cassandra/distributed/test/NativeTransportEncryptionOptionsTest.java @@@ -18,25 -18,14 +18,26 @@@ package org.apache.cassandra.distributed.test; +import java.io.FileInputStream; +import java.io.InputStream; import java.net.InetAddress; +import java.security.KeyStore; import java.util.Collections; +import javax.net.ssl.KeyManagerFactory; +import javax.net.ssl.TrustManagerFactory; + + import com.google.common.collect.ImmutableList; import com.google.common.collect.ImmutableMap; import org.junit.Assert; +import org.junit.Rule; import org.junit.Test; +import org.junit.rules.ExpectedException; +import com.datastax.driver.core.SSLOptions; +import com.datastax.driver.core.exceptions.NoHostAvailableException; +import com.datastax.shaded.netty.handler.ssl.SslContext; +import com.datastax.shaded.netty.handler.ssl.SslContextBuilder; import org.apache.cassandra.distributed.Cluster; import org.apache.cassandra.distributed.api.Feature; - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732681#comment-17732681
]
Ekaterina Dimitrova commented on CASSANDRA-18540:
-
To https://github.com/apache/cassandra
[2fcdaa5b76..c37bcbf7e9 cassandra-4.0 ->
cassandra-4.0|https://github.com/apache/cassandra/commit/c37bcbf7e9d2b3c8ec4e93aa661d358c9f382edf]
[1f6b37d189..622397e7e5 cassandra-4.1 ->
cassandra-4.1|https://github.com/apache/cassandra/commit/622397e7e5a2ab8a0bd902b0155a5379e2bbfab4]
[4f5cb2a6fa..a55d4183f5 trunk ->
trunk|https://github.com/apache/cassandra/commit/a55d4183f507fab7b254a827af0ee6cc821c5674]
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, after
> 2021-Apr JDK8 dropped TLSv1.1 which led to a fix in
> [cassandra-build|https://github.com/apache/cassandra-builds/commit/d1a3a0c59b3c5c17697d6a6656cd5d4f3a1cdbe9]
> docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
[jira] [Updated] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18540:
Fix Version/s: 4.0.11
4.1.3
5.0
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
Since Version: 4.0.4
Source Control Link:
https://github.com/apache/cassandra/commit/c37bcbf7e9d2b3c8ec4e93aa661d358c9f382edf
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 4.0.11, 4.1.3, 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, after
> 2021-Apr JDK8 dropped TLSv1.1 which led to a fix in
> [cassandra-build|https://github.com/apache/cassandra-builds/commit/d1a3a0c59b3c5c17697d6a6656cd5d4f3a1cdbe9]
> docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
--
[jira] [Comment Edited] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732681#comment-17732681
]
Ekaterina Dimitrova edited comment on CASSANDRA-18540 at 6/14/23 6:23 PM:
--
To [https://github.com/apache/cassandra]
[2fcdaa5b76..c37bcbf7e9 cassandra-4.0 ->
cassandra-4.0|https://github.com/apache/cassandra/commit/c37bcbf7e9d2b3c8ec4e93aa661d358c9f382edf]
[1f6b37d189..622397e7e5 cassandra-4.1 ->
cassandra-4.1|https://github.com/apache/cassandra/commit/622397e7e5a2ab8a0bd902b0155a5379e2bbfab4]
[4f5cb2a6fa..a55d4183f5 trunk ->
trunk|https://github.com/apache/cassandra/commit/a55d4183f507fab7b254a827af0ee6cc821c5674]
Thank you both!
was (Author: e.dimitrova):
To https://github.com/apache/cassandra
[2fcdaa5b76..c37bcbf7e9 cassandra-4.0 ->
cassandra-4.0|https://github.com/apache/cassandra/commit/c37bcbf7e9d2b3c8ec4e93aa661d358c9f382edf]
[1f6b37d189..622397e7e5 cassandra-4.1 ->
cassandra-4.1|https://github.com/apache/cassandra/commit/622397e7e5a2ab8a0bd902b0155a5379e2bbfab4]
[4f5cb2a6fa..a55d4183f5 trunk ->
trunk|https://github.com/apache/cassandra/commit/a55d4183f507fab7b254a827af0ee6cc821c5674]
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 4.0.11, 4.1.3, 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, after
> 2021-Apr JDK8 dropped TLSv1.1 which led to a fix in
> [cassandra-build|https://github.com/apache/cassandra-builds/commit/d1a3a0c59b3c5c17697d6a6656cd5d
[jira] [Updated] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18540:
Since Version: (was: 4.0.4)
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 4.0.11, 4.1.3, 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, after
> 2021-Apr JDK8 dropped TLSv1.1 which led to a fix in
> [cassandra-build|https://github.com/apache/cassandra-builds/commit/d1a3a0c59b3c5c17697d6a6656cd5d4f3a1cdbe9]
> docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
--
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-18588) Slow builds due to checkstyle
[
https://issues.apache.org/jira/browse/CASSANDRA-18588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732685#comment-17732685
]
Ekaterina Dimitrova commented on CASSANDRA-18588:
-
{quote}This benefits mainly local dev imo where {{realclean}} is not run so
often.
{quote}
Unfortunately, going backwards in branches almost always requires it but I
still see a value. Thank you for working it out.
{quote}If we're happy with the approach I'll push the rest of the PRs
{quote}
What happened to the other branches? Pre-4.1?
> Slow builds due to checkstyle
> -
>
> Key: CASSANDRA-18588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18588
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1.3, 5.0
>
>
> Builds are terribly slow atm due to checkstyle. But there's an option to
> cache results and only run on the latest changed files to avoid running over
> the same files over and over again.
> This brings build times from the current 1m30s to the old 5s.
--
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
