[jira] [Commented] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553446#comment-17553446 ] Tanuj Nayak commented on CASSANDRA-17617: - I added your changes to my PR. If you're happy with that you can just move this one on if you please. > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1-rc > > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17301) Test Failure: org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553501#comment-17553501
]
Berenguer Blasi commented on CASSANDRA-17301:
-
+1 LGTM. It's difficult to navigate jenkins status these days but I don't see
how this could affect it. Let's raise it and we can reopen if it reapears one
day.
> Test Failure:
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
> ---
>
> Key: CASSANDRA-17301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17301
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/316/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/suddenDisconnect_cdc/
> See same failure on
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-compression
> as well
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> {code}
> Stacktrace
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:279)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$suddenDisconnect$29(ProxyHandlerConnectionsTest.java:237)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:385)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:344)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect(ProxyHandlerConnectionsTest.java:225)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> DEBUG [main] 2022-01-23 13:09:13,779 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:897 - Java
> version: 8
> DEBUG [main] 2022-01-23 13:09:13,807 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] 2022-01-23 13:09:13,808 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> ...[truncated 417667 chars]...
> ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.decode(InboundConnectionInitiator.java:235)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 29 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553506#comment-17553506 ] Berenguer Blasi commented on CASSANDRA-17617: - ||PR||CI|| |[3.11|https://github.com/apache/cassandra/pull/1679]|[j8|https://app.circleci.com/pipelines/github/bereng/cassandra/684/workflows/5a872292-e0c3-4695-b4e8-f8e024da101a]| |[4.0|https://github.com/apache/cassandra/pull/1680]|[j8|https://app.circleci.com/pipelines/github/bereng/cassandra/681/workflows/c48d3dd4-a9b9-47f8-8369-c600b91a8e70] [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/681/workflows/f867d2e9-2077-4937-97fe-8ea5bedba3e7]| |[4.1|https://github.com/apache/cassandra/pull/1681]|[j8|https://app.circleci.com/pipelines/github/bereng/cassandra/682/workflows/846f8436-4c18-4ce4-95ca-e621a2626372] [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/682/workflows/dbb38461-9153-49c2-a149-19647adff094]| |[trunk|https://github.com/apache/cassandra/pull/1664]|[j8|https://app.circleci.com/pipelines/github/bereng/cassandra/685/workflows/83581109-4037-46ae-87dd-6a17d44f1ee8] [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/685/workflows/8a813d5a-7bec-4ec6-a95f-7683c72bfe01]| > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1-rc > > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553509#comment-17553509 ] Berenguer Blasi edited comment on CASSANDRA-17617 at 6/13/22 10:26 AM: --- bq. I added your changes to my PR. If you're happy with that you can just move this one on if you please. Thanks [~tanujnay] yes I noticed that. But I have to put up PRs anyway for all maintained versions, add CI and then another committer/reviewer to +1 that, which is the table I just posted. Then I'll merge all that with proper attribution to yoy ofc! :-) was (Author: bereng): bq. I added your changes to my PR. If you're happy with that you can just move this one on if you please. Thanks [~tanujnay] yes I noticed that. But I have to put up PRs anyway for all maintained versions, add CI and then another committer/reviewer to +1 that, which is the table I just posted. Then I'll merge all that with proper attribution ofc! :-) > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1-rc > > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553509#comment-17553509 ] Berenguer Blasi commented on CASSANDRA-17617: - bq. I added your changes to my PR. If you're happy with that you can just move this one on if you please. Thanks [~tanujnay] yes I noticed that. But I have to put up PRs anyway for all maintained versions, add CI and then another committer/reviewer to +1 that, which is the table I just posted. Then I'll merge all that with proper attribution ofc! :-) > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1-rc > > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553509#comment-17553509 ] Berenguer Blasi edited comment on CASSANDRA-17617 at 6/13/22 10:26 AM: --- bq. I added your changes to my PR. If you're happy with that you can just move this one on if you please. Thanks [~tanujnay] yes I noticed that. But I have to put up PRs anyway for all maintained versions, add CI and then another committer/reviewer to +1 that, which is the table I just posted. Then I'll merge all that with proper attribution to you ofc! :-) was (Author: bereng): bq. I added your changes to my PR. If you're happy with that you can just move this one on if you please. Thanks [~tanujnay] yes I noticed that. But I have to put up PRs anyway for all maintained versions, add CI and then another committer/reviewer to +1 that, which is the table I just posted. Then I'll merge all that with proper attribution to yoy ofc! :-) > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1-rc > > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553514#comment-17553514 ] Brandon Williams commented on CASSANDRA-17617: -- +1, thanks for driving this to completion. > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1-rc > > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (fd547aff55 -> 67632edc51)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from fd547aff55 Merge branch 'cassandra-4.0' into cassandra-4.1 add 2531dd1eba remove ssl storage port from sstableloader add 67632edc51 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + .../cassandra/tools/BulkLoadConnectionFactory.java| 19 +-- src/java/org/apache/cassandra/tools/BulkLoader.java | 8 +++- .../org/apache/cassandra/tools/LoaderOptions.java | 15 --- .../cassandra/utils/NativeSSTableLoaderClient.java| 5 ++--- .../test/SSTableLoaderEncryptionOptionsTest.java | 6 -- .../org/apache/cassandra/tools/BulkLoaderTest.java| 10 +- 7 files changed, 24 insertions(+), 40 deletions(-) - 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 (cd0a40d09e -> 2531dd1eba)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from cd0a40d09e Allow java 11 in redhat packaging add 2531dd1eba remove ssl storage port from sstableloader No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/tools/BulkLoadConnectionFactory.java | 18 -- src/java/org/apache/cassandra/tools/BulkLoader.java| 8 +++- src/java/org/apache/cassandra/tools/LoaderOptions.java | 15 --- .../cassandra/utils/NativeSSTableLoaderClient.java | 5 ++--- .../test/SSTableLoaderEncryptionOptionsTest.java | 6 -- .../org/apache/cassandra/tools/BulkLoaderTest.java | 10 +- 7 files changed, 23 insertions(+), 40 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (067f4c7461 -> 56dbc68528)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 067f4c7461 Merge branch 'cassandra-4.1' into trunk add 2531dd1eba remove ssl storage port from sstableloader add 67632edc51 Merge branch 'cassandra-4.0' into cassandra-4.1 new 56dbc68528 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: CHANGES.txt | 1 + .../cassandra/tools/BulkLoadConnectionFactory.java| 19 +-- src/java/org/apache/cassandra/tools/BulkLoader.java | 8 +++- .../org/apache/cassandra/tools/LoaderOptions.java | 15 --- .../cassandra/utils/NativeSSTableLoaderClient.java| 5 ++--- .../test/SSTableLoaderEncryptionOptionsTest.java | 6 -- .../org/apache/cassandra/tools/BulkLoaderTest.java| 10 +- 7 files changed, 24 insertions(+), 40 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17602) sstableloader not respecting conf-path flag
[
https://issues.apache.org/jira/browse/CASSANDRA-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553517#comment-17553517
]
Stefan Miklosovic commented on CASSANDRA-17602:
---
trunk
https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-17602-trunk
4.1
https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-17602-4.1
4.0
https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-17602
> sstableloader not respecting conf-path flag
> ---
>
> Key: CASSANDRA-17602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17602
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Aswin Karthik
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Hello,
> sstableloader does not seem to respect the config file flag (-f) and the
> storage port flag.
>
> We run our cluster on a different storage port with encryption. We construct
> a YAML with {{server_encryption_options}} and {{client_encryption_options}}
> and pass the storage port flag (both {{-sp}} and {{-ssp}}).
>
> However, we noticed that both the storage port flag and encryption settings
> are getting picked from the default config file {{conf/cassandra.yaml}} and
> ends up connecting to 7000 port unencrypted. As a workaround, we have added
> the storage port configuration to the YAML and copy our configuration file
> and overwrite the {{conf/cassandra.yaml}} and it is working now.
>
> Also to be noted that using the {{-f}} works in Cassandra 3.x. The bug seems
> to be present in 4.x versions only.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 56dbc68528c92b9ccaaa34ab19640a7613124828 Merge: 067f4c7461 67632edc51 Author: Stefan Miklosovic AuthorDate: Mon Jun 13 10:57:49 2022 +0200 Merge branch 'cassandra-4.1' into trunk CHANGES.txt | 1 + .../cassandra/tools/BulkLoadConnectionFactory.java| 19 +-- src/java/org/apache/cassandra/tools/BulkLoader.java | 8 +++- .../org/apache/cassandra/tools/LoaderOptions.java | 15 --- .../cassandra/utils/NativeSSTableLoaderClient.java| 5 ++--- .../test/SSTableLoaderEncryptionOptionsTest.java | 6 -- .../org/apache/cassandra/tools/BulkLoaderTest.java| 10 +- 7 files changed, 24 insertions(+), 40 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17602) sstableloader not respecting conf-path flag
[
https://issues.apache.org/jira/browse/CASSANDRA-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17602:
--
Status: Ready to Commit (was: Review In Progress)
> sstableloader not respecting conf-path flag
> ---
>
> Key: CASSANDRA-17602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17602
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Aswin Karthik
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Hello,
> sstableloader does not seem to respect the config file flag (-f) and the
> storage port flag.
>
> We run our cluster on a different storage port with encryption. We construct
> a YAML with {{server_encryption_options}} and {{client_encryption_options}}
> and pass the storage port flag (both {{-sp}} and {{-ssp}}).
>
> However, we noticed that both the storage port flag and encryption settings
> are getting picked from the default config file {{conf/cassandra.yaml}} and
> ends up connecting to 7000 port unencrypted. As a workaround, we have added
> the storage port configuration to the YAML and copy our configuration file
> and overwrite the {{conf/cassandra.yaml}} and it is working now.
>
> Also to be noted that using the {{-f}} works in Cassandra 3.x. The bug seems
> to be present in 4.x versions only.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17602) sstableloader not respecting conf-path flag
[
https://issues.apache.org/jira/browse/CASSANDRA-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17602:
--
Reviewers: Brandon Williams, Stefan Miklosovic
Status: Review In Progress (was: Patch Available)
> sstableloader not respecting conf-path flag
> ---
>
> Key: CASSANDRA-17602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17602
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Aswin Karthik
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Hello,
> sstableloader does not seem to respect the config file flag (-f) and the
> storage port flag.
>
> We run our cluster on a different storage port with encryption. We construct
> a YAML with {{server_encryption_options}} and {{client_encryption_options}}
> and pass the storage port flag (both {{-sp}} and {{-ssp}}).
>
> However, we noticed that both the storage port flag and encryption settings
> are getting picked from the default config file {{conf/cassandra.yaml}} and
> ends up connecting to 7000 port unencrypted. As a workaround, we have added
> the storage port configuration to the YAML and copy our configuration file
> and overwrite the {{conf/cassandra.yaml}} and it is working now.
>
> Also to be noted that using the {{-f}} works in Cassandra 3.x. The bug seems
> to be present in 4.x versions only.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17602) sstableloader not respecting conf-path flag
[
https://issues.apache.org/jira/browse/CASSANDRA-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17602:
--
Fix Version/s: 4.0.5
4.2
(was: 4.0.x)
Since Version: 4.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/2531dd1ebaeab4e71f970e27a5dd962ceb6b790b
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> sstableloader not respecting conf-path flag
> ---
>
> Key: CASSANDRA-17602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17602
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Aswin Karthik
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.5, 4.1-beta, 4.2
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Hello,
> sstableloader does not seem to respect the config file flag (-f) and the
> storage port flag.
>
> We run our cluster on a different storage port with encryption. We construct
> a YAML with {{server_encryption_options}} and {{client_encryption_options}}
> and pass the storage port flag (both {{-sp}} and {{-ssp}}).
>
> However, we noticed that both the storage port flag and encryption settings
> are getting picked from the default config file {{conf/cassandra.yaml}} and
> ends up connecting to 7000 port unencrypted. As a workaround, we have added
> the storage port configuration to the YAML and copy our configuration file
> and overwrite the {{conf/cassandra.yaml}} and it is working now.
>
> Also to be noted that using the {{-f}} works in Cassandra 3.x. The bug seems
> to be present in 4.x versions only.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17658) Test Failures: org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
[
https://issues.apache.org/jira/browse/CASSANDRA-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17658:
--
Test and Documentation Plan: Repeated runs for the flaky test
Status: Patch Available (was: In Progress)
> Test Failures:
> org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
>
>
> Key: CASSANDRA-17658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17658
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> The test
> {{org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop}}
> seems to be flaky on CircleCI, although I haven't seen it failing on Jenkins.
> It was first detected during CASSANDRA-17509, on [this
> run|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/211/workflows/2cbb5465-a970-440b-a502-06e380ce6851/jobs/1977/tests]:
> {code}
> junit.framework.AssertionFailedError:
> org.apache.cassandra.metrics.keyspace.AdditionalWrites.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesLiveDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesOffHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesOnHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AntiCompactionTime.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BloomFilterDiskSpaceUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BloomFilterOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BytesValidated.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasCommitLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasCommitTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasPrepareLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasPrepareTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasProposeLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasProposeTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ClientTombstoneAborts.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ClientTombstoneWarnings.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ColUpdateTimeDeltaHistogram.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CompressionMetadataOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSizeAborts.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSizeWarnings.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IdealCLWriteLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IdealCLWriteTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IndexSummaryOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LiveDiskSpaceUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LiveScannedHistogram.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LocalReadSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LocalReadSizeAborts.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LocalReadSizeWarnings.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.MemtableColumnsCount.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.MemtableLiveDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.MemtableOffHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.MemtableOnHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.MemtableSwitchCount.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.PartitionsValidated.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.PendingCompactions.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.PendingFlushes.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.RangeLatency.keyspacemetricstest_metrics_cleanup,org.apache.cas
[jira] [Commented] (CASSANDRA-17658) Test Failures: org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
[
https://issues.apache.org/jira/browse/CASSANDRA-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553522#comment-17553522
]
Andres de la Peña commented on CASSANDRA-17658:
---
[Here|https://github.com/jacek-lewandowski/cassandra/commit/e936f120b7ee1936bab6f62810a6d75af1bb7874]
is the patch provided by [~jlewandowski], with [some repeated runs for 4.1
j8-j8|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/226/workflows/808cc7d1-03a0-4161-b56c-ca3d6477dfaf/jobs/1491].
I've started full CI for 4.1 and trunk:
||PR||CI||
|[4.1
|https://github.com/apache/cassandra/compare/trunk...adelapena:17658-4.1-review]
|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1700/workflows/4dd40b1d-8a89-42d2-b5eb-6df7d1f26820]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1700/workflows/33cb8efd-7883-4111-93ed-b248d163e204]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:17658-trunk-review]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1699/workflows/b994c61c-50d1-48af-8b86-f814919fabd3]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1699/workflows/d0d4ffc2-29f9-45be-95c4-3d4b6c4cdcd2]|
The method {{Schema#clear()}} is only meant to be called by tests. Perhaps we
should rename it to {{Schema#clearUnsafe()}} to prevent mistakes. This would be
in line with methods such as {{ColumnFamilyStore#clearUnsafe()}},
{{Gossiper#clearUnsafe()}}, {{TokenMetadata#clearUnsafe()}} and
{{Accumulator#clearUnsafe()}}.
> Test Failures:
> org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
>
>
> Key: CASSANDRA-17658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17658
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> The test
> {{org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop}}
> seems to be flaky on CircleCI, although I haven't seen it failing on Jenkins.
> It was first detected during CASSANDRA-17509, on [this
> run|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/211/workflows/2cbb5465-a970-440b-a502-06e380ce6851/jobs/1977/tests]:
> {code}
> junit.framework.AssertionFailedError:
> org.apache.cassandra.metrics.keyspace.AdditionalWrites.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesLiveDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesOffHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesOnHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AntiCompactionTime.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BloomFilterDiskSpaceUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BloomFilterOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BytesValidated.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasCommitLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasCommitTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasPrepareLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasPrepareTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasProposeLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasProposeTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ClientTombstoneAborts.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ClientTombstoneWarnings.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ColUpdateTimeDeltaHistogram.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CompressionMetadataOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSizeAborts.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSizeWarnings.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IdealCLWriteLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IdealCLWriteTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IndexSummaryOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspac
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553566#comment-17553566
]
Andres de la Peña commented on CASSANDRA-16844:
---
{quote}Compatibility between major versions - Content we have so far based on
the feedback - Developer community will try not to make any backwards
incompatible changes as much as possible, except in extreme cases like to
ensure correctness. Introducing a backward incompatibility change needs dev
community approval via voting [voting open for 48 hours]
{quote}
That point on the "Outstanding questions beyond the scope of this document"
section of the Release Lifecycle document has a comment that says:
{quote}To what? We should clarify what constitutes as C*'s public interface -
eg. cql, jmx, virtual tables, configuration params, etc.
{quote}
That seems relevant for nodetools' stdout. It's not clear to me whether that
output should be considered as a public interface with a proper serialization
format, or as text primarily meant for human consumption. The way the output is
formatted in many commands, frequently with the data included in sentences in
natural language, might suggest that it's mainly meant for human consumption.
But I can understand how users could be parsing this human-readable output on
the absence of a machine-readable counterpart.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553567#comment-17553567
]
Benedict Elliott Smith commented on CASSANDRA-16844:
I think, after JMX (or even before), {{nodetool}} is probably our most widely
consumed public API, and it is _definitely_ going to be used in scripts.
It's probably the API we should be _most_ careful about changing.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17307) Test Failure: org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailability
[
https://issues.apache.org/jira/browse/CASSANDRA-17307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553609#comment-17553609
]
Andres de la Peña commented on CASSANDRA-17307:
---
[Repeated
runs|https://app.circleci.com/pipelines/github/adelapena/cassandra/1680/workflows/f8c846a3-7768-4326-b7cb-e25da4dab2d7/jobs/17618]
of this test hit both the timeout mentioned on the description and the failure
reported on CASSANDRA-17641, CASSANDRA-17642, CASSANDRA-17651 and
CASSANDRA-17652.
The test combines queries expected to succeed with writes expected to timeout.
One one hand, the queries that should succeed require a timeout config large
enough to avoid accidentally timeouts queries due to a slow env. One the other
hand, the queries that should timeout benefit from a not-so-long timeout config
so the entire test doesn't hit a JUnit timeout.
I guess that what we can do here is increasing the query timeout config, so the
queries expected to succeed don't timeout on the coordinator, and also split
the test into multiple classes so there are less queries per test. That ways
the queries that should timeout on the coordinator wouldn't produce a Junit
timeout.
The problem is that the {{ShutdownException}} reported on the other tickets is
far more common than the timeout, so it's difficult to solve the timeout
problem without fixing the {{ShutdownException}} problem before.
> Test Failure:
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailability
>
>
> Key: CASSANDRA-17307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17307
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> No known failures. Flakiness 0%, Stability 100%
> Error Message
> Unexpected error while reading in case write-read consistency QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Unexpected error while reading in case
> write-read consistency QUORUM-QUORUM with not upgraded coordinator and 1
> nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:142)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:91)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:231)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:93)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:62)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:56)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailability(MixedModeAvailabilityV30Test.java:33)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:218)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
> at
> org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:135)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:155)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:134)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 1 responses.
> at
> org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1833)
> at
> org.apache.cassandra.service.StorageProxy.fet
[jira] [Comment Edited] (CASSANDRA-17307) Test Failure: org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailability
[
https://issues.apache.org/jira/browse/CASSANDRA-17307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553609#comment-17553609
]
Andres de la Peña edited comment on CASSANDRA-17307 at 6/13/22 2:27 PM:
[Repeated
runs|https://app.circleci.com/pipelines/github/adelapena/cassandra/1680/workflows/f8c846a3-7768-4326-b7cb-e25da4dab2d7/jobs/17618]
of this test hit both the timeout mentioned on the description and the failure
reported on CASSANDRA-17641, CASSANDRA-17642, CASSANDRA-17651 and
CASSANDRA-17652.
The test combines queries expected to succeed with writes expected to timeout.
One one hand, the queries that should succeed require a timeout config large
enough to avoid accidentally timeouts queries due to a slow env. One the other
hand, the queries that should timeout benefit from a not-so-long timeout config
so the entire test doesn't hit a JUnit timeout.
I guess that what we can do here is increasing the query timeout config, so the
queries expected to succeed don't timeout on the coordinator, and also split
the test into multiple classes so there are less queries per test. That ways
the queries that should timeout on the coordinator wouldn't produce a Junit
timeout.
The problem is that the {{ShutdownException}} reported on the other tickets is
far more common than the timeout, so it's difficult to solve the timeout
without fixing the {{ShutdownException}} bug before.
was (Author: adelapena):
[Repeated
runs|https://app.circleci.com/pipelines/github/adelapena/cassandra/1680/workflows/f8c846a3-7768-4326-b7cb-e25da4dab2d7/jobs/17618]
of this test hit both the timeout mentioned on the description and the failure
reported on CASSANDRA-17641, CASSANDRA-17642, CASSANDRA-17651 and
CASSANDRA-17652.
The test combines queries expected to succeed with writes expected to timeout.
One one hand, the queries that should succeed require a timeout config large
enough to avoid accidentally timeouts queries due to a slow env. One the other
hand, the queries that should timeout benefit from a not-so-long timeout config
so the entire test doesn't hit a JUnit timeout.
I guess that what we can do here is increasing the query timeout config, so the
queries expected to succeed don't timeout on the coordinator, and also split
the test into multiple classes so there are less queries per test. That ways
the queries that should timeout on the coordinator wouldn't produce a Junit
timeout.
The problem is that the {{ShutdownException}} reported on the other tickets is
far more common than the timeout, so it's difficult to solve the timeout
problem without fixing the {{ShutdownException}} problem before.
> Test Failure:
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailability
>
>
> Key: CASSANDRA-17307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17307
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> No known failures. Flakiness 0%, Stability 100%
> Error Message
> Unexpected error while reading in case write-read consistency QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Unexpected error while reading in case
> write-read consistency QUORUM-QUORUM with not upgraded coordinator and 1
> nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:142)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:91)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:231)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:93)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:62)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:56)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailability(MixedModeAvailabilityV30Test.java:33)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:218)
> at
> org.apache.cassandra.distribut
[jira] [Commented] (CASSANDRA-17310) Test Failure: org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
[
https://issues.apache.org/jira/browse/CASSANDRA-17310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553617#comment-17553617
]
Andres de la Peña commented on CASSANDRA-17310:
---
Indeed this seems a duplicate of CASSANDRA-17307, hitting the same type of
timeout in a different test case. And, same as CASSANDRA-17307, the test also
frequently hits the failure reported on CASSANDRA-17641, CASSANDRA-17642,
CASSANDRA-17651 and CASSANDRA-17652. That {{ShutdownException}} reported on the
other tickets is far more common than the timeout, so it seems difficult to
solve the timeout without fixing the {{ShutdownException}} bug before.
> Test Failure:
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
>
>
> Key: CASSANDRA-17310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17310
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/312/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV3XTest/testAvailability/
> Failed 1 times in the last 5 runs. Flakiness: 25%, Stability: 80%
> Error Message
> Unexpected error while reading in case write-read consistency ONE-ALL with
> upgraded coordinator and 2 nodes down
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Unexpected error while reading in case
> write-read consistency ONE-ALL with upgraded coordinator and 2 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:142)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:91)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:231)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:93)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:61)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:56)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability(MixedModeAvailabilityV3XTest.java:33)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:166)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:134)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17641) Fix flaky dtest - org.apache.cassandra.distributed.test.SchemaTest.readRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-17641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553619#comment-17553619
]
Brandon Williams commented on CASSANDRA-17641:
--
Interesting to note that this test can't be run in isolation with
test-jvm-dtest-some due to a problem with metrics:
{noformat}
[junit-timeout] Testcase:
readRepair(org.apache.cassandra.distributed.test.SchemaTest): Caused an ERROR
[junit-timeout] java.lang.NoSuchMethodError:
org.apache.cassandra.metrics.CassandraMetricsRegistry.timer(Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;)Lcom/codahale/metrics/Timer;
[junit-timeout] java.lang.RuntimeException: java.lang.NoSuchMethodError:
org.apache.cassandra.metrics.CassandraMetricsRegistry.timer(Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;)Lcom/codahale/metrics/Timer;
[junit-timeout] at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$12(Instance.java:702)
[junit-timeout] at
org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
[junit-timeout] at
org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
[junit-timeout] at
org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
[junit-timeout] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[junit-timeout] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit-timeout] at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[junit-timeout] at java.lang.Thread.run(Thread.java:748)
[junit-timeout] Caused by: java.lang.NoSuchMethodError:
org.apache.cassandra.metrics.CassandraMetricsRegistry.timer(Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;)Lcom/codahale/metrics/Timer;
[junit-timeout] at
org.apache.cassandra.metrics.DroppedMessageMetrics.(DroppedMessageMetrics.java:77)
[junit-timeout] at
org.apache.cassandra.metrics.MessagingMetrics$DroppedForVerb.(MessagingMetrics.java:84)
[junit-timeout] at
org.apache.cassandra.metrics.MessagingMetrics.(MessagingMetrics.java:110)
[junit-timeout] at
org.apache.cassandra.net.MessagingService.(MessagingService.java:267)
[junit-timeout] at
org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:232)
[junit-timeout] at
org.apache.cassandra.net.MessagingService.instance(MessagingService.java:237)
[junit-timeout] at
org.apache.cassandra.schema.DefaultSchemaUpdateHandler.(DefaultSchemaUpdateHandler.java:78)
[junit-timeout] at
org.apache.cassandra.schema.DefaultSchemaUpdateHandlerFactory.getSchemaUpdateHandler(DefaultSchemaUpdateHandlerFactory.java:32)
[junit-timeout] at
org.apache.cassandra.schema.Schema.(Schema.java:111)
[junit-timeout] at
org.apache.cassandra.schema.Schema.(Schema.java:75)
[junit-timeout] at
org.apache.cassandra.service.StartupChecks$13.execute(StartupChecks.java:626)
[junit-timeout] at
org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:175)
[junit-timeout] at
org.apache.cassandra.service.CassandraDaemon.runStartupChecks(CassandraDaemon.java:501)
[junit-timeout] at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$12(Instance.java:574)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.distributed.test.SchemaTest FAILED
{noformat}
> Fix flaky dtest - org.apache.cassandra.distributed.test.SchemaTest.readRepair
> -
>
> Key: CASSANDRA-17641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17641
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x
>
>
> {code}
> org.apache.cassandra.distributed.shared.ShutdownException: Uncaught
> exceptions were thrown during test
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:1056)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1042)
> at
> org.apache.cassandra.distributed.test.SchemaTest.readRepair(SchemaTest.java:46)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(
[jira] [Commented] (CASSANDRA-17658) Test Failures: org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
[
https://issues.apache.org/jira/browse/CASSANDRA-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553632#comment-17553632
]
Andres de la Peña commented on CASSANDRA-17658:
---
[~jlewandowski] it seems that the repeated test runs above keep hitting the
failure.
> Test Failures:
> org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
>
>
> Key: CASSANDRA-17658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17658
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> The test
> {{org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop}}
> seems to be flaky on CircleCI, although I haven't seen it failing on Jenkins.
> It was first detected during CASSANDRA-17509, on [this
> run|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/211/workflows/2cbb5465-a970-440b-a502-06e380ce6851/jobs/1977/tests]:
> {code}
> junit.framework.AssertionFailedError:
> org.apache.cassandra.metrics.keyspace.AdditionalWrites.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesLiveDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesOffHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesOnHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AntiCompactionTime.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BloomFilterDiskSpaceUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BloomFilterOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BytesValidated.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasCommitLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasCommitTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasPrepareLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasPrepareTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasProposeLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasProposeTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ClientTombstoneAborts.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ClientTombstoneWarnings.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ColUpdateTimeDeltaHistogram.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CompressionMetadataOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSizeAborts.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSizeWarnings.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IdealCLWriteLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IdealCLWriteTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IndexSummaryOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LiveDiskSpaceUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LiveScannedHistogram.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LocalReadSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LocalReadSizeAborts.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LocalReadSizeWarnings.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.MemtableColumnsCount.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.MemtableLiveDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.MemtableOffHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.MemtableOnHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.MemtableSwitchCount.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.PartitionsValidated.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.PendingCompactions.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.PendingFlushes.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.RangeLatency.keyspacemetricstest_metrics_cleanup,org.a
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553670#comment-17553670
]
Brandon Williams commented on CASSANDRA-16844:
--
bq. I can tell you now I'd -1 cutting a 5.0 instead of 4.2 just so we can add
an extra column
I agree with you, a single column isn't enough to justify it. But as I pointed
out before, it's _all of the columns_ after CASSANDRA-16976, and a way to
preserve the contributions already committed would be to leave them in trunk,
bumping the version, and revert them in 4.1 to preserve the compatibility.
bq. I think, after JMX (or even before), nodetool is probably our most widely
consumed public API
I think this is probably true as well, and perhaps a good reason to offer a
proper serialization format as was done (for cfstats) in CASSANDRA-5977 so that
we can avoid issues like this going forward.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17411) Network partition causes write ONE timeouts when using counters in Cassandra 4
[
https://issues.apache.org/jira/browse/CASSANDRA-17411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17411:
-
Status: Needs Committer (was: Patch Available)
> Network partition causes write ONE timeouts when using counters in Cassandra 4
> --
>
> Key: CASSANDRA-17411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17411
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Pere Balaguer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.x
>
> Attachments: app.py
>
>
> h5. Affected versions:
> * 4.x
> h5. Observed behavior:
> When executing CL=ONE writes on a table with a counter column, if one of the
> nodes is network partitioned from the others, clients keep sending requests
> to it.
> Even though this may be a "driver" problem, I've been able to reproduce it
> with both java and python datastax drivers using their latest available
> versions and given the behavior only changes depending on the Cassandra
> version, well, here I am.
> h5. Expected behavior:
> In Cassandra 3 after all inflight requests fail (expected), no new requests
> are sent to the partitioned node. The expectation is that Cassandra 4 behaves
> the same way.
> h5. How to reproduce:
> {noformat}
> # Create a cluster with the desired version, will go with 4.x for this example
> ccm create bug-report -v 4.0.3
> ccm populate -n 2:2:2
> ccm start
> # Create schemas and so on
> CQL=$(cat < CONSISTENCY ALL;
> DROP KEYSPACE IF EXISTS demo;
> CREATE KEYSPACE demo WITH REPLICATION = {'class': 'NetworkTopologyStrategy',
> 'dc1': 2, 'dc2': 2, 'dc3': 2};
> CREATE TABLE demo.demo (pk uuid PRIMARY KEY, count counter) WITH compaction =
> {'class': 'LeveledCompactionStrategy'};
> END
> )
> ccm node1 cqlsh --verbose --exec="${CQL}"
> # Launch the attached app.py
> # requires cassandra-driver
> python3 app.py "127.0.0.1" "9042"
> # Wait a bit for the app to settle, proceed to next step once you see 3
> messages in stdout like:
> # 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572
> (0.00) timeouts/total_rqs in the last 1 minute
> # Partition one node with iptables
> iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port 7000 -j
> DROP; iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port
> 9042 -j DROP
> {noformat}
> Some time after executing the iptables command in cassandra-3 the output
> should be similar to:
> {noformat}
> 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:51,576 - target-dc3 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:58,032 - target-dc1 - __main__ - INFO - Got 6/252 (2.380952)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,560 - target-dc2 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,620 - target-dc3 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:58,101 - target-dc1 - __main__ - INFO - Got 2/354 (0.564972)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,602 - target-dc2 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,672 - target-dc3 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:58,153 - target-dc1 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> {noformat}
> as the timeouts/rqs shows, in about 2 minutes the partitioned node stops
> receiving traffic
> while as in cassandra-4
> {noformat}
> 2022-03-01 15:49:39,068 - target-dc3 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:39,107 - target-dc2 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:41,206 - target-dc1 - __main__ - INFO - Got 2/444 (0.450450)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:39,095 - target-dc3 - __main__ - INFO - Got 0/569 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:39,148 - target-dc2 - __main__ - INFO - Got 0/569 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:42,589 - target-dc1 - __main__ - INFO - Got 7/13 (53.846154)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:51:39,125 - target-dc3 - __main__ - INFO - Got 0/567 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:51:39,159 - target-dc2 - __main__ - INFO - Got 0/567 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2
[jira] [Updated] (CASSANDRA-17301) Test Failure: org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17301:
Status: Ready to Commit (was: Review In Progress)
> Test Failure:
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
> ---
>
> Key: CASSANDRA-17301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17301
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/316/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/suddenDisconnect_cdc/
> See same failure on
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-compression
> as well
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> {code}
> Stacktrace
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:279)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$suddenDisconnect$29(ProxyHandlerConnectionsTest.java:237)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:385)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:344)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect(ProxyHandlerConnectionsTest.java:225)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> DEBUG [main] 2022-01-23 13:09:13,779 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:897 - Java
> version: 8
> DEBUG [main] 2022-01-23 13:09:13,807 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] 2022-01-23 13:09:13,808 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> ...[truncated 417667 chars]...
> ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.decode(InboundConnectionInitiator.java:235)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 29 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17301) Test Failure: org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17301:
Reviewers: Berenguer Blasi, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> Test Failure:
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
> ---
>
> Key: CASSANDRA-17301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17301
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/316/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/suddenDisconnect_cdc/
> See same failure on
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-compression
> as well
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> {code}
> Stacktrace
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:279)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$suddenDisconnect$29(ProxyHandlerConnectionsTest.java:237)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:385)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:344)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect(ProxyHandlerConnectionsTest.java:225)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> DEBUG [main] 2022-01-23 13:09:13,779 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:897 - Java
> version: 8
> DEBUG [main] 2022-01-23 13:09:13,807 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] 2022-01-23 13:09:13,808 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> ...[truncated 417667 chars]...
> ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.decode(InboundConnectionInitiator.java:235)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 29 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17301) Test Failure: org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553689#comment-17553689
]
Ekaterina Dimitrova commented on CASSANDRA-17301:
-
Thanks, I don't see on the last trunk CI run too.
I can commit it tomorrow (having very bad internet where I am now, I don't want
to get interrupted in the middle of a commit)
> Test Failure:
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
> ---
>
> Key: CASSANDRA-17301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17301
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/316/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/suddenDisconnect_cdc/
> See same failure on
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-compression
> as well
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> {code}
> Stacktrace
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:279)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$suddenDisconnect$29(ProxyHandlerConnectionsTest.java:237)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:385)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:344)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect(ProxyHandlerConnectionsTest.java:225)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> DEBUG [main] 2022-01-23 13:09:13,779 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:897 - Java
> version: 8
> DEBUG [main] 2022-01-23 13:09:13,807 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] 2022-01-23 13:09:13,808 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> ...[truncated 417667 chars]...
> ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.decode(InboundConnectionInitiator.java:235)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 29 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17687) Remove "--frames" option when generating javadoc
[ https://issues.apache.org/jira/browse/CASSANDRA-17687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17687: - Reviewers: Brandon Williams, Stefan Miklosovic (was: Stefan Miklosovic) > Remove "--frames" option when generating javadoc > > > Key: CASSANDRA-17687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17687 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Zili Chen >Assignee: Zili Chen >Priority: Normal > Fix For: 4.x > > > JDK17 doesn't support this option and it seems not quite necessary. For > forward compatibility I propose we can remove this option. > Related JDK issue: [https://bugs.openjdk.org/browse/JDK-8215599] > I volunteer to prepare a patch if this is in a good direction. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17687) Remove "--frames" option when generating javadoc
[ https://issues.apache.org/jira/browse/CASSANDRA-17687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553692#comment-17553692 ] Brandon Williams commented on CASSANDRA-17687: -- [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17687], [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1792/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1792/pipeline] > Remove "--frames" option when generating javadoc > > > Key: CASSANDRA-17687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17687 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Zili Chen >Assignee: Zili Chen >Priority: Normal > Fix For: 4.x > > > JDK17 doesn't support this option and it seems not quite necessary. For > forward compatibility I propose we can remove this option. > Related JDK issue: [https://bugs.openjdk.org/browse/JDK-8215599] > I volunteer to prepare a patch if this is in a good direction. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17301) Test Failure: org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17301:
Test and Documentation Plan: The test is not reproducible in CircleCI or
locally but fails regularly in Jenkins so running CI on all three branches In
Jenkins sounds like a first step and we will keep on monitoring if any timeout
pops up again to reopen the ticket (was: The test is not reproducible in
CircleCI or locally but fails regularly in Jenkins so running CI on all three
branches In Jenkins sounds like a first step and we will keep on monitoring if
any timeout pops up again.)
> Test Failure:
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
> ---
>
> Key: CASSANDRA-17301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17301
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/316/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/suddenDisconnect_cdc/
> See same failure on
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-compression
> as well
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> {code}
> Stacktrace
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:279)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$suddenDisconnect$29(ProxyHandlerConnectionsTest.java:237)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:385)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:344)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect(ProxyHandlerConnectionsTest.java:225)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> DEBUG [main] 2022-01-23 13:09:13,779 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:897 - Java
> version: 8
> DEBUG [main] 2022-01-23 13:09:13,807 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] 2022-01-23 13:09:13,808 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> ...[truncated 417667 chars]...
> ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.decode(InboundConnectionInitiator.java:235)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 29 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17301) Test Failure: org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553689#comment-17553689
]
Ekaterina Dimitrova edited comment on CASSANDRA-17301 at 6/13/22 4:24 PM:
--
Thanks, I don't see it on the last trunk CI run too.
I can commit it tomorrow (having very bad internet where I am now, I don't want
to get interrupted in the middle of a commit)
was (Author: e.dimitrova):
Thanks, I don't see on the last trunk CI run too.
I can commit it tomorrow (having very bad internet where I am now, I don't want
to get interrupted in the middle of a commit)
> Test Failure:
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
> ---
>
> Key: CASSANDRA-17301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17301
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/316/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/suddenDisconnect_cdc/
> See same failure on
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-compression
> as well
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> {code}
> Stacktrace
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:279)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$suddenDisconnect$29(ProxyHandlerConnectionsTest.java:237)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:385)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:344)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect(ProxyHandlerConnectionsTest.java:225)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> DEBUG [main] 2022-01-23 13:09:13,779 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:897 - Java
> version: 8
> DEBUG [main] 2022-01-23 13:09:13,807 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] 2022-01-23 13:09:13,808 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> ...[truncated 417667 chars]...
> ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.decode(InboundConnectionInitiator.java:235)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 29 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17301) Test Failure: org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17301:
Reviewers: Berenguer Blasi (was: Berenguer Blasi, Ekaterina Dimitrova)
> Test Failure:
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-cdc
> ---
>
> Key: CASSANDRA-17301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17301
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/316/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/suddenDisconnect_cdc/
> See same failure on
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect-compression
> as well
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> {code}
> Stacktrace
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:279)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$suddenDisconnect$29(ProxyHandlerConnectionsTest.java:237)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:385)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:344)
> at
> org.apache.cassandra.net.ProxyHandlerConnectionsTest.suddenDisconnect(ProxyHandlerConnectionsTest.java:225)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> DEBUG [main] 2022-01-23 13:09:13,779 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] 2022-01-23 13:09:13,805 PlatformDependent0.java:897 - Java
> version: 8
> DEBUG [main] 2022-01-23 13:09:13,807 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] 2022-01-23 13:09:13,808 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> ...[truncated 417667 chars]...
> ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$Handler.decode(InboundConnectionInitiator.java:235)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 29 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17646) Increment CQLSH version for release 4.2
[ https://issues.apache.org/jira/browse/CASSANDRA-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553693#comment-17553693 ] Brandon Williams commented on CASSANDRA-17646: -- [~e.dimitrova] what should be the next step here? > Increment CQLSH version for release 4.2 > --- > > Key: CASSANDRA-17646 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17646 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Attila Homoki >Priority: Normal > Fix For: 4.x > > Attachments: image-2022-05-27-23-08-25-855.png > > > Increment CQLSH version for release 4.2 on trunk -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17680) Fix flaky topology_test.py::TestTopology::test_simple_decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-17680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17680:
Assignee: Brandon Williams
> Fix flaky topology_test.py::TestTopology::test_simple_decommission
> --
>
> Key: CASSANDRA-17680
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17680
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x
>
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=test_simple_decommission-4.1&filter=all]
> Reproduced in 4.1 but it might exist also in other branches, to be tested. I
> don't see it in Butler but sounds like something good to be checked.
>
> {code:java}
> test teardown failure Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [OptionalTasks:1] 2022-06-02
> 21:19:09,514 JVMStabilityInspector.java:68 - Exception in thread
> Thread[OptionalTasks:1,5,OptionalTasks]\njava.lang.AssertionError: Unable to
> get tokens for /127.0.0.2:7000; it is not a member\n\tat
> org.apache.cassandra.locator.TokenMetadata.getTokens(TokenMetadata.java:604)\n\tat
>
> org.apache.cassandra.service.StorageService.getLocalPrimaryRangeForEndpoint(StorageService.java:4543)\n\tat
>
> org.apache.cassandra.service.StorageService.getLocalPrimaryRange(StorageService.java:4535)\n\tat
>
> org.apache.cassandra.db.SizeEstimatesRecorder.run(SizeEstimatesRecorder.java:91)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)\n\tat
>
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)\n\tat
>
> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)\n\tat
>
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17151) Guardrail for column size
[
https://issues.apache.org/jira/browse/CASSANDRA-17151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-17151:
-
Assignee: Andres de la Peña
> Guardrail for column size
> -
>
> Key: CASSANDRA-17151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17151
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add a guardrail for limiting the max size of column values, for example:
> {code}
> # Failure threshold to prevent writing large column values.
> # Defaults to -1 to disable.
> column_value_size_failure_threshold_in_kb: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17646) Increment CQLSH version for release 4.2
[ https://issues.apache.org/jira/browse/CASSANDRA-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553710#comment-17553710 ] Ekaterina Dimitrova commented on CASSANDRA-17646: - I am sorry, I thought we are good to commit this one. I just looked at all runs you linked. So in CircleCI one container was timing out on DropCompactStorage. I think we need to rebase and rerun CI as that test was split lately in another ticket and the patch was not rebased since it was committed more than 20 days ago. WDYT? > Increment CQLSH version for release 4.2 > --- > > Key: CASSANDRA-17646 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17646 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Attila Homoki >Priority: Normal > Fix For: 4.x > > Attachments: image-2022-05-27-23-08-25-855.png > > > Increment CQLSH version for release 4.2 on trunk -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17646) Increment CQLSH version for release 4.2
[ https://issues.apache.org/jira/browse/CASSANDRA-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553710#comment-17553710 ] Ekaterina Dimitrova edited comment on CASSANDRA-17646 at 6/13/22 4:55 PM: -- I am sorry, I thought we are good to commit this one. I just looked at all runs you linked. So in CircleCI one container was timing out on DropCompactStorage. I think we need to rebase and rerun CI as that test was split lately in another ticket and the patch was not rebased since it was committed more than 20 days ago. WDYT? PS I am out until next Tuesday but I take a look occasionally at things I was involved or if there is something urgent. was (Author: e.dimitrova): I am sorry, I thought we are good to commit this one. I just looked at all runs you linked. So in CircleCI one container was timing out on DropCompactStorage. I think we need to rebase and rerun CI as that test was split lately in another ticket and the patch was not rebased since it was committed more than 20 days ago. WDYT? > Increment CQLSH version for release 4.2 > --- > > Key: CASSANDRA-17646 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17646 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Attila Homoki >Priority: Normal > Fix For: 4.x > > Attachments: image-2022-05-27-23-08-25-855.png > > > Increment CQLSH version for release 4.2 on trunk -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17646) Increment CQLSH version for release 4.2
[ https://issues.apache.org/jira/browse/CASSANDRA-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553710#comment-17553710 ] Ekaterina Dimitrova edited comment on CASSANDRA-17646 at 6/13/22 4:55 PM: -- I am sorry, I thought we are good to commit this one. I just looked at all runs you linked. So in CircleCI one container was timing out on DropCompactStorage. I think we need to rebase and rerun CI as that test was split lately in another ticket and the patch was not rebased since it was committed more than 20 days ago. WDYT? PS I am out until next Tuesday but I take a look occasionally at things I am involved in or if there is something urgent. was (Author: e.dimitrova): I am sorry, I thought we are good to commit this one. I just looked at all runs you linked. So in CircleCI one container was timing out on DropCompactStorage. I think we need to rebase and rerun CI as that test was split lately in another ticket and the patch was not rebased since it was committed more than 20 days ago. WDYT? PS I am out until next Tuesday but I take a look occasionally at things I was involved or if there is something urgent. > Increment CQLSH version for release 4.2 > --- > > Key: CASSANDRA-17646 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17646 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Attila Homoki >Priority: Normal > Fix For: 4.x > > Attachments: image-2022-05-27-23-08-25-855.png > > > Increment CQLSH version for release 4.2 on trunk -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17646) Increment CQLSH version for release 4.2
[ https://issues.apache.org/jira/browse/CASSANDRA-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553717#comment-17553717 ] Brandon Williams commented on CASSANDRA-17646: -- Sounds good to me. [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17646], [j8 w/upgrade|https://app.circleci.com/pipelines/github/driftx/cassandra/521/workflows/81f06aa2-3f15-44b9-a890-5667ddda382a], [j11https://app.circleci.com/pipelines/github/driftx/cassandra/521/workflows/7dd108d5-be12-421c-bc6f-214180be6de2]. > Increment CQLSH version for release 4.2 > --- > > Key: CASSANDRA-17646 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17646 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Attila Homoki >Priority: Normal > Fix For: 4.x > > Attachments: image-2022-05-27-23-08-25-855.png > > > Increment CQLSH version for release 4.2 on trunk -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17646) Increment CQLSH version for release 4.2
[ https://issues.apache.org/jira/browse/CASSANDRA-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553717#comment-17553717 ] Brandon Williams edited comment on CASSANDRA-17646 at 6/13/22 5:08 PM: --- Sounds good to me. [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17646], [j8 w/upgrade|https://app.circleci.com/pipelines/github/driftx/cassandra/521/workflows/81f06aa2-3f15-44b9-a890-5667ddda382a], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/521/workflows/7dd108d5-be12-421c-bc6f-214180be6de2]. was (Author: brandon.williams): Sounds good to me. [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17646], [j8 w/upgrade|https://app.circleci.com/pipelines/github/driftx/cassandra/521/workflows/81f06aa2-3f15-44b9-a890-5667ddda382a], [j11https://app.circleci.com/pipelines/github/driftx/cassandra/521/workflows/7dd108d5-be12-421c-bc6f-214180be6de2]. > Increment CQLSH version for release 4.2 > --- > > Key: CASSANDRA-17646 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17646 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Attila Homoki >Priority: Normal > Fix For: 4.x > > Attachments: image-2022-05-27-23-08-25-855.png > > > Increment CQLSH version for release 4.2 on trunk -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-17641) Fix flaky dtest - org.apache.cassandra.distributed.test.SchemaTest.readRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-17641 ]
Brandon Williams deleted comment on CASSANDRA-17641:
--
was (Author: brandon.williams):
Interesting to note that this test can't be run in isolation with
test-jvm-dtest-some due to a problem with metrics:
{noformat}
[junit-timeout] Testcase:
readRepair(org.apache.cassandra.distributed.test.SchemaTest): Caused an ERROR
[junit-timeout] java.lang.NoSuchMethodError:
org.apache.cassandra.metrics.CassandraMetricsRegistry.timer(Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;)Lcom/codahale/metrics/Timer;
[junit-timeout] java.lang.RuntimeException: java.lang.NoSuchMethodError:
org.apache.cassandra.metrics.CassandraMetricsRegistry.timer(Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;)Lcom/codahale/metrics/Timer;
[junit-timeout] at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$12(Instance.java:702)
[junit-timeout] at
org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
[junit-timeout] at
org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
[junit-timeout] at
org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
[junit-timeout] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[junit-timeout] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit-timeout] at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[junit-timeout] at java.lang.Thread.run(Thread.java:748)
[junit-timeout] Caused by: java.lang.NoSuchMethodError:
org.apache.cassandra.metrics.CassandraMetricsRegistry.timer(Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;Lorg/apache/cassandra/metrics/CassandraMetricsRegistry$MetricName;)Lcom/codahale/metrics/Timer;
[junit-timeout] at
org.apache.cassandra.metrics.DroppedMessageMetrics.(DroppedMessageMetrics.java:77)
[junit-timeout] at
org.apache.cassandra.metrics.MessagingMetrics$DroppedForVerb.(MessagingMetrics.java:84)
[junit-timeout] at
org.apache.cassandra.metrics.MessagingMetrics.(MessagingMetrics.java:110)
[junit-timeout] at
org.apache.cassandra.net.MessagingService.(MessagingService.java:267)
[junit-timeout] at
org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:232)
[junit-timeout] at
org.apache.cassandra.net.MessagingService.instance(MessagingService.java:237)
[junit-timeout] at
org.apache.cassandra.schema.DefaultSchemaUpdateHandler.(DefaultSchemaUpdateHandler.java:78)
[junit-timeout] at
org.apache.cassandra.schema.DefaultSchemaUpdateHandlerFactory.getSchemaUpdateHandler(DefaultSchemaUpdateHandlerFactory.java:32)
[junit-timeout] at
org.apache.cassandra.schema.Schema.(Schema.java:111)
[junit-timeout] at
org.apache.cassandra.schema.Schema.(Schema.java:75)
[junit-timeout] at
org.apache.cassandra.service.StartupChecks$13.execute(StartupChecks.java:626)
[junit-timeout] at
org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:175)
[junit-timeout] at
org.apache.cassandra.service.CassandraDaemon.runStartupChecks(CassandraDaemon.java:501)
[junit-timeout] at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$12(Instance.java:574)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.distributed.test.SchemaTest FAILED
{noformat}
> Fix flaky dtest - org.apache.cassandra.distributed.test.SchemaTest.readRepair
> -
>
> Key: CASSANDRA-17641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17641
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x
>
>
> {code}
> org.apache.cassandra.distributed.shared.ShutdownException: Uncaught
> exceptions were thrown during test
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:1056)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1042)
> at
> org.apache.cassandra.distributed.test.SchemaTest.readRepair(SchemaTest.java:46)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Suppressed: java.lang.R
[cassandra-website] branch asf-staging updated (7e87036fb -> 6bdc22a44)
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 7e87036fb generate docs for bab3393d new 6bdc22a44 generate docs for bab3393d 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 (7e87036fb) \ N -- N -- N refs/heads/asf-staging (6bdc22a44) 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: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17483) WEBSITE - Homepage, Case Studies, and Blog edits and fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17483: - Test and Documentation Plan: Homepage * Formatting fix for Cassandra Users quotes Case Studies page * Add alt text for company logos * Add quotation marks to the Backblaze case study card * Add logo on the Backblaze case study page * Formatting fix Instana testimonial quotes * Fix "Read More" buttons on Backblaze, Kinetic Data, Instana, and Liquibase opening a new window *and* opening the case study page Blog * "Apache Cassandra 4.1 Features: Guardrails Framework" image replacement * "Inside Cassandra: An Interview with Project Contributor, Lorina Poland" image replacement Images * Image cleanup ** Fixing incorrect image locations ** Image locations corrected on the website for those images changed was: Homepage * Formatting fix for Cassandra Users quotes Case Studies page * Add alt text for company logos * Add quotation marks to the Backblaze case study card * Fix "Read More" buttons on Backblaze, Kinetic Data, and Liquibase opening a new window *and* opening the case study page Blog * "Apache Cassandra 4.1 Features: Guardrails Framework" image replacement * "Inside Cassandra: An Interview with Project Contributor, Lorina Poland" image replacement Images * Image cleanup ** Fixing incorrect image locations ** Image locations corrected on the website for those images changed > WEBSITE - Homepage, Case Studies, and Blog edits and fixes > -- > > Key: CASSANDRA-17483 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17483 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Fix For: NA > > > This ticket is to capture the work associated with updates to the Apache > Cassandra homepage, Case Studies page, and blog posts to address typos and > formatting issues. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17661) Adding support to perform certificate based internode authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17661: -- Reviewers: Jon Meredith, Yifan Cai (was: Yifan Cai) > Adding support to perform certificate based internode authentication > > > Key: CASSANDRA-17661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17661 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Changes are to be made in IInternodeAuthenticator interface to support > certificate based authentication and to add a new pipeline in > InboundConnectionInitiator should be added to perform certificate based > authentication for internode communications. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17692) WEBSITE - June 2022 blog "Apache Cassandra 4.1: New SSTable Identifiers"
Diogenese Topper created CASSANDRA-17692: Summary: WEBSITE - June 2022 blog "Apache Cassandra 4.1: New SSTable Identifiers" Key: CASSANDRA-17692 URL: https://issues.apache.org/jira/browse/CASSANDRA-17692 Project: Cassandra Issue Type: Task Components: Documentation/Blog Reporter: Diogenese Topper This ticket is to capture the work associated with publishing the June 2022 blog "Apache Cassandra 4.1: New SSTable Identifiers" If this blog cannot be published by the *June 16, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553747#comment-17553747
]
Andres de la Peña commented on CASSANDRA-16844:
---
I agree with bumping the version and keeping the changes on trunk, while also
offering a proper serialization format. The {{cfstats}}-style formatting would
probably mean providing a {{-F}} option allowing us to print the table in json
or yaml. That way we could consider the current output of {{compactionstats}}
as human-readable, and the scripts out there could start using the {{-F}}
option to generate proper machine-readable output.
That approach would give us an exit from the current situation, where every
minimal change in nodetool output risks breaking scripts consuming what seems
originally conceived as human-readable output (see first comment on
CASSANDRA-5977).
The {{-F}} option might also be introduced in 4.1 without the rest of the
changes, so users have time to upgrade their scripts before 5.0 changes the
human-readable output.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17687) Remove "--frames" option when generating javadoc
[ https://issues.apache.org/jira/browse/CASSANDRA-17687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553692#comment-17553692 ] Brandon Williams edited comment on CASSANDRA-17687 at 6/13/22 6:18 PM: --- [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17687], [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1793/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1793/pipeline] was (Author: brandon.williams): [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17687], [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1792/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1792/pipeline] > Remove "--frames" option when generating javadoc > > > Key: CASSANDRA-17687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17687 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Zili Chen >Assignee: Zili Chen >Priority: Normal > Fix For: 4.x > > > JDK17 doesn't support this option and it seems not quite necessary. For > forward compatibility I propose we can remove this option. > Related JDK issue: [https://bugs.openjdk.org/browse/JDK-8215599] > I volunteer to prepare a patch if this is in a good direction. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17687) Remove "--frames" option when generating javadoc
[ https://issues.apache.org/jira/browse/CASSANDRA-17687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553692#comment-17553692 ] Brandon Williams edited comment on CASSANDRA-17687 at 6/13/22 6:20 PM: --- [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17687], [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1794/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1794/pipeline] was (Author: brandon.williams): [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17687], [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1793/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1793/pipeline] > Remove "--frames" option when generating javadoc > > > Key: CASSANDRA-17687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17687 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Zili Chen >Assignee: Zili Chen >Priority: Normal > Fix For: 4.x > > > JDK17 doesn't support this option and it seems not quite necessary. For > forward compatibility I propose we can remove this option. > Related JDK issue: [https://bugs.openjdk.org/browse/JDK-8215599] > I volunteer to prepare a patch if this is in a good direction. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17683) CASSANDRA-16844 added column in the middle of compactionstats which breaks consumers using positional parsing
[ https://issues.apache.org/jira/browse/CASSANDRA-17683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553750#comment-17553750 ] David Capwell commented on CASSANDRA-17683: --- renaming to reflect the actual issue... > CASSANDRA-16844 added column in the middle of compactionstats which breaks > consumers using positional parsing > - > > Key: CASSANDRA-17683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17683 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1.x > > > Compactionstats added a new sstables column in the middle of the output > table, this causes issues for tools which use positional parsing rather than > by-name parsing; to avoid this issue we should move the column to the last > column -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553749#comment-17553749
]
David Capwell commented on CASSANDRA-16844:
---
bq. it's all of the columns after CASSANDRA-16976, and a way to preserve the
contributions already committed would be to leave them in trunk, bumping the
version, and revert them in 4.1 to preserve the compatibility.
Agree that has to be dealt with as well, but that ticket was also a style
change and not a critical bug fix, which means it should not have been merged
until the 5.0 trunk change was agreed on.
bq. I can tell you now I'd -1 cutting a 5.0 instead of 4.2 just so we can add
an extra column
We don't have any pending tickets which justify the extra burden of 5.0, so
moving trunk 5.0 adds extra cost to everyone maintaining, I am against
switching to 5.0 at the moment.
bq. perhaps a good reason to offer a proper serialization format as was done
(for cfstats) in CASSANDRA-5977 so that we can avoid issues like this going
forward.
Having an output format which can be evolved without "breaking" is a good
thing, but the two tickets would need to be tied to that work.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17683) Address CASSANDRA-16844 and CASSANDRA-16976 breaking compatibility
[ https://issues.apache.org/jira/browse/CASSANDRA-17683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17683: -- Summary: Address CASSANDRA-16844 and CASSANDRA-16976 breaking compatibility (was: CASSANDRA-16844 added column in the middle of compactionstats which breaks consumers using positional parsing) > Address CASSANDRA-16844 and CASSANDRA-16976 breaking compatibility > -- > > Key: CASSANDRA-17683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17683 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1.x > > > Compactionstats added a new sstables column in the middle of the output > table, this causes issues for tools which use positional parsing rather than > by-name parsing; to avoid this issue we should move the column to the last > column -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17683) Address CASSANDRA-16844 and CASSANDRA-16976 breaking compatibility
[ https://issues.apache.org/jira/browse/CASSANDRA-17683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17683: -- Description: Compactionstats changed the output format, which causes a breaking change in a minor release; this goes against the projects guidelines for a minor release and needs to be addressed before releasing 4.1 (was: Compactionstats added a new sstables column in the middle of the output table, this causes issues for tools which use positional parsing rather than by-name parsing; to avoid this issue we should move the column to the last column) > Address CASSANDRA-16844 and CASSANDRA-16976 breaking compatibility > -- > > Key: CASSANDRA-17683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17683 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1.x > > > Compactionstats changed the output format, which causes a breaking change in > a minor release; this goes against the projects guidelines for a minor > release and needs to be addressed before releasing 4.1 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17683) Address CASSANDRA-16844 and CASSANDRA-16976 breaking compatibility
[ https://issues.apache.org/jira/browse/CASSANDRA-17683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553751#comment-17553751 ] David Capwell commented on CASSANDRA-17683: --- Having most of the conversation in CASSANDRA-16844, but using this ticket to block release > Address CASSANDRA-16844 and CASSANDRA-16976 breaking compatibility > -- > > Key: CASSANDRA-17683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17683 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1.x > > > Compactionstats added a new sstables column in the middle of the output > table, this causes issues for tools which use positional parsing rather than > by-name parsing; to avoid this issue we should move the column to the last > column -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17683) Address CASSANDRA-16844 and CASSANDRA-16976 breaking compatibility
[ https://issues.apache.org/jira/browse/CASSANDRA-17683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17683: -- Fix Version/s: 4.1-alpha (was: 4.1.x) > Address CASSANDRA-16844 and CASSANDRA-16976 breaking compatibility > -- > > Key: CASSANDRA-17683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17683 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1-alpha > > > Compactionstats changed the output format, which causes a breaking change in > a minor release; this goes against the projects guidelines for a minor > release and needs to be addressed before releasing 4.1 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17661) Adding support to perform certificate based internode authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17661: -- Status: Ready to Commit (was: Review In Progress) Starting commit CI Results (pending): ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17661-trunk-E4EE4A24-9682-4DAC-ABF2-4A8E8E0ACB30]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17661-trunk-E4EE4A24-9682-4DAC-ABF2-4A8E8E0ACB30]| > Adding support to perform certificate based internode authentication > > > Key: CASSANDRA-17661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17661 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Changes are to be made in IInternodeAuthenticator interface to support > certificate based authentication and to add a new pipeline in > InboundConnectionInitiator should be added to perform certificate based > authentication for internode communications. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17692) WEBSITE - June 2022 blog "Apache Cassandra 4.1: New SSTable Identifiers"
[ https://issues.apache.org/jira/browse/CASSANDRA-17692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17692: - Test and Documentation Plan: Add blog post titled "Apache Cassandra 4.1: New SSTable Identifiers" Modify blog index page Add image for blog: "apache-cassandra-4.1-new-sstable-identifiers-unsplash-maksym-kaharlytskyi.jpg" > WEBSITE - June 2022 blog "Apache Cassandra 4.1: New SSTable Identifiers" > > > Key: CASSANDRA-17692 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17692 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with publishing the June 2022 > blog "Apache Cassandra 4.1: New SSTable Identifiers" > If this blog cannot be published by the *June 16, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (6bdc22a4 -> a9edf97f)
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 6bdc22a4 generate docs for bab3393d new a9edf97f generate docs for bab3393d 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 (6bdc22a4) \ N -- N -- N refs/heads/asf-staging (a9edf97f) 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 4740078 -> 4740078 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
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553773#comment-17553773
]
Ekaterina Dimitrova commented on CASSANDRA-16844:
-
{quote}We don't have any pending tickets which justify the extra burden of 5.0,
so moving trunk 5.0 adds extra cost to everyone maintaining, I am against
switching to 5.0 at the moment.
{quote}
That is an interesting question that I believe It deserves broader agreement.
Up to now I was always hearing - we are 4.x until someone adds something
breaking compatibility and considered 5.0, then we will bump. No one was saying
- we need to approve it or have a list that should be big enough to justify it.
I think it is probably a good time to get into some agreement with the PMC on
this topic so that people can actually plan what they will work on or hit the
mailing list to agree whether it makes sense or not at this point in time. Some
changes people probably feel do not deserve CEP but we all know they can be a
breaking change.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553773#comment-17553773
]
Ekaterina Dimitrova edited comment on CASSANDRA-16844 at 6/13/22 7:31 PM:
--
{quote}We don't have any pending tickets which justify the extra burden of 5.0,
so moving trunk 5.0 adds extra cost to everyone maintaining, I am against
switching to 5.0 at the moment.
{quote}
That is an interesting question that I believe It deserves broader agreement.
Up to now I was always hearing - we are 4.x until someone adds something
breaking compatibility and considered 5.0, then we will bump. No one was saying
- we need to approve it explicitly on the mailing list or have a list that
should be big enough to justify that bump in time (which I believe might
demotivate people to be on a waiting list, IMHO).
I think it is probably a good time to get into some agreement with the PMC on
this topic so that people can actually plan what they will work on or hit the
mailing list to agree whether it makes sense or not at this point in time. Some
changes people probably feel do not deserve CEP but we all know they can be a
breaking change.
was (Author: e.dimitrova):
{quote}We don't have any pending tickets which justify the extra burden of 5.0,
so moving trunk 5.0 adds extra cost to everyone maintaining, I am against
switching to 5.0 at the moment.
{quote}
That is an interesting question that I believe It deserves broader agreement.
Up to now I was always hearing - we are 4.x until someone adds something
breaking compatibility and considered 5.0, then we will bump. No one was saying
- we need to approve it or have a list that should be big enough to justify it.
I think it is probably a good time to get into some agreement with the PMC on
this topic so that people can actually plan what they will work on or hit the
mailing list to agree whether it makes sense or not at this point in time. Some
changes people probably feel do not deserve CEP but we all know they can be a
breaking change.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553773#comment-17553773
]
Ekaterina Dimitrova edited comment on CASSANDRA-16844 at 6/13/22 7:32 PM:
--
{quote}We don't have any pending tickets which justify the extra burden of 5.0,
so moving trunk 5.0 adds extra cost to everyone maintaining, I am against
switching to 5.0 at the moment.
{quote}
That is an interesting question that I believe It deserves broader agreement.
Up to now I was always hearing - we are 4.x until someone adds something
breaking compatibility and considered 5.0, then we will bump. No one was saying
- we need to approve it explicitly on the mailing list or have a list that
should be big enough to justify that bump in time (which I believe might
demotivate people to be on a waiting list, IMHO).
I think it is probably a good time to get into some agreement with the PMC on
this topic so that people can actually plan what they will work on or hit the
mailing list to agree whether it makes sense or not at this point in time. Some
changes people probably feel do not deserve CEP but we all know they can be a
breaking change.
was (Author: e.dimitrova):
{quote}We don't have any pending tickets which justify the extra burden of 5.0,
so moving trunk 5.0 adds extra cost to everyone maintaining, I am against
switching to 5.0 at the moment.
{quote}
That is an interesting question that I believe It deserves broader agreement.
Up to now I was always hearing - we are 4.x until someone adds something
breaking compatibility and considered 5.0, then we will bump. No one was saying
- we need to approve it explicitly on the mailing list or have a list that
should be big enough to justify that bump in time (which I believe might
demotivate people to be on a waiting list, IMHO).
I think it is probably a good time to get into some agreement with the PMC on
this topic so that people can actually plan what they will work on or hit the
mailing list to agree whether it makes sense or not at this point in time. Some
changes people probably feel do not deserve CEP but we all know they can be a
breaking change.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553773#comment-17553773
]
Ekaterina Dimitrova edited comment on CASSANDRA-16844 at 6/13/22 7:33 PM:
--
{quote}We don't have any pending tickets which justify the extra burden of 5.0,
so moving trunk 5.0 adds extra cost to everyone maintaining, I am against
switching to 5.0 at the moment.
{quote}
That is an interesting question that I believe It deserves broader agreement.
Up to now I was always hearing - we are 4.x until someone adds something
breaking compatibility and considered 5.0, then we will bump. No one was saying
- we need to approve it explicitly on the mailing list or have a list that
should be big enough to justify that bump in time (which I believe might
demotivate people to be on a waiting list, IMHO).
I think it is probably a good time to get into some agreement with the PMC on
this topic (how to approach those changes) so that people can actually plan
what they will work on or hit the mailing list to agree whether it makes sense
or not at this point in time. Some changes people probably feel do not deserve
CEP but we all know they can be a breaking change.
was (Author: e.dimitrova):
{quote}We don't have any pending tickets which justify the extra burden of 5.0,
so moving trunk 5.0 adds extra cost to everyone maintaining, I am against
switching to 5.0 at the moment.
{quote}
That is an interesting question that I believe It deserves broader agreement.
Up to now I was always hearing - we are 4.x until someone adds something
breaking compatibility and considered 5.0, then we will bump. No one was saying
- we need to approve it explicitly on the mailing list or have a list that
should be big enough to justify that bump in time (which I believe might
demotivate people to be on a waiting list, IMHO).
I think it is probably a good time to get into some agreement with the PMC on
this topic so that people can actually plan what they will work on or hit the
mailing list to agree whether it makes sense or not at this point in time. Some
changes people probably feel do not deserve CEP but we all know they can be a
breaking change.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553784#comment-17553784
]
David Capwell commented on CASSANDRA-16844:
---
bq. I think it is probably a good time to get into some agreement with the PMC
on this topic
Sounds good to me!
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17661) Adding support to perform certificate based internode authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553762#comment-17553762 ] Yifan Cai edited comment on CASSANDRA-17661 at 6/13/22 8:43 PM: Starting commit CI Results: ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17661-trunk-E4EE4A24-9682-4DAC-ABF2-4A8E8E0ACB30]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17661-trunk-E4EE4A24-9682-4DAC-ABF2-4A8E8E0ACB30]| The CI result looks mostly green. The failures are not related with the patch. was (Author: yifanc): Starting commit CI Results (pending): ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17661-trunk-E4EE4A24-9682-4DAC-ABF2-4A8E8E0ACB30]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17661-trunk-E4EE4A24-9682-4DAC-ABF2-4A8E8E0ACB30]| > Adding support to perform certificate based internode authentication > > > Key: CASSANDRA-17661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17661 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Changes are to be made in IInternodeAuthenticator interface to support > certificate based authentication and to add a new pipeline in > InboundConnectionInitiator should be added to perform certificate based > authentication for internode communications. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Adding support to perform certificate based internode authentication
This is an automated email from the ASF dual-hosted git repository.
ycai pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 557b8e9982 Adding support to perform certificate based internode
authentication
557b8e9982 is described below
commit 557b8e9982ad0964191abde810ef5c77a536f70a
Author: Jyothsna Konisa
AuthorDate: Mon Jun 13 11:05:22 2022 -0700
Adding support to perform certificate based internode authentication
patch by Jyothsna Konisa; reviewed by Jon Meredith, Yifan Cai for
CASSANDRA-17661
---
CHANGES.txt| 1 +
.../auth/AllowAllInternodeAuthenticator.java | 4 +-
.../cassandra/auth/IInternodeAuthenticator.java| 50 +++-
.../cassandra/net/InboundConnectionInitiator.java | 100 ---
.../cassandra/net/InternodeConnectionUtils.java| 83 ++
.../org/apache/cassandra/net/MessagingService.java | 3 +
.../cassandra/net/OutboundConnectionInitiator.java | 60 -
.../apache/cassandra/service/StorageService.java | 2 +-
.../test/InternodeEncryptionEnforcementTest.java | 286 +
test/unit/org/apache/cassandra/SchemaLoader.java | 1 +
.../apache/cassandra/net/MessagingServiceTest.java | 91 +--
11 files changed, 616 insertions(+), 65 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 57733a5438..8e8305aed0 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * Adding support to perform certificate based internode authentication
(CASSANDRA-17661)
* Option to disable CDC writes of repaired data (CASSANDRA-17666)
* When a node is bootstrapping it gets the whole gossip state but applies in
random order causing some cases where StorageService will fail causing an
instance to not show up in TokenMetadata (CASSANDRA-17676)
* Add CQLSH command SHOW REPLICAS (CASSANDRA-17577)
diff --git
a/src/java/org/apache/cassandra/auth/AllowAllInternodeAuthenticator.java
b/src/java/org/apache/cassandra/auth/AllowAllInternodeAuthenticator.java
index d0d2d745d7..ac62bfae00 100644
--- a/src/java/org/apache/cassandra/auth/AllowAllInternodeAuthenticator.java
+++ b/src/java/org/apache/cassandra/auth/AllowAllInternodeAuthenticator.java
@@ -20,12 +20,14 @@
package org.apache.cassandra.auth;
import java.net.InetAddress;
+import java.security.cert.Certificate;
import org.apache.cassandra.exceptions.ConfigurationException;
public class AllowAllInternodeAuthenticator implements IInternodeAuthenticator
{
-public boolean authenticate(InetAddress remoteAddress, int remotePort)
+public boolean authenticate(InetAddress remoteAddress, int remotePort,
+Certificate[] certificates,
InternodeConnectionDirection connectionType)
{
return true;
}
diff --git a/src/java/org/apache/cassandra/auth/IInternodeAuthenticator.java
b/src/java/org/apache/cassandra/auth/IInternodeAuthenticator.java
index 8e09b9035f..02745fe925 100644
--- a/src/java/org/apache/cassandra/auth/IInternodeAuthenticator.java
+++ b/src/java/org/apache/cassandra/auth/IInternodeAuthenticator.java
@@ -20,6 +20,7 @@
package org.apache.cassandra.auth;
import java.net.InetAddress;
+import java.security.cert.Certificate;
import org.apache.cassandra.exceptions.ConfigurationException;
@@ -33,7 +34,35 @@ public interface IInternodeAuthenticator
* @param remotePort port of the connecting node.
* @return true if the connection should be accepted, false otherwise.
*/
-boolean authenticate(InetAddress remoteAddress, int remotePort);
+@Deprecated
+default boolean authenticate(InetAddress remoteAddress, int remotePort)
+{
+return false;
+}
+
+/**
+ * Decides whether a peer is allowed to connect to this node.
+ * If this method returns false, the socket will be immediately closed.
+ *
+ * Default implementation calls authenticate method by IP and port method
+ *
+ * 1. If it is IP based authentication ignore the certificates &
connectionType parameters in the implementation
+ * of this method.
+ * 2. For certificate based authentication like mTLS, server's identity
for outbound connections is verified by the
+ * trusted root certificates in the outbound_keystore. In such cases this
method may be overridden to return true
+ * when certificateType is OUTBOUND, as the authentication of the server
happens during SSL Handshake.
+ *
+ * @param remoteAddress ip address of the connecting node.
+ * @param remotePort port of the connecting node.
+ * @param certificates peer certificates
+ * @param connectionType If the connection is inbound/outbound connection.
+ * @return true if the connection should be accepted, false otherwise.
+ */
+default boolean authenticate(InetAddress remoteAddress, int remotePort,
+
[jira] [Updated] (CASSANDRA-17661) Adding support to perform certificate based internode authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17661: -- Fix Version/s: 4.2 (was: 4.x) > Adding support to perform certificate based internode authentication > > > Key: CASSANDRA-17661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17661 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.2 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Changes are to be made in IInternodeAuthenticator interface to support > certificate based authentication and to add a new pipeline in > InboundConnectionInitiator should be added to perform certificate based > authentication for internode communications. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17661) Adding support to perform certificate based internode authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17661: -- Source Control Link: https://github.com/apache/cassandra/commit/557b8e9982ad0964191abde810ef5c77a536f70a Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed into trunk as [557b8e99|https://github.com/apache/cassandra/commit/557b8e9982ad0964191abde810ef5c77a536f70a] > Adding support to perform certificate based internode authentication > > > Key: CASSANDRA-17661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17661 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Changes are to be made in IInternodeAuthenticator interface to support > certificate based authentication and to add a new pipeline in > InboundConnectionInitiator should be added to perform certificate based > authentication for internode communications. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553791#comment-17553791
]
Jon Meredith commented on CASSANDRA-16844:
--
This isn't the only recent breaking change we've had on a .x release.
CASSANDRA-17602 removes an option from the bulk loader command, which
admittedly wasn't working, however straight removal of it rather than
ignoring/warning could potentially break existing usage.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553801#comment-17553801
]
Benedict Elliott Smith commented on CASSANDRA-16844:
*Everything* needs the consent of the community, and API-impacting changes need
community buy-in. This does not mean a CEP, it means confirming the community
is happy with the proposed changes to the API. This has been discussed on
numerous occasions, including recently in the style guide ("Any strategy for
modifying APIs should be brought to d...@cassandra.apache.org for discussion.")
and in the Release Lifecycle ("Developer community will try not to make any
backwards incompatible changes") and I'm certain elsewhere.
To reiterate: whether we have a 5.0 release is irrelevant. The question is only
whether or not we *should* break any given API, and in this case I think the
answer is clearly *no* - again, whether or not we have bumped the major version.
We can bring this to the list for _further_ discussion, but I feel like it's
been covered repeatedly, and I'm sure I could find multiple references in dev@
discussions over the past year.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553802#comment-17553802
]
Benedict Elliott Smith commented on CASSANDRA-16844:
A wider discussion is also besides the point here. In this instance we should
not break the API.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553809#comment-17553809
]
Ekaterina Dimitrova commented on CASSANDRA-16844:
-
My comment about 5.0 was not in particular for this ticket, some comments made
me really thinking. Anyway, I do not want to hijack the ticket, but it raised a
few general questions. I will share them and I will follow up separately when I
am back next week, only with best intentions to our users.:)
PS[~jonmeredith] , thanks for bringing the other ticket, I just saw the patch,
agree with you. I will reopen and ping Stefan. This seems to have been
committed today so it is a quick revert, good catch. Let’s continue there.
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16844) Add number of sstables in a compaction to compactionstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553812#comment-17553812
]
Benedict Elliott Smith commented on CASSANDRA-16844:
Lots of discussions going on in parallel [~e.dimitrova] - my comment was an
attempt to respond to many different threads at once!
> Add number of sstables in a compaction to compactionstats output
>
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17602) sstableloader not respecting conf-path flag
[
https://issues.apache.org/jira/browse/CASSANDRA-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17602:
Resolution: (was: Fixed)
Status: Open (was: Resolved)
I apologize I am out these days and I didn’t manage to review this one before
commit.
Jon just brought it on another ticket. Unfortunately, it is a breaking change
and in a minor release and we cannot afford that.
Please revert it until another patch to fix the issue without breaking changes
lands.
I can help reviewing next week when I am back if there is still a need.
> sstableloader not respecting conf-path flag
> ---
>
> Key: CASSANDRA-17602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17602
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Aswin Karthik
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.5, 4.1-beta, 4.2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Hello,
> sstableloader does not seem to respect the config file flag (-f) and the
> storage port flag.
>
> We run our cluster on a different storage port with encryption. We construct
> a YAML with {{server_encryption_options}} and {{client_encryption_options}}
> and pass the storage port flag (both {{-sp}} and {{-ssp}}).
>
> However, we noticed that both the storage port flag and encryption settings
> are getting picked from the default config file {{conf/cassandra.yaml}} and
> ends up connecting to 7000 port unencrypted. As a workaround, we have added
> the storage port configuration to the YAML and copy our configuration file
> and overwrite the {{conf/cassandra.yaml}} and it is working now.
>
> Also to be noted that using the {{-f}} works in Cassandra 3.x. The bug seems
> to be present in 4.x versions only.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17602) sstableloader not respecting conf-path flag
[
https://issues.apache.org/jira/browse/CASSANDRA-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553820#comment-17553820
]
Ekaterina Dimitrova commented on CASSANDRA-17602:
-
To be more clear - my understanding is the config needs to be deprecated and
the users informed but we shouldn’t remove it, similar to what we agreed and do
for the Config class. Thanks
> sstableloader not respecting conf-path flag
> ---
>
> Key: CASSANDRA-17602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17602
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Aswin Karthik
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.5, 4.1-beta, 4.2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Hello,
> sstableloader does not seem to respect the config file flag (-f) and the
> storage port flag.
>
> We run our cluster on a different storage port with encryption. We construct
> a YAML with {{server_encryption_options}} and {{client_encryption_options}}
> and pass the storage port flag (both {{-sp}} and {{-ssp}}).
>
> However, we noticed that both the storage port flag and encryption settings
> are getting picked from the default config file {{conf/cassandra.yaml}} and
> ends up connecting to 7000 port unencrypted. As a workaround, we have added
> the storage port configuration to the YAML and copy our configuration file
> and overwrite the {{conf/cassandra.yaml}} and it is working now.
>
> Also to be noted that using the {{-f}} works in Cassandra 3.x. The bug seems
> to be present in 4.x versions only.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (a9edf97f -> 6b913c8c)
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 a9edf97f generate docs for bab3393d new 6b913c8c generate docs for bab3393d 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 (a9edf97f) \ N -- N -- N refs/heads/asf-staging (6b913c8c) 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: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - 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 (6b913c8c -> 0ab2c83e)
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 6b913c8c generate docs for bab3393d new 0ab2c83e generate docs for bab3393d 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 (6b913c8c) \ N -- N -- N refs/heads/asf-staging (0ab2c83e) 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 4740078 -> 4740078 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] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit bb5b2d28896328df5996cb0fc870b012315f0e80
Merge: 2531dd1eba f884dda75b
Author: Bereng
AuthorDate: Tue Jun 14 06:58:30 2022 +0200
Merge branch 'cassandra-3.11' into cassandra-4.0
pylib/cqlshlib/formatting.py| 4 ++--
pylib/cqlshlib/test/test_unicode.py | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --cc pylib/cqlshlib/test/test_unicode.py
index 836c2d9b8b,00..9fc052f58a
mode 100644,00..100644
--- a/pylib/cqlshlib/test/test_unicode.py
+++ b/pylib/cqlshlib/test/test_unicode.py
@@@ -1,75 -1,0 +1,79 @@@
+# coding=utf-8
+# 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.
+
+from __future__ import unicode_literals, with_statement
+
+import os
+import subprocess
+
+from .basecase import BaseTestCase
+from .cassconnect import (get_cassandra_connection, create_keyspace,
testrun_cqlsh)
++from cqlshlib.formatting import unicode_controlchars_re
+
+
+class TestCqlshUnicode(BaseTestCase):
+
+@classmethod
+def setUpClass(cls):
+s = get_cassandra_connection().connect()
+s.default_timeout = 60.0
+create_keyspace(s)
+s.execute('CREATE TABLE t (k int PRIMARY KEY, v text)')
+
+env = os.environ.copy()
+env['LC_CTYPE'] = 'UTF-8'
+cls.default_env = env
+
+def test_unicode_value_round_trip(self):
+with testrun_cqlsh(tty=True, env=self.default_env) as c:
+value = 'ϑΉӁװڜ'
+c.cmd_and_response("INSERT INTO t(k, v) VALUES (1, '%s');" %
(value,))
+output = c.cmd_and_response('SELECT * FROM t;')
+self.assertIn(value, output)
+
+def test_unicode_identifier(self):
+col_name = 'テスト'
+with testrun_cqlsh(tty=True, env=self.default_env) as c:
+c.cmd_and_response('ALTER TABLE t ADD "%s" int;' % (col_name,))
+# describe command reproduces name
+output = c.cmd_and_response('DESC t')
+self.assertIn('"%s" int' % (col_name,), output)
+c.cmd_and_response("INSERT INTO t(k, v) VALUES (1, '値');")
+# results header reproduces name
+output = c.cmd_and_response('SELECT * FROM t;')
+self.assertIn(col_name, output)
+
+def test_unicode_multiline_input(self): # CASSANDRA-16400
+with testrun_cqlsh(tty=True, env=self.default_env) as c:
+value = '値'
+c.send("INSERT INTO t(k, v) VALUES (1, \n'%s');\n" % (value,))
+c.read_to_next_prompt()
+output = c.cmd_and_response('SELECT v FROM t;')
+self.assertIn(value, output)
+
+def test_unicode_desc(self): # CASSANDRA-16539
+with testrun_cqlsh(tty=True, env=self.default_env) as c:
+v1 = 'ࠑ'
+v2 = 'Ξ'
+output = c.cmd_and_response('CREATE TYPE "%s" ( "%s" int );' %
(v1, v2))
+output = c.cmd_and_response('DESC TYPES;')
+self.assertIn(v1, output)
+output = c.cmd_and_response('DESC TYPE "%s";' %(v1,))
+self.assertIn(v2, output)
++
++def test_unicode_esc(self): # CASSANDRA-17617
++self.assertFalse(unicode_controlchars_re.match("01"))
-
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 fca2502e1dc05876640396732ec1728e16f1944d Merge: 557b8e9982 92aacd6673 Author: Bereng AuthorDate: Tue Jun 14 07:00:51 2022 +0200 Merge branch 'cassandra-4.1' into trunk pylib/cqlshlib/formatting.py| 4 ++-- pylib/cqlshlib/test/test_unicode.py | 4 2 files changed, 6 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: CQLSH unicode control character list is too liberal
This is an automated email from the ASF dual-hosted git repository. bereng pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-3.11 by this push: new f884dda75b CQLSH unicode control character list is too liberal f884dda75b is described below commit f884dda75b1427b8cb9aa64c46d30fb4c1eeffee Author: Tanuj Nayak AuthorDate: Mon Jun 13 09:59:42 2022 +0200 CQLSH unicode control character list is too liberal patch by Tanuj Nayak; reviewed by Berenguer Blasi, Brandon Williams for CASSANDRA-17617 --- pylib/cqlshlib/formatting.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pylib/cqlshlib/formatting.py b/pylib/cqlshlib/formatting.py index d87e20602a..4f60a864e6 100644 --- a/pylib/cqlshlib/formatting.py +++ b/pylib/cqlshlib/formatting.py @@ -33,8 +33,8 @@ from util import UTC is_win = platform.system() == 'Windows' -unicode_controlchars_re = re.compile(r'[\x00-\x31\x7f-\xa0]') -controlchars_re = re.compile(r'[\x00-\x31\x7f-\xff]') +unicode_controlchars_re = re.compile(r'[\x00-\x1f\x7f-\xa0]') +controlchars_re = re.compile(r'[\x00-\x1f\x7f-\xff]') def _show_control_chars(match): - 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 (2531dd1eba -> bb5b2d2889)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 2531dd1eba remove ssl storage port from sstableloader new f884dda75b CQLSH unicode control character list is too liberal new bb5b2d2889 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: pylib/cqlshlib/formatting.py| 4 ++-- pylib/cqlshlib/test/test_unicode.py | 4 2 files changed, 6 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (557b8e9982 -> fca2502e1d)
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 557b8e9982 Adding support to perform certificate based internode authentication new f884dda75b CQLSH unicode control character list is too liberal new bb5b2d2889 Merge branch 'cassandra-3.11' into cassandra-4.0 new 92aacd6673 Merge branch 'cassandra-4.0' into cassandra-4.1 new fca2502e1d 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: pylib/cqlshlib/formatting.py| 4 ++-- pylib/cqlshlib/test/test_unicode.py | 4 2 files changed, 6 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-4.1 updated (67632edc51 -> 92aacd6673)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 67632edc51 Merge branch 'cassandra-4.0' into cassandra-4.1 new f884dda75b CQLSH unicode control character list is too liberal new bb5b2d2889 Merge branch 'cassandra-3.11' into cassandra-4.0 new 92aacd6673 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: pylib/cqlshlib/formatting.py| 4 ++-- pylib/cqlshlib/test/test_unicode.py | 4 2 files changed, 6 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.
bereng pushed a commit to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 92aacd6673ce78cb891255e54653cbc9cbc19e32
Merge: 67632edc51 bb5b2d2889
Author: Bereng
AuthorDate: Tue Jun 14 06:59:45 2022 +0200
Merge branch 'cassandra-4.0' into cassandra-4.1
pylib/cqlshlib/formatting.py| 4 ++--
pylib/cqlshlib/test/test_unicode.py | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --cc pylib/cqlshlib/formatting.py
index 42c9305e76,5e2bb266df..b49a29aebd
--- a/pylib/cqlshlib/formatting.py
+++ b/pylib/cqlshlib/formatting.py
@@@ -29,8 -35,10 +29,8 @@@ from . import wcwidt
from .displaying import colorme, get_str, FormattedValue,
DEFAULT_VALUE_COLORS, NO_COLOR_MAP
from .util import UTC
- unicode_controlchars_re = re.compile(r'[\x00-\x31\x7f-\xa0]')
- controlchars_re = re.compile(r'[\x00-\x31\x7f-\xff]')
-is_win = platform.system() == 'Windows'
-
+ unicode_controlchars_re = re.compile(r'[\x00-\x1f\x7f-\xa0]')
+ controlchars_re = re.compile(r'[\x00-\x1f\x7f-\xff]')
def _show_control_chars(match):
diff --cc pylib/cqlshlib/test/test_unicode.py
index a1e842d437,9fc052f58a..d24a78736e
--- a/pylib/cqlshlib/test/test_unicode.py
+++ b/pylib/cqlshlib/test/test_unicode.py
@@@ -15,10 -15,14 +15,11 @@@
# See the License for the specific language governing permissions and
# limitations under the License.
-from __future__ import unicode_literals, with_statement
-
import os
-import subprocess
from .basecase import BaseTestCase
-from .cassconnect import (get_cassandra_connection, create_keyspace,
testrun_cqlsh)
+from .cassconnect import (get_cassandra_connection, create_keyspace,
remove_db, testrun_cqlsh)
+ from cqlshlib.formatting import unicode_controlchars_re
class TestCqlshUnicode(BaseTestCase):
@@@ -72,5 -72,8 +73,8 @@@
output = c.cmd_and_response('CREATE TYPE "%s" ( "%s" int );' %
(v1, v2))
output = c.cmd_and_response('DESC TYPES;')
self.assertIn(v1, output)
-output = c.cmd_and_response('DESC TYPE "%s";' %(v1,))
+output = c.cmd_and_response('DESC TYPE "%s";' % (v1,))
self.assertIn(v2, output)
+
+ def test_unicode_esc(self): # CASSANDRA-17617
+ self.assertFalse(unicode_controlchars_re.match("01"))
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17617: Status: Review In Progress (was: Patch Available) > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1-rc > > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17617: Status: Ready to Commit (was: Review In Progress) > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1-rc > > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17617: Fix Version/s: 3.11.14 4.0.5 4.x (was: 3.11.x) (was: 4.0.x) Source Control Link: https://github.com/apache/cassandra/commit/f884dda75b1427b8cb9aa64c46d30fb4c1eeffee Resolution: Fixed Status: Resolved (was: Ready to Commit) > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.14, 4.0.5, 4.1-rc, 4.x > > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17617) CQLSH unicode control character list is too liberal
[ https://issues.apache.org/jira/browse/CASSANDRA-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553896#comment-17553896 ] Berenguer Blasi commented on CASSANDRA-17617: - Merged. Thanks [~tanujnay] for your hard work! > CQLSH unicode control character list is too liberal > --- > > Key: CASSANDRA-17617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17617 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Tanuj Nayak >Assignee: Tanuj Nayak >Priority: Normal > Fix For: 3.11.14, 4.0.5, 4.1-rc, 4.x > > > It appears that the list of escaped unicode control characters > [here|https://github.com/apache/cassandra/blob/53a67ff2c36d90d337aba1409498de29931d4279/pylib/cqlshlib/formatting.py#L32] > is a bit too liberal. It seems to include characters such as '1' (0x31) and > '0' (0x30) which do not need to be escaped. It seems that the actual range > should be 0x00 - 0x1F and 0x7F+ as corroborated [by this > page|https://en.wikipedia.org/wiki/Unicode_control_characters]. > > This causes unnecessary escaping and regex substitutions on the CQLSH end > whenever common characters such as any punctuation or a 0 or a 1 appear in > the text column of a table. One might notice that a table with a text column > filled with 2's will take much less time to print than one with all 0's for > this reason. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17083) testsome target doesn't work with wildcards
[
https://issues.apache.org/jira/browse/CASSANDRA-17083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553897#comment-17553897
]
Berenguer Blasi commented on CASSANDRA-17083:
-
Hi, moving this to review for the small original fix just to close loose ends.
We can always open a new ticket for any further improvements which are always
welcomed :-)
> testsome target doesn't work with wildcards
> ---
>
> Key: CASSANDRA-17083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17083
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Berenguer Blasi
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Running {{ant test -Dtest.name=PasswordObfuscator*Test}} runs the test
> correctly. But {{ant testsome -Dtest.name=PasswordObfuscator*Test}} will make
> it fail like
> {noformat}
> [junit-timeout] Testsuite: org.apache.cassandra.cql3.PasswordObfuscatorTest
> [junit-timeout] Testsuite: org.apache.cassandra.cql3.PasswordObfuscatorTest
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.038 sec
> [junit-timeout]
> [junit-timeout] Testsuite: PasswordObfuscator*Test
> [junit-timeout] Testsuite: PasswordObfuscator*Test Tests run: 1, Failures: 0,
> Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout]
> [junit-timeout] Null Test:Caused an ERROR
> [junit-timeout] PasswordObfuscator*Test
> [junit-timeout] java.lang.ClassNotFoundException: PasswordObfuscator*Test
> [junit-timeout] at
> java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> [junit-timeout] at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> [junit-timeout] at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> [junit-timeout] at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> [junit-timeout] at java.lang.Class.forName0(Native Method)
> [junit-timeout] at java.lang.Class.forName(Class.java:348)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test PasswordObfuscator*Test FAILED
> {noformat}
> We should fix testsome as this is a useful feature for 'families' of tests
> such as {{ViewComplex*Test}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17083) testsome target doesn't work with wildcards
[
https://issues.apache.org/jira/browse/CASSANDRA-17083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17083:
Authors: Berenguer Blasi, Bernardo Botella Corbi (was:
Bernardo Botella Corbi)
Test and Documentation Plan: See PR (was: Posted a fix for double test
running)
Status: Patch Available (was: In Progress)
> testsome target doesn't work with wildcards
> ---
>
> Key: CASSANDRA-17083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17083
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Berenguer Blasi
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Running {{ant test -Dtest.name=PasswordObfuscator*Test}} runs the test
> correctly. But {{ant testsome -Dtest.name=PasswordObfuscator*Test}} will make
> it fail like
> {noformat}
> [junit-timeout] Testsuite: org.apache.cassandra.cql3.PasswordObfuscatorTest
> [junit-timeout] Testsuite: org.apache.cassandra.cql3.PasswordObfuscatorTest
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.038 sec
> [junit-timeout]
> [junit-timeout] Testsuite: PasswordObfuscator*Test
> [junit-timeout] Testsuite: PasswordObfuscator*Test Tests run: 1, Failures: 0,
> Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout]
> [junit-timeout] Null Test:Caused an ERROR
> [junit-timeout] PasswordObfuscator*Test
> [junit-timeout] java.lang.ClassNotFoundException: PasswordObfuscator*Test
> [junit-timeout] at
> java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> [junit-timeout] at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> [junit-timeout] at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> [junit-timeout] at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> [junit-timeout] at java.lang.Class.forName0(Native Method)
> [junit-timeout] at java.lang.Class.forName(Class.java:348)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test PasswordObfuscator*Test FAILED
> {noformat}
> We should fix testsome as this is a useful feature for 'families' of tests
> such as {{ViewComplex*Test}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
