[cassandra-website] branch asf-staging updated (072448fc -> 37f49175)
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 072448fc generate docs for 6f603a2c new 37f49175 generate docs for 6f603a2c 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 (072448fc) \ N -- N -- N refs/heads/asf-staging (37f49175) 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 4970139 -> 4970139 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] [Commented] (CASSANDRA-16555) Add out-of-the-box snitch for Ec2 IMDSv2
[ https://issues.apache.org/jira/browse/CASSANDRA-16555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643700#comment-17643700 ] Erick Ramirez commented on CASSANDRA-16555: --- Thanks for putting this together. 👍 Does the PR apply to the current supported versions (3.0, 3.11, 4.x)? 🙂 > Add out-of-the-box snitch for Ec2 IMDSv2 > > > Key: CASSANDRA-16555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16555 > Project: Cassandra > Issue Type: New Feature > Components: Consistency/Coordination >Reporter: Paul Rütter (BlueConic) >Assignee: fulco taen >Priority: Normal > Time Spent: 1.5h > Remaining Estimate: 0h > > In order to patch a vulnerability, Amazon came up with a new version of their > metadata service. > It's no longer unrestricted but now requires a token (in a header), in order > to access the metadata service. > See > [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html] > for more information. > Cassandra currently doesn't offer an out-of-the-box snitch class to support > this. > See > [https://cassandra.apache.org/doc/latest/operating/snitch.html#snitch-classes] > This issue asks to add support for this as a separate snitch class. > We'll probably do a PR for this, as we are in the process of developing one. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18095) WEBSITE - Publish C* Day China in Events section
[ https://issues.apache.org/jira/browse/CASSANDRA-18095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-18095: -- Change Category: Semantic Complexity: Normal Component/s: Documentation/Website Fix Version/s: NA Status: Open (was: Triage Needed) > WEBSITE - Publish C* Day China in Events section > > > Key: CASSANDRA-18095 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18095 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > > PLACEHOLDER - Working with Tom Lu to publicise the C* Day China event on the > Cassandra website once approved by the PMC. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18095) WEBSITE - Publish C* Day China in Events section
[ https://issues.apache.org/jira/browse/CASSANDRA-18095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-18095: -- Description: PLACEHOLDER - Working with Tom Lu to publicise the C* Day China event on the Cassandra website once approved by the PMC. (was: WEBSITE - Publish C* Day China in Events section) > WEBSITE - Publish C* Day China in Events section > > > Key: CASSANDRA-18095 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18095 > Project: Cassandra > Issue Type: Task >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > > PLACEHOLDER - Working with Tom Lu to publicise the C* Day China event on the > Cassandra website once approved by the PMC. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18095) WEBSITE - Publish C* Day China in Events section
Erick Ramirez created CASSANDRA-18095: - Summary: WEBSITE - Publish C* Day China in Events section Key: CASSANDRA-18095 URL: https://issues.apache.org/jira/browse/CASSANDRA-18095 Project: Cassandra Issue Type: Task Reporter: Erick Ramirez Assignee: Erick Ramirez WEBSITE - Publish C* Day China in Events section -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (b9f03acb -> 072448fc)
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 b9f03acb generate docs for 6f603a2c new 072448fc generate docs for 6f603a2c 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 (b9f03acb) \ N -- N -- N refs/heads/asf-staging (072448fc) 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 4970139 -> 4970139 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-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-17848:
--
Source Control Link:
https://github.com/apache/cassandra/commit/473656c1d53edb998aa60d414221e397797de52b
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed in to cassandra-3.0 as
[473656c1d53https://github.com/apache/cassandra/commit/473656c1d53edb998aa60d414221e397797de52b]
and merged up to trunk.
> Fix incorrect resource name in LIST PERMISSION output
> -
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "ConfigurationException: Unable to
> find abstract-type class".
> The bug is discovered by Piotr Sarna.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643631#comment-17643631
]
Yifan Cai edited comment on CASSANDRA-17848 at 12/6/22 3:02 AM:
Committed in to cassandra-3.0 as
[473656c1d53|https://github.com/apache/cassandra/commit/473656c1d53edb998aa60d414221e397797de52b]
and merged up to trunk.
was (Author: yifanc):
Committed in to cassandra-3.0 as
[473656c1d53https://github.com/apache/cassandra/commit/473656c1d53edb998aa60d414221e397797de52b]
and merged up to trunk.
> Fix incorrect resource name in LIST PERMISSION output
> -
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "ConfigurationException: Unable to
> find abstract-type class".
> The bug is discovered by Piotr Sarna.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-17848:
--
Status: Ready to Commit (was: Review In Progress)
> Fix incorrect resource name in LIST PERMISSION output
> -
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "ConfigurationException: Unable to
> find abstract-type class".
> The bug is discovered by Piotr Sarna.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (33c60d8daf -> 235d2df0ee)
This is an automated email from the ASF dual-hosted git repository. ycai pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 33c60d8daf Merge branch 'cassandra-4.1' into trunk add 473656c1d5 Fix incorrect resource name in LIST PERMISSION output add eb91e2c354 Merge branch 'cassandra-3.0' into cassandra-3.11 add f22263cd8a Merge branch 'cassandra-3.11' into cassandra-4.0 add 27fff06bb7 Merge branch 'cassandra-4.0' into cassandra-4.1 new 235d2df0ee 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 + .../apache/cassandra/auth/FunctionResource.java| 25 +--- .../cassandra/cql3/functions/FunctionName.java | 26 + .../schema/CreateAggregateStatement.java | 3 ++ .../statements/schema/CreateFunctionStatement.java | 3 ++ .../cassandra/auth/FunctionResourceTest.java | 33 ++ .../cassandra/cql3/validation/entities/UFTest.java | 23 ++- .../validation/operations/AggregationTest.java | 17 +++ 8 files changed, 115 insertions(+), 16 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. ycai pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 235d2df0eea4a2c70bbdcb1b9f4d2e121080f4c3 Merge: 33c60d8daf 27fff06bb7 Author: Yifan Cai AuthorDate: Mon Dec 5 18:57:19 2022 -0800 Merge branch 'cassandra-4.1' into trunk CHANGES.txt| 1 + .../apache/cassandra/auth/FunctionResource.java| 25 +--- .../cassandra/cql3/functions/FunctionName.java | 26 + .../schema/CreateAggregateStatement.java | 3 ++ .../statements/schema/CreateFunctionStatement.java | 3 ++ .../cassandra/auth/FunctionResourceTest.java | 33 ++ .../cassandra/cql3/validation/entities/UFTest.java | 23 ++- .../validation/operations/AggregationTest.java | 17 +++ 8 files changed, 115 insertions(+), 16 deletions(-) diff --cc CHANGES.txt index 79590ddad6,a36662ba48..68a73159cc --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -158,11 -88,6 +158,12 @@@ Merged from 3.11 * Creating of a keyspace on insufficient number of replicas should filter out gosspping-only members (CASSANDRA-17759) * Suppress CVE-2022-25857 and other snakeyaml CVEs (CASSANDRA-17907) Merged from 3.0: ++ * Fix incorrect resource name in LIST PERMISSION output (CASSANDRA-17848) + * Suppress CVE-2022-41854 and similar (CASSANDRA-18083) + * Fix running Ant rat targets without git (CASSANDRA-17974) + * Harden JMX by resolving beanshooter issues (CASSANDRA-17921) + * Suppress CVE-2019-2684 (CASSANDRA-17965) + * Fix auto-completing "WITH" when creating a materialized view (CASSANDRA-17879) * Improve libjemalloc resolution in bin/cassandra (CASSANDRA-15767) * Fix restarting of services on gossipping-only member (CASSANDRA-17752) * Fix scrubber falling into infinite loop when the last partition is broken (CASSANDRA-17862) - 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 (8889b27c9c -> 27fff06bb7)
This is an automated email from the ASF dual-hosted git repository. ycai pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 8889b27c9c Merge branch 'cassandra-4.0' into cassandra-4.1 add 473656c1d5 Fix incorrect resource name in LIST PERMISSION output add eb91e2c354 Merge branch 'cassandra-3.0' into cassandra-3.11 add f22263cd8a Merge branch 'cassandra-3.11' into cassandra-4.0 add 27fff06bb7 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/auth/FunctionResource.java| 25 +--- .../cassandra/cql3/functions/FunctionName.java | 26 + .../schema/CreateAggregateStatement.java | 3 ++ .../statements/schema/CreateFunctionStatement.java | 3 ++ .../cassandra/auth/FunctionResourceTest.java | 33 ++ .../cassandra/cql3/validation/entities/UFTest.java | 23 ++- .../validation/operations/AggregationTest.java | 17 +++ 8 files changed, 115 insertions(+), 16 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (92019df4d8 -> 473656c1d5)
This is an automated email from the ASF dual-hosted git repository. ycai pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 92019df4d8 Suppress CVE-2022-41854 and similar add 473656c1d5 Fix incorrect resource name in LIST PERMISSION output No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/auth/FunctionResource.java| 25 +--- .../cassandra/cql3/functions/FunctionName.java | 26 + .../cql3/statements/CreateAggregateStatement.java | 3 ++ .../cql3/statements/CreateFunctionStatement.java | 3 ++ .../cassandra/auth/FunctionResourceTest.java | 33 ++ .../cassandra/cql3/validation/entities/UFTest.java | 23 +-- .../validation/operations/AggregationTest.java | 17 +++ 8 files changed, 114 insertions(+), 17 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 (c2bbee2020 -> f22263cd8a)
This is an automated email from the ASF dual-hosted git repository. ycai pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from c2bbee2020 Merge branch 'cassandra-3.11' into cassandra-4.0 add 473656c1d5 Fix incorrect resource name in LIST PERMISSION output add eb91e2c354 Merge branch 'cassandra-3.0' into cassandra-3.11 add f22263cd8a Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/auth/FunctionResource.java| 25 +--- .../cassandra/cql3/functions/FunctionName.java | 26 + .../schema/CreateAggregateStatement.java | 3 ++ .../statements/schema/CreateFunctionStatement.java | 3 ++ .../cassandra/auth/FunctionResourceTest.java | 33 ++ .../cassandra/cql3/validation/entities/UFTest.java | 23 ++- .../validation/operations/AggregationTest.java | 17 +++ 8 files changed, 115 insertions(+), 16 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 (b7762e2aa2 -> eb91e2c354)
This is an automated email from the ASF dual-hosted git repository. ycai pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from b7762e2aa2 Merge branch 'cassandra-3.0' into cassandra-3.11 add 473656c1d5 Fix incorrect resource name in LIST PERMISSION output add eb91e2c354 Merge branch 'cassandra-3.0' into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/auth/FunctionResource.java| 25 +--- .../cassandra/cql3/functions/FunctionName.java | 26 + .../cql3/statements/CreateAggregateStatement.java | 3 ++ .../cql3/statements/CreateFunctionStatement.java | 3 ++ .../cassandra/auth/FunctionResourceTest.java | 33 ++ .../cassandra/cql3/validation/entities/UFTest.java | 23 ++- .../validation/operations/AggregationTest.java | 17 +++ 8 files changed, 115 insertions(+), 16 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643628#comment-17643628 ] Ekaterina Dimitrova commented on CASSANDRA-18077: - bq. I set version to NA when its not a bug but just some internal detail... I guess I can set 4.x If it will be applicable only to trunk (which I suspect it is), yes, please, 4.x :-) Other than that posting here a few questions we discussed earlier for completeness: - currently SpotBugs provides JDK8 support, JDK11 is experimental and going to newer releases is missing...yet. Not sure when/whether they plan to change that but it is a thing considering we aim to get rid of JDK8. - As it was requested on the mailing list, we need to double-check with legal the license - So as you explained we will be raising only the high priority issues. I think the list should be probably raised to the ML on the same thread for visibility so no one complains when they got blocked on something later. The full list is 400 items, I am not sure which of them are high priority > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > Attachments: spotbugs.html > > Time Spent: 50m > Remaining Estimate: 0h > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (babc0b1d -> b9f03acb)
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 babc0b1d generate docs for 6f603a2c new b9f03acb generate docs for 6f603a2c 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 (babc0b1d) \ N -- N -- N refs/heads/asf-staging (b9f03acb) 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 4970139 -> 4970139 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] [Commented] (CASSANDRA-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643608#comment-17643608 ] David Capwell commented on CASSANDRA-18077: --- I set version to NA when its not a bug but just some internal detail... I guess I can set 4.x > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > Attachments: spotbugs.html > > Time Spent: 40m > Remaining Estimate: 0h > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14930) decommission may cause timeout because messaging backlog is cleared
[
https://issues.apache.org/jira/browse/CASSANDRA-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643605#comment-17643605
]
Zhao Yang commented on CASSANDRA-14930:
---
[~smiklosovic] I will be on leaves for quite a while. Could you please take
over? thank you!
> decommission may cause timeout because messaging backlog is cleared
>
>
> Key: CASSANDRA-14930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14930
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Core
>Reporter: Zhao Yang
>Assignee: Zhao Yang
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> On a 3-node cluster with RF=2, decommissioning a node may cause quorum write
> timeout because messaging backlog to decommissioned node is cleared via
> {{Gossiper#removeEndpoint() -> OutboundTcpConnection#closeSocket()}}.
> (Timeout is less likely to happen with RF=3, because we can afford one less
> response)
> {code:java}
> What happened:
> 1. [WriteStage] before the leaving node is removed from tokenmetadata, the
> write endpoints are generated ( leaving endpoint is included )
> 2. [GossipStage] the leaving node is removed from tokenmetadata, no more
> future write handler will include leaving endpoints
> 3. [WriteStage] write handlers sends messages to messaging-service backlog
> 4. [GossipStage] messaging-service backlog is cleared, messages are not sent
> and connection closed
> 5. [WriteStage] write time out
> {code}
> |patch|
> |[3.0|https://github.com/jasonstack/cassandra/commits/decommission_timeout_3.0]|
> |[3.11|https://github.com/jasonstack/cassandra/commits/decommission_timeout_3.11]|
> We can avoid it by delaying to destroy messaging connection so that messages
> are sent and responded. This patch also avoids reopening already closed
> connection on {{MessagingService#convict()}}.
> New messaging framework rewrite in {{Trunk}} avoids the issues by not
> clearing messaging backlog.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14930) decommission may cause timeout because messaging backlog is cleared
[
https://issues.apache.org/jira/browse/CASSANDRA-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643607#comment-17643607
]
Zhao Yang commented on CASSANDRA-14930:
---
[~azotcsit] sorry, I missed the notification. thanks for the feedback
> decommission may cause timeout because messaging backlog is cleared
>
>
> Key: CASSANDRA-14930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14930
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Core
>Reporter: Zhao Yang
>Assignee: Zhao Yang
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> On a 3-node cluster with RF=2, decommissioning a node may cause quorum write
> timeout because messaging backlog to decommissioned node is cleared via
> {{Gossiper#removeEndpoint() -> OutboundTcpConnection#closeSocket()}}.
> (Timeout is less likely to happen with RF=3, because we can afford one less
> response)
> {code:java}
> What happened:
> 1. [WriteStage] before the leaving node is removed from tokenmetadata, the
> write endpoints are generated ( leaving endpoint is included )
> 2. [GossipStage] the leaving node is removed from tokenmetadata, no more
> future write handler will include leaving endpoints
> 3. [WriteStage] write handlers sends messages to messaging-service backlog
> 4. [GossipStage] messaging-service backlog is cleared, messages are not sent
> and connection closed
> 5. [WriteStage] write time out
> {code}
> |patch|
> |[3.0|https://github.com/jasonstack/cassandra/commits/decommission_timeout_3.0]|
> |[3.11|https://github.com/jasonstack/cassandra/commits/decommission_timeout_3.11]|
> We can avoid it by delaying to destroy messaging connection so that messages
> are sent and responded. This patch also avoids reopening already closed
> connection on {{MessagingService#convict()}}.
> New messaging framework rewrite in {{Trunk}} avoids the issues by not
> clearing messaging backlog.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17178) CEP-10: Simulator Java11 Support
[ https://issues.apache.org/jira/browse/CASSANDRA-17178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643600#comment-17643600 ] David Capwell commented on CASSANDRA-17178: --- bq. I know that simulator tests are passing, but do we want to add a particular test? I don't see much of a benefit, that would be testing the test. > CEP-10: Simulator Java11 Support > > > Key: CASSANDRA-17178 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17178 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > Java11 introduces new protection domains for package private methods, so that > classes loaded with different class loaders may not access each others’ > package private methods, regardless of the package they are declared within. > There are differences within the JDK also, and there may be byte weaving > targets that need updating (ThreadLocalRandom was one that has been handled) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18091) Column update lost after a full stop upgrade from 4.0.6 to trunk (4.2:fdc88a)
[
https://issues.apache.org/jira/browse/CASSANDRA-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ke Han updated CASSANDRA-18091:
---
Description:
When we performed a full-stop upgrade from release 4.0.6 to 4.2 trunk (fdc88a),
we executed the same read command before and after the upgrade and found that
some column updates were lost after the upgrade.
This inconsistency is likely related to timing and cannot be reproduced
deterministically. Though it's non-deterministic, this failure *happens
reliably* *once every ten times* when executing the following command sequence.
h2. Steps to reproduce
1. Set up a 4.0.6 3-node cluster. (N0: seed node, N1, N2). Default
configurations, set num_tokens to 256.
2. Execute the following cqlsh command at N0
(The test commands use random parameters because it is generated by our
testing tool)
{code:java}
CREATE KEYSPACE uuid5f86250110a247d48c481c5579cb2ea1 WITH REPLICATION = {
'class' : 'SimpleStrategy', 'replication_factor' : 1 };
CREATE TABLE uuid5f86250110a247d48c481c5579cb2ea1.kattmG (kattmG TEXT,VldG
TEXT,Ajqm TEXT,lTQSQ INT,EVzlSKrbkUGyhJshH TEXT, PRIMARY KEY (lTQSQ ));
DELETE FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG WHERE lTQSQ = 2;
ALTER TABLE uuid5f86250110a247d48c481c5579cb2ea1.kattmG DROP kattmG ;
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (Ajqm,
EVzlSKrbkUGyhJshH, lTQSQ) VALUES
('nZJzNjYnXOwPLpVoFSVwxcvznsDFBYqmlprrVXYJQLzYvYkrmfEsiuAcCtggypnxIkIevRHyPQGOWrIZNObJ','RaAhbVKUQzgJaupaupKPVnNLLYDaZEaMyFteVwhLePqZwikuBEsVDxTuTqBfkFYmeMMsOFXjVkObZduPfAFsLzuYlrgpYsPPxDNQCRzzPaEdWHARnnWbAFAUUnbYnvEESeHDRHSkEhSnoREprrHWasYLMSocIYiMGQXjzsaKptqbtPgrztIdpQLgDAZOPfhJIblmwTFAWiFbzrbTkFwJGP',1693380861);
DELETE FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG WHERE lTQSQ =
1693380861;
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (lTQSQ) VALUES (2);
ALTER TABLE uuid5f86250110a247d48c481c5579cb2ea1.kattmG DROP VldG ;
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (lTQSQ) VALUES
(1693380861);
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (Ajqm, lTQSQ) VALUES
('ldrsHa',1693380861);
ALTER TABLE uuid5f86250110a247d48c481c5579cb2ea1.kattmG DROP Ajqm ;{code}
3. Execute a SELECT command at N0, and get results
{code:java}
SELECT lTQSQ FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG;
ltqsq
1693380861
2
(2 rows){code}
4. Perform a full-stop upgrade. (Set num_tokens to 256)
1. Drain N0, stop N0.
2. Drain N1, stop N1.
3. Drain N2, stop N2.
4. Start up N0.
5. Start up N1.
6. Start up N2.
5. Execute the same SELECT command at N0, and get results
{code:java}
SELECT lTQSQ FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG;
ltqsq
---
2
(1 rows){code}
Or
{code:java}
SELECT lTQSQ FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG;
ltqsq
---
(0 rows){code}
The new result is inconsistent with the old version's result. The insert update
is lost.
was:
When we performed a full-stop upgrade from release 4.0.6 to 4.2 trunk (fdc88a),
we executed the same read command before and after the upgrade and found that
some column updates were lost after the upgrade.
This inconsistency is likely related to timing and cannot be reproduced
deterministically. Though it's non-deterministic, this failure *happens
reliably* *once every ten times* when executing the following command sequence.
h2. Steps to reproduce
1. Set up a 4.0.6 3-node cluster. (N0: seed node, N1, N2). Default
configurations, set num_tokens to 256.
2. Execute the following cqlsh command
(The test commands use random parameters because it is generated by our
testing tool)
{code:java}
CREATE KEYSPACE uuid5f86250110a247d48c481c5579cb2ea1 WITH REPLICATION = {
'class' : 'SimpleStrategy', 'replication_factor' : 1 };
CREATE TABLE uuid5f86250110a247d48c481c5579cb2ea1.kattmG (kattmG TEXT,VldG
TEXT,Ajqm TEXT,lTQSQ INT,EVzlSKrbkUGyhJshH TEXT, PRIMARY KEY (lTQSQ ));
DELETE FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG WHERE lTQSQ = 2;
ALTER TABLE uuid5f86250110a247d48c481c5579cb2ea1.kattmG DROP kattmG ;
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (Ajqm,
EVzlSKrbkUGyhJshH, lTQSQ) VALUES
('nZJzNjYnXOwPLpVoFSVwxcvznsDFBYqmlprrVXYJQLzYvYkrmfEsiuAcCtggypnxIkIevRHyPQGOWrIZNObJ','RaAhbVKUQzgJaupaupKPVnNLLYDaZEaMyFteVwhLePqZwikuBEsVDxTuTqBfkFYmeMMsOFXjVkObZduPfAFsLzuYlrgpYsPPxDNQCRzzPaEdWHARnnWbAFAUUnbYnvEESeHDRHSkEhSnoREprrHWasYLMSocIYiMGQXjzsaKptqbtPgrztIdpQLgDAZOPfhJIblmwTFAWiFbzrbTkFwJGP',1693380861);
DELETE FROM uuid5f86250110a247d48c481c5579cb2ea1.kattmG WHERE lTQSQ =
1693380861;
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (lTQSQ) VALUES (2);
ALTER TABLE uuid5f86250110a247d48c481c5579cb2ea1.kattmG DROP VldG ;
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (lTQSQ) VALUES
(1693380861);
INSERT INTO uuid5f86250110a247d48c481c5579cb2ea1.kattmG (Ajqm, lTQSQ) VALUES
('ldrsHa',1693380861);
ALTER TABLE u
[cassandra-website] branch asf-staging updated (496e306b -> babc0b1d)
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 496e306b generate docs for 6f603a2c new babc0b1d generate docs for 6f603a2c 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 (496e306b) \ N -- N -- N refs/heads/asf-staging (babc0b1d) 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 4970139 -> 4970139 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-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18088:
-
Fix Version/s: 4.x
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-18088:
Assignee: Brandon Williams
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18055) Nodetool Compact set the compaction type incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-18055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643579#comment-17643579
]
Ekaterina Dimitrova commented on CASSANDRA-18055:
-
[~barnie], do you mind to take a look into this small patch, please?
> Nodetool Compact set the compaction type incorrectly
>
>
> Key: CASSANDRA-18055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18055
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Tool/nodetool
>Reporter: maxwellguo
>Assignee: maxwellguo
>Priority: Low
> Fix For: 4.x
>
> Attachments: 20221116235846.jpg
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When using nodetool compactionstats to see what does the c*'s compactions are
> doing ,the output has got a column named "compaction type", but It seem that
> major compaction and minor compaction 's type are all name Compaction, after
> read the code I found that may be the the MAJOR_COMPACTION OperationType is
> not setted into AbstractCompactionTask
> at this method : CompactionStrategyManager -> getMaximalTasks .When we peform
> a major compact without any arguments we will got this execute path :
> {code:java}
> // Some comments here
> Compact.java : probe.forceKeyspaceCompaction(splitOutput, keyspace,
> tableNames);
> --->
> ColumnFamilyStore.java : cfStore.forceMajorCompaction(splitOutput);
> --->
> CompactionManager.java : submitMaximal(cfStore, gcBefore, splitOutput,
> OperationType.MAJOR_COMPACTION);
> {code}
> Unfortunately OperationType.MAJOR_COMPACTION is not rightly setted.
> see the picture on the right I perform a major compact , and on the left the
> compactionstats show the type is only Compaction ;
> I think it is import for us to know wether the task is a major or a minor .
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18055) Nodetool Compact set the compaction type incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-18055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18055:
Status: Review In Progress (was: Needs Committer)
> Nodetool Compact set the compaction type incorrectly
>
>
> Key: CASSANDRA-18055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18055
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Tool/nodetool
>Reporter: maxwellguo
>Assignee: maxwellguo
>Priority: Low
> Fix For: 4.x
>
> Attachments: 20221116235846.jpg
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When using nodetool compactionstats to see what does the c*'s compactions are
> doing ,the output has got a column named "compaction type", but It seem that
> major compaction and minor compaction 's type are all name Compaction, after
> read the code I found that may be the the MAJOR_COMPACTION OperationType is
> not setted into AbstractCompactionTask
> at this method : CompactionStrategyManager -> getMaximalTasks .When we peform
> a major compact without any arguments we will got this execute path :
> {code:java}
> // Some comments here
> Compact.java : probe.forceKeyspaceCompaction(splitOutput, keyspace,
> tableNames);
> --->
> ColumnFamilyStore.java : cfStore.forceMajorCompaction(splitOutput);
> --->
> CompactionManager.java : submitMaximal(cfStore, gcBefore, splitOutput,
> OperationType.MAJOR_COMPACTION);
> {code}
> Unfortunately OperationType.MAJOR_COMPACTION is not rightly setted.
> see the picture on the right I perform a major compact , and on the left the
> compactionstats show the type is only Compaction ;
> I think it is import for us to know wether the task is a major or a minor .
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18079) Print exception message without stacktrace when nodetool commands fail on probe.getOwnershipWithPort()
[
https://issues.apache.org/jira/browse/CASSANDRA-18079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18079:
--
Summary: Print exception message without stacktrace when nodetool commands
fail on probe.getOwnershipWithPort() (was: Log better message when nodetool
commands can not get probe.getOwnershipWithPort())
> Print exception message without stacktrace when nodetool commands fail on
> probe.getOwnershipWithPort()
> --
>
> Key: CASSANDRA-18079
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18079
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: lhf, nodetool
> Fix For: 4.x
>
>
> When status, ring or describecluster nodetool commands are executed while a
> node which is queried is not fully bootstrapped / started, it can throw this
> exception:
> {code:java}
> cassandra_node_4 | error: No nodes present in the cluster. Has this node
> finished starting up?
> cassandra_node_4 | -- StackTrace --
> cassandra_node_4 | java.lang.RuntimeException: No nodes present in the
> cluster. Has this node finished starting up?
> cassandra_node_4 | at
> org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:303)
> cassandra_node_4 | at
> org.apache.cassandra.service.StorageService.getOwnershipWithPort(StorageService.java:5751)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> cassandra_node_4 | at
> jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
> cassandra_node_4 | at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:641)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> cassandra_node_4 | at
> java.management/com.sun.jmx.remote.security.MBeanServerAccessController.getAttribute(MBeanServerAccessController.java:320)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1443)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
> cassandra_node_4 | at
> java.base/java.security.AccessController.doPrivileged(Native Method)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1406)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:637)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
> cassandra_node_4 | at
>
[jira] [Updated] (CASSANDRA-18086) Bug fix for 'wait' time to be in nanoseconds for consistency instead of microseconds
[ https://issues.apache.org/jira/browse/CASSANDRA-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-18086: -- Status: Patch Available (was: Open) > Bug fix for 'wait' time to be in nanoseconds for consistency instead of > microseconds > > > Key: CASSANDRA-18086 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18086 > Project: Cassandra > Issue Type: Bug > Components: Feature/Lightweight Transactions >Reporter: Marianne Lyne Manaog >Assignee: Marianne Lyne Manaog >Priority: Normal > Fix For: 4.1.x, 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > While working on benchmarking Paxos improvements in OSS Cassandra, > [~benedict] was asked to review the work and thus found that the wait time > was input in microseconds but then output incorrectly in the > ContentionStrategy.java file, i.e., by summing up a wait time in nanoseconds > with another wait time in microseconds (two different units used mistakenly). > So, Benedict suggested the fix whereby the output wait time was then enforced > to be consistently in nanoseconds. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18086) Bug fix for 'wait' time to be in nanoseconds for consistency instead of microseconds
[
https://issues.apache.org/jira/browse/CASSANDRA-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643558#comment-17643558
]
Josh McKenzie commented on CASSANDRA-18086:
---
The patch LGTM. I have some slight concerns with {{ContentionStrategy.java}} as
I read through it to convince myself this patch is correct; there's little to
no documentation about the expectation of units being passed into various
functions nor annotation around the unit being passed back out. I also have the
luxury of having another implementation of this to compare the upstreamed to;
the original did indeed have a slightly different approach to calculating wait
that made it clear the intent there:
{code:java}
long wait =
MICROSECONDS.toNanos(ThreadLocalRandom.current().nextLong(minWaitMicros,
maxWaitMicros)); {code}
In this case, while simple inspection of the code after the fact of observing
the regression shows probable unit mismatch:
{code:java}
long minWaitMicros = min.get(attempts);
long maxWaitMicros = max.get(attempts);
long minDeltaMicros = minDelta.get(attempts);
if (minWaitMicros + minDeltaMicros > maxWaitMicros)
{
maxWaitMicros = minWaitMicros + minDeltaMicros;
if (maxWaitMicros > this.max.max)
{
maxWaitMicros = this.max.max;
minWaitMicros = max(this.min.min, min(this.min.max,
maxWaitMicros - minDeltaMicros));
}
}
// REVIEW EDIT: micros go in, have to assume micros come back out?
long wait = waitRandomizer.wait(minWaitMicros, maxWaitMicros, attempts);
return nanoTime() + wait;
}
{code}
My broad concern is that the lack of annotation about expected units of time
for any of the {{WaitInterface}} implementers in the class as well as other
supporting methods leave ambiguity that _theoretically_ encourages this class
of error.
Now, that said, many (most? all?) of these supporting functions are actually
time unit agnostic so could be used for both nano and microsecond precision
units, so there's an argument here to not clutter the interface and
implementation of things w/names or comments that bind us to a certain unit of
operation. If we back out to the primary user of this in {{Paxos.cas()}} we can
see that the primary proposeDeadline and commitDeadline are in nanos and
extrapolate.
So that's all editorial concern about the lack of annotation in the class, well
outside the scope of the change here to unblock 4.1 GA. So I'm +1 on the
correctness of what's here but would love a follow-on conversation w/someone
more familiar with the cas / Paxos codebase as to whether leaving it unit-free
is adding value on balance.
> Bug fix for 'wait' time to be in nanoseconds for consistency instead of
> microseconds
>
>
> Key: CASSANDRA-18086
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18086
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Marianne Lyne Manaog
>Assignee: Marianne Lyne Manaog
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While working on benchmarking Paxos improvements in OSS Cassandra,
> [~benedict] was asked to review the work and thus found that the wait time
> was input in microseconds but then output incorrectly in the
> ContentionStrategy.java file, i.e., by summing up a wait time in nanoseconds
> with another wait time in microseconds (two different units used mistakenly).
> So, Benedict suggested the fix whereby the output wait time was then enforced
> to be consistently in nanoseconds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default cas
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-12525: -- Reviewers: Stefan Miklosovic, Stefan Miklosovic Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic) Status: Review In Progress (was: Patch Available) > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Low > Time Spent: 2h 40m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (db5df60a -> 496e306b)
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 db5df60a generate docs for 6f603a2c new 496e306b generate docs for 6f603a2c 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 (db5df60a) \ N -- N -- N refs/heads/asf-staging (496e306b) 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: .../4.2/cassandra/tools/nodetool/getsstables.html | 7 ++- .../cassandra/tools/nodetool/getsstables.html | 7 ++- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139 bytes 4 files changed, 13 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18086) Bug fix for 'wait' time to be in nanoseconds for consistency instead of microseconds
[ https://issues.apache.org/jira/browse/CASSANDRA-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-18086: -- Reviewers: Ariel Weisberg, Blake Eggleston, Josh McKenzie (was: Ariel Weisberg, Benedict Elliott Smith) > Bug fix for 'wait' time to be in nanoseconds for consistency instead of > microseconds > > > Key: CASSANDRA-18086 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18086 > Project: Cassandra > Issue Type: Bug > Components: Feature/Lightweight Transactions >Reporter: Marianne Lyne Manaog >Assignee: Marianne Lyne Manaog >Priority: Normal > Fix For: 4.1.x, 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > While working on benchmarking Paxos improvements in OSS Cassandra, > [~benedict] was asked to review the work and thus found that the wait time > was input in microseconds but then output incorrectly in the > ContentionStrategy.java file, i.e., by summing up a wait time in nanoseconds > with another wait time in microseconds (two different units used mistakenly). > So, Benedict suggested the fix whereby the output wait time was then enforced > to be consistently in nanoseconds. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default c
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643549#comment-17643549 ] German Eichberger commented on CASSANDRA-12525: --- I am sorry for all the mistakes. This is my first patch so still learning the process... > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Low > Time Spent: 2h 40m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default cas
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] German Eichberger updated CASSANDRA-12525: -- Test and Documentation Plan: https://github.com/apache/cassandra/pull/2033#discussion_r1038807028 Status: Patch Available (was: Open) > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Low > Time Spent: 2h 40m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever reassigned CASSANDRA-17869:
--
Assignee: Michael Semb Wever
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643541#comment-17643541
]
Michael Semb Wever commented on CASSANDRA-17869:
bq. versioning the build scripts separately and having a single repo that has
multi-version support makes some logical sense that we'd lose if we put it
in-tree.
This is a current pain-point. Different JDK versions, different test types,
etc, is overhead in complexity that has no value that I'm aware of? There's
also a lot of {{`git clone --depth 1 --single-branch …cassandra-builds }} we
could be avoiding…
The idea is per-branch scripts. Put in the {{.build/}} folder.
bq. I think that is what we also do with the python upgrade tests?
Both upgrade test types already have in-place definitions of what versions can
be, and are to be, upgraded from and to. So it makes sense to not enforce the
JDK used at the test level, but via the build.xml (so we actually verify that
there's a JDK in common that all upgrade paths can operate on).
{quote}
bq. Can we remove JAVA8_HOME and JAVA11_HOME from dtests script and image?
What is your idea?
{quote}
Well, in ci-cassandra.a.o there are no jdk11 python dtests run… (AFAIK?)
But… it's unclear to what the purpose of the JAVA8_HOME and JAVA11_HOME
variables are for? Given the jdk used for the tests comes down the JAVA_HOME
variable anyway, and building bc JAVA11_HOME doesn't happen anymore…
bq. So you won't have both applicable in one version. Or did I misunderstand
the question?
Why have anything in trunk ? (There was a discussion about it recently, but i
can't find it…)
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Priority: Normal
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643538#comment-17643538
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
bq. Honestly, people will probably learn about it when they have to, i.e. in a
hypothetical future where folks are using these scripts to run on either ASF CI
or a clone of it on private cloud.
bq. Same thing w/the circle config; people learn things when they need to but
are content to have them be black-box if they satisfy most of their needs.
Totally agree with you here. The suggestion about docs and session was only to
satisfy the concern that people do not know of those when they are in a
separate repo.
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Priority: Normal
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643523#comment-17643523
]
Josh McKenzie commented on CASSANDRA-17869:
---
bq. If we want to challenge and educate more people about the cassandra-builds
repo - docs and some nice session should be enough refreshment in my opinion.
Honestly, people will probably learn about it when they have to, i.e. in a
hypothetical future where folks are using these scripts to run on either ASF CI
or a clone of it on private cloud.
Same thing w/the circle config; people learn things when they need to but are
content to have them be black-box if they satisfy most of their needs.
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Priority: Normal
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643520#comment-17643520
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
bq. Having them separate has some real costs in terms of visibility and folks
on the project being familiar with it.
In my all honesty, I disagree considering how we have CircleCI config in-tree,
docs etc and:
- people still do not get involved mostly because they do not have the time
- I feel it is more prone to bugs if we have it in a few versions.
bq. Would the idea be to have build scripts that are targeted per-branch rather
than all the scripts on trunk supporting all previous supported branches?
I understood it being per version.
If we want to challenge and educate more people about the cassandra-builds repo
- docs and some nice session should be enough refreshment in my opinion.
bq. For the jvm-dtest-upgrade I presume we would then only support the default
(implied that's the JDK that overlaps with the previous major).
I think that is what we also do with the python upgrade tests?
bq. This is a starting working point:
https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/17869
[~mck], so just to confirm - this is one that covers trunk j11 and j17, right?
This one we can use for preliminary testing with arm, as we talked last week,
right? And thanks for pushing it!
bq. Can we remove JAVA8_HOME and JAVA11_HOME from dtests script and image?
What is your idea?
bq. CASSANDRA_USE_JDK17
Isn't this a substitution of CASSANDRA_USE_JDK11 from previous versions for the
next 5.0 one?
So you won't have both applicable in one version. Or did I misunderstand the
question?
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Priority: Normal
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643513#comment-17643513
]
Josh McKenzie commented on CASSANDRA-17869:
---
bq. i'm wondering if all this would be simpler if we brought these* scripts
in-tree
I've been asking myself this same question. Having them separate has some real
costs in terms of visibility and folks on the project being familiar with it,
but versioning the build scripts separately and having a single repo that has
multi-version support makes some logical sense that we'd lose if we put it
in-tree.
Would the idea be to have build scripts that are targeted per-branch rather
than all the scripts on trunk supporting all previous supported branches? Or
the latter?
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Priority: Normal
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18086) Bug fix for 'wait' time to be in nanoseconds for consistency instead of microseconds
[ https://issues.apache.org/jira/browse/CASSANDRA-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-18086: --- Test and Documentation Plan: Add unit test to `ContentionStrategyTest.java` to check that the calculated wait is as expected. > Bug fix for 'wait' time to be in nanoseconds for consistency instead of > microseconds > > > Key: CASSANDRA-18086 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18086 > Project: Cassandra > Issue Type: Bug > Components: Feature/Lightweight Transactions >Reporter: Marianne Lyne Manaog >Assignee: Marianne Lyne Manaog >Priority: Normal > Fix For: 4.1.x, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > While working on benchmarking Paxos improvements in OSS Cassandra, > [~benedict] was asked to review the work and thus found that the wait time > was input in microseconds but then output incorrectly in the > ContentionStrategy.java file, i.e., by summing up a wait time in nanoseconds > with another wait time in microseconds (two different units used mistakenly). > So, Benedict suggested the fix whereby the output wait time was then enforced > to be consistently in nanoseconds. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18086) Bug fix for 'wait' time to be in nanoseconds for consistency instead of microseconds
[ https://issues.apache.org/jira/browse/CASSANDRA-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-18086: --- Bug Category: Parent values: Degradation(12984)Level 1 values: Performance Bug/Regression(12997) Complexity: Normal Component/s: Feature/Lightweight Transactions Discovered By: Adhoc Test Severity: Normal Status: Open (was: Triage Needed) > Bug fix for 'wait' time to be in nanoseconds for consistency instead of > microseconds > > > Key: CASSANDRA-18086 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18086 > Project: Cassandra > Issue Type: Bug > Components: Feature/Lightweight Transactions >Reporter: Marianne Lyne Manaog >Assignee: Marianne Lyne Manaog >Priority: Normal > Fix For: 4.1.x, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > While working on benchmarking Paxos improvements in OSS Cassandra, > [~benedict] was asked to review the work and thus found that the wait time > was input in microseconds but then output incorrectly in the > ContentionStrategy.java file, i.e., by summing up a wait time in nanoseconds > with another wait time in microseconds (two different units used mistakenly). > So, Benedict suggested the fix whereby the output wait time was then enforced > to be consistently in nanoseconds. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18086) Bug fix for 'wait' time to be in nanoseconds for consistency instead of microseconds
[ https://issues.apache.org/jira/browse/CASSANDRA-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-18086: --- Reviewers: Ariel Weisberg, Benedict Elliott Smith Source Control Link: https://github.com/apache/cassandra/pull/2038 > Bug fix for 'wait' time to be in nanoseconds for consistency instead of > microseconds > > > Key: CASSANDRA-18086 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18086 > Project: Cassandra > Issue Type: Bug >Reporter: Marianne Lyne Manaog >Assignee: Marianne Lyne Manaog >Priority: Normal > Fix For: 4.1.x, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > While working on benchmarking Paxos improvements in OSS Cassandra, > [~benedict] was asked to review the work and thus found that the wait time > was input in microseconds but then output incorrectly in the > ContentionStrategy.java file, i.e., by summing up a wait time in nanoseconds > with another wait time in microseconds (two different units used mistakenly). > So, Benedict suggested the fix whereby the output wait time was then enforced > to be consistently in nanoseconds. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14930) decommission may cause timeout because messaging backlog is cleared
[
https://issues.apache.org/jira/browse/CASSANDRA-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643469#comment-17643469
]
Stefan Miklosovic commented on CASSANDRA-14930:
---
hi [~jasonstack], do you plan to address points [~azotcsit] has? If you are not
interested in this ticket anymore I ll gladly take over, I just do not want to
hijack your ticket so I am asking first.
> decommission may cause timeout because messaging backlog is cleared
>
>
> Key: CASSANDRA-14930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14930
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Core
>Reporter: Zhao Yang
>Assignee: Zhao Yang
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> On a 3-node cluster with RF=2, decommissioning a node may cause quorum write
> timeout because messaging backlog to decommissioned node is cleared via
> {{Gossiper#removeEndpoint() -> OutboundTcpConnection#closeSocket()}}.
> (Timeout is less likely to happen with RF=3, because we can afford one less
> response)
> {code:java}
> What happened:
> 1. [WriteStage] before the leaving node is removed from tokenmetadata, the
> write endpoints are generated ( leaving endpoint is included )
> 2. [GossipStage] the leaving node is removed from tokenmetadata, no more
> future write handler will include leaving endpoints
> 3. [WriteStage] write handlers sends messages to messaging-service backlog
> 4. [GossipStage] messaging-service backlog is cleared, messages are not sent
> and connection closed
> 5. [WriteStage] write time out
> {code}
> |patch|
> |[3.0|https://github.com/jasonstack/cassandra/commits/decommission_timeout_3.0]|
> |[3.11|https://github.com/jasonstack/cassandra/commits/decommission_timeout_3.11]|
> We can avoid it by delaying to destroy messaging connection so that messages
> are sent and responded. This patch also avoids reopening already closed
> connection on {{MessagingService#convict()}}.
> New messaging framework rewrite in {{Trunk}} avoids the issues by not
> clearing messaging backlog.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18058) In-memory index and query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643463#comment-17643463 ] Andres de la Peña commented on CASSANDRA-18058: --- I think I have finished my first round of review. I have left a bunch of suggestions on the PR, most things are quite minor. > In-memory index and query path > -- > > Key: CASSANDRA-18058 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18058 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > An in-memory index using the in-memory trie structure introduced with > CASSANDRA-17240 along with a query path implementation to perform index > queries from the in-memory index. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17874) Only reload compaction strategies if disk boundaries change
[ https://issues.apache.org/jira/browse/CASSANDRA-17874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17874: -- Status: Review In Progress (was: Patch Available) > Only reload compaction strategies if disk boundaries change > --- > > Key: CASSANDRA-17874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17874 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > Fix For: 4.x > > > We currently reload compaction strategies every time ringVersion changes - we > should change this to only reload if the ring version change actually changes > the disk boundaries. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17985) Handle timeouts when shutting down MessagingService
[ https://issues.apache.org/jira/browse/CASSANDRA-17985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17985: -- Reviewers: Aleksey Yeschenko, Aleksey Yeschenko Aleksey Yeschenko, Aleksey Yeschenko (was: Aleksey Yeschenko) Status: Review In Progress (was: Patch Available) > Handle timeouts when shutting down MessagingService > --- > > Key: CASSANDRA-17985 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17985 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.1.x, 4.x > > > Sometimes when shutting down messaging service during decommission we get a > timeout exception, which leaves StorageService.operationMode in "LEAVING" > instead of "DECOMMISSIONED" > We should catch the exception, improve logging and increase the timeout -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18083) snakeyaml-1.26.jar: CVE-2022-41854
[ https://issues.apache.org/jira/browse/CASSANDRA-18083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18083: - Fix Version/s: 3.0.29 3.11.15 4.1.1 4.2 (was: 3.0.x) (was: 4.x) (was: 3.11.x) (was: 4.0.x) (was: 4.1.x) Since Version: NA Source Control Link: https://github.com/apache/cassandra/commit/92019df4d8540b384d7fb8655f7c02293f7f7ec1 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thanks for the review! > snakeyaml-1.26.jar: CVE-2022-41854 > -- > > Key: CASSANDRA-18083 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18083 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.29, 3.11.15, 4.1.1, 4.2 > > > https://nvd.nist.gov/vuln/detail/CVE-2022-41854 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (279f284da5 -> 33c60d8daf)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 279f284da5 Add option to print level with getsstables output new 92019df4d8 Suppress CVE-2022-41854 and similar new b7762e2aa2 Merge branch 'cassandra-3.0' into cassandra-3.11 new c2bbee2020 Merge branch 'cassandra-3.11' into cassandra-4.0 new 8889b27c9c Merge branch 'cassandra-4.0' into cassandra-4.1 new 33c60d8daf Merge branch 'cassandra-4.1' into trunk The 5 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 33c60d8daf7b25ffc80136289aaa4e6c9589b2c0 Merge: 279f284da5 8889b27c9c Author: Brandon Williams AuthorDate: Mon Dec 5 10:10:37 2022 -0600 Merge branch 'cassandra-4.1' into trunk .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) diff --cc CHANGES.txt index 98a63a6aa8,4b26f3a24e..79590ddad6 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -158,10 -87,6 +158,11 @@@ Merged from 3.11 * Creating of a keyspace on insufficient number of replicas should filter out gosspping-only members (CASSANDRA-17759) * Suppress CVE-2022-25857 and other snakeyaml CVEs (CASSANDRA-17907) Merged from 3.0: ++ * Suppress CVE-2022-41854 and similar (CASSANDRA-18083) + * Fix running Ant rat targets without git (CASSANDRA-17974) + * Harden JMX by resolving beanshooter issues (CASSANDRA-17921) + * Suppress CVE-2019-2684 (CASSANDRA-17965) + * Fix auto-completing "WITH" when creating a materialized view (CASSANDRA-17879) * Improve libjemalloc resolution in bin/cassandra (CASSANDRA-15767) * Fix restarting of services on gossipping-only member (CASSANDRA-17752) * Fix scrubber falling into infinite loop when the last partition is broken (CASSANDRA-17862) - 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 (cc4c8a3637 -> 8889b27c9c)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from cc4c8a3637 Merge branch 'cassandra-4.0' into cassandra-4.1 new 92019df4d8 Suppress CVE-2022-41854 and similar new b7762e2aa2 Merge branch 'cassandra-3.0' into cassandra-3.11 new c2bbee2020 Merge branch 'cassandra-3.11' into cassandra-4.0 new 8889b27c9c Merge branch 'cassandra-4.0' into cassandra-4.1 The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into cassandra-4.1
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 8889b27c9cfd7820a4a7d31b4fb63d2059b35ff9 Merge: cc4c8a3637 c2bbee2020 Author: Brandon Williams AuthorDate: Mon Dec 5 10:08:09 2022 -0600 Merge branch 'cassandra-4.0' into cassandra-4.1 .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) diff --cc CHANGES.txt index 967cbc0f22,fc0d9fb2c6..4b26f3a24e --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,21 -1,15 +1,22 @@@ -4.0.8 - * Harden parsing of boolean values in CQL in PropertyDefinitions (CASSANDRA-17878) - * Fix error message about type hints (CASSANDRA-17915) - * Fix possible race condition on repair snapshots (CASSANDRA-17955) - * Fix ASM bytecode version inconsistency (CASSANDRA-17873) +4.1.0 +Merged from 4.0: Merged from 3.11: - * Fix Splitter sometimes creating more splits than requested (CASSANDRA-18013) Merged from 3.0: + * Suppress CVE-2022-41854 and similar (CASSANDRA-18083) - * Fix running Ant rat targets without git (CASSANDRA-17974) -4.0.7 + +4.1-rc1 + * Avoid schema mismatch problems on memtable API misconfiguration (CASSANDRA-18040) + * Start Paxos auto repair in CassandraDaemon (CASSANDRA-18029) + * Restore streaming_keep_alive_period on the netty control streaming channel (CASSANDRA-17768) + * Move Schema.FORCE_LOAD_KEYSPACES and Schema.FORCE_LOAD_KEYSPACES_PROP to CassandraRelevantProps (CASSANDRA-17783) + * Add --resolve-ip option to nodetool gossipinfo (CASSANDRA-17934) + * Allow pre-V5 global limit on bytes in flight to revert to zero asynchronously in RateLimitingTest (CASSANDRA-17927) +Merged from 4.0: + * Harden parsing of boolean values in CQL in PropertyDefinitions (CASSANDRA-17878) + * Fix error message about type hints (CASSANDRA-17915) + * Fix possible race condition on repair snapshots (CASSANDRA-17955) + * Fix ASM bytecode version inconsistency (CASSANDRA-17873) * Remove empty cq4 files in log directory to not fail the startup of BinLog (CASSANDRA-17933) * Fix multiple BufferPool bugs (CASSANDRA-16681) * Fix StorageService.getNativeaddress handling of IPv6 addresses (CASSANDRA-17945) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit b7762e2aa276ecf9cad2dd26ee52fe2463ae52db Merge: 5a53c36515 92019df4d8 Author: Brandon Williams AuthorDate: Mon Dec 5 10:02:35 2022 -0600 Merge branch 'cassandra-3.0' into cassandra-3.11 .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) diff --cc .build/dependency-check-suppressions.xml index 6ed01952be,d9eea56920..d2ee33617d --- a/.build/dependency-check-suppressions.xml +++ b/.build/dependency-check-suppressions.xml @@@ -23,12 -23,13 +23,13 @@@ ^pkg:maven/org\.yaml/snakeyaml@.*$ -CVE-2022-38752 -CVE-2022-38751 -CVE-2022-38750 -CVE-2022-41854 +CVE-2017-18640 CVE-2022-25857 CVE-2022-38749 -CVE-2017-18640 +CVE-2022-38750 +CVE-2022-38751 +CVE-2022-38752 ++CVE-2022-41854 diff --cc CHANGES.txt index d435a17ab1,296d41f2b2..4223a5cd8d --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,19 -1,10 +1,20 @@@ -3.0.29 +3.11.15 + * Fix Splitter sometimes creating more splits than requested (CASSANDRA-18013) + +Merged from 3.0: + * Suppress CVE-2022-41854 and similar (CASSANDRA-18083) * Fix running Ant rat targets without git (CASSANDRA-17974) - * Fix intermittent failure in nodetool toppartitions (CASSANDRA-17254) -3.0.28 +3.11.14 + * Suppress CVE-2022-42003 and CVE-2022-42004 (CASSANDRA-17966) + * Make LongBufferPoolTest insensitive to timing (CASSANDRA-16681) + * Suppress CVE-2022-25857 and other snakeyaml CVEs (CASSANDRA-17907) + * Fix potential IndexOutOfBoundsException in PagingState in mixed mode clusters (CASSANDRA-17840) + * Document usage of closed token intervals in manual compaction (CASSANDRA-17575) + * Creating of a keyspace on insufficient number of replicas should filter out gosspping-only members (CASSANDRA-17759) + * Only use statically defined subcolumns when determining column definition for supercolumn cell (CASSANDRA-14113) +Merged from 3.0: * Harden JMX by resolving beanshooter issues (CASSANDRA-17921) * Suppress CVE-2019-2684 (CASSANDRA-17965) * Fix auto-completing "WITH" when creating a materialized view (CASSANDRA-17879) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: Suppress CVE-2022-41854 and similar
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-3.0 by this push: new 92019df4d8 Suppress CVE-2022-41854 and similar 92019df4d8 is described below commit 92019df4d8540b384d7fb8655f7c02293f7f7ec1 Author: Brandon Williams AuthorDate: Wed Nov 30 09:44:25 2022 -0600 Suppress CVE-2022-41854 and similar Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18083 --- .build/dependency-check-suppressions.xml | 6 ++ CHANGES.txt | 1 + 2 files changed, 7 insertions(+) diff --git a/.build/dependency-check-suppressions.xml b/.build/dependency-check-suppressions.xml index 11bc87a552..d9eea56920 100644 --- a/.build/dependency-check-suppressions.xml +++ b/.build/dependency-check-suppressions.xml @@ -23,6 +23,12 @@ ^pkg:maven/org\.yaml/snakeyaml@.*$ +CVE-2022-38752 +CVE-2022-38751 +CVE-2022-38750 +CVE-2022-41854 +CVE-2022-25857 +CVE-2022-38749 CVE-2017-18640 diff --git a/CHANGES.txt b/CHANGES.txt index 95931e0485..296d41f2b2 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0.29 + * Suppress CVE-2022-41854 and similar (CASSANDRA-18083) * Fix running Ant rat targets without git (CASSANDRA-17974) * Fix intermittent failure in nodetool toppartitions (CASSANDRA-17254) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit c2bbee2020af7b07eb478c10df21a8d081ec6a7e Merge: bba7ab3eca b7762e2aa2 Author: Brandon Williams AuthorDate: Mon Dec 5 10:06:17 2022 -0600 Merge branch 'cassandra-3.11' into cassandra-4.0 .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) diff --cc .build/dependency-check-suppressions.xml index c833fd252b,d2ee33617d..481d8d0b3f --- a/.build/dependency-check-suppressions.xml +++ b/.build/dependency-check-suppressions.xml @@@ -37,20 -29,16 +37,21 @@@ CVE-2022-38750 CVE-2022-38751 CVE-2022-38752 + CVE-2022-41854 - - + + +^pkg:maven/net\.openhft/chronicle\-wire@.*$ +cpe:/a:wire:wire + + + +^pkg:maven/com\.google\.guava/guava@.*$ +CVE-2020-8908 + + ^pkg:maven/io\.netty/netty\-all@.*$ -CVE-2019-16869 -CVE-2019-20444 -CVE-2019-20445 -CVE-2020-7238 CVE-2021-21290 CVE-2021-21295 CVE-2021-21409 diff --cc CHANGES.txt index de9e6f07cf,4223a5cd8d..fc0d9fb2c6 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,24 -1,12 +1,25 @@@ -3.11.15 +4.0.8 + * Harden parsing of boolean values in CQL in PropertyDefinitions (CASSANDRA-17878) + * Fix error message about type hints (CASSANDRA-17915) + * Fix possible race condition on repair snapshots (CASSANDRA-17955) + * Fix ASM bytecode version inconsistency (CASSANDRA-17873) +Merged from 3.11: * Fix Splitter sometimes creating more splits than requested (CASSANDRA-18013) - Merged from 3.0: + * Suppress CVE-2022-41854 and similar (CASSANDRA-18083) * Fix running Ant rat targets without git (CASSANDRA-17974) - -3.11.14 +4.0.7 + * Remove empty cq4 files in log directory to not fail the startup of BinLog (CASSANDRA-17933) + * Fix multiple BufferPool bugs (CASSANDRA-16681) + * Fix StorageService.getNativeaddress handling of IPv6 addresses (CASSANDRA-17945) + * Mitigate direct buffer memory OOM on replacements (CASSANDRA-17895) + * Fix repair failure on assertion if two peers have overlapping mismatching ranges (CASSANDRA-17900) + * Better handle null state in Gossip schema migration to avoid NPE (CASSANDRA-17864) + * HintedHandoffAddRemoveNodesTest now accounts for the fact that StorageMetrics.totalHints is not updated synchronously w/ writes (CASSANDRA-16679) + * Avoid getting hanging repairs due to repair message timeouts (CASSANDRA-17613) + * Prevent infinite loop in repair coordinator on FailSession (CASSANDRA-17834) +Merged from 3.11: * Suppress CVE-2022-42003 and CVE-2022-42004 (CASSANDRA-17966) * Make LongBufferPoolTest insensitive to timing (CASSANDRA-16681) * Suppress CVE-2022-25857 and other snakeyaml CVEs (CASSANDRA-17907) - 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 (bba7ab3eca -> c2bbee2020)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from bba7ab3eca Merge branch 'cassandra-3.11' into cassandra-4.0 new 92019df4d8 Suppress CVE-2022-41854 and similar new b7762e2aa2 Merge branch 'cassandra-3.0' into cassandra-3.11 new c2bbee2020 Merge branch 'cassandra-3.11' into cassandra-4.0 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) - 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 (5a53c36515 -> b7762e2aa2)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 5a53c36515 Merge branch 'cassandra-3.0' into cassandra-3.11 new 92019df4d8 Suppress CVE-2022-41854 and similar new b7762e2aa2 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .build/dependency-check-suppressions.xml | 1 + CHANGES.txt | 1 + 2 files changed, 2 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643422#comment-17643422
]
Michael Semb Wever edited comment on CASSANDRA-17869 at 12/5/22 3:51 PM:
-
This is a starting working point:
https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/17869
Looking at the diff, i'm wondering if all this would be simpler if we brought
these* scripts in-tree, and introduced variables in build.xml
{code}
{code}
Questions…
* For the {{jvm-dtest-upgrade}} I presume we would then only support the
default (implied that's the JDK that overlaps with the previous major).
* Can we remove JAVA8_HOME and JAVA11_HOME from dtests script and image?
* Can we avoid introducing any CASSANDRA_USE_JDK17 ?
was (Author: michaelsembwever):
This is a starting working point:
https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/17869
Looking at the diff, i'm wondering if all this would be simpler if we brought
these* scripts in-tree, and introduced variables in build.xml
{code}
{code}
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Priority: Normal
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643422#comment-17643422
]
Michael Semb Wever commented on CASSANDRA-17869:
This is a starting working point:
https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/17869
Looking at the diff, i'm wondering if all this would be simpler if we brought
these* scripts in-tree, and introduced variables in build.xml
{code}
{code}
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Priority: Normal
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18093) `generatetokens` uses the wrong allocation strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643413#comment-17643413
]
Branimir Lambov edited comment on CASSANDRA-18093 at 12/5/22 3:35 PM:
--
This is an example of the allocation {{generatetokens}} is currently
constructing for the second nodes in each rack:
{code:java}
Replicated node load in rack=0 after allocating node 3: max 1.33 min 0.56
stddev 0.0370.
Replicated node load in rack=1 after allocating node 4: max 1.67 min 0.70
stddev 0.0288.
Replicated node load in rack=2 after allocating node 5: max 1.16 min 0.84
stddev 0.0064.
{code}
and this is what it should be
{code:java}
Replicated node load in rack=0 after allocating node 3: max 1.06 min 0.94
stddev 0.0052.
Replicated node load in rack=1 after allocating node 4: max 1.06 min 0.94
stddev 0.0052.
Replicated node load in rack=2 after allocating node 5: max 1.06 min 0.94
stddev 0.0052.
{code}
The second result was generated after applying the following patch:
{code:java}
diff --git
a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
index 184332907b..84ccb95ff4 100644
--- a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
+++ b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
@@ -239,7 +239,8 @@ public class TokenAllocation
private StrategyAdapter getOrCreateStrategy(String dc, String rack)
{
-return strategyByRackDc.computeIfAbsent(dc, k -> new
HashMap<>()).computeIfAbsent(rack, k -> createStrategy(dc, rack));
+return createStrategy(dc, rack);
+//return strategyByRackDc.computeIfAbsent(dc, k -> new
HashMap<>()).computeIfAbsent(rack, k -> createStrategy(dc, rack));
}
private StrategyAdapter createStrategy(String dc, String rack)
@@ -281,8 +282,11 @@ public class TokenAllocation
// group by rack
return createStrategy(strategy.snitch, dc, null, replicas, true);
}
-else if (racks == 1)
+else if (racks == 1 ||
topology.getDatacenterEndpoints().get(dc).size() < replicas)
{
+// One rack, each node treated as separate.
+// This is also used as a fallback when number of nodes is lower
than the replication factor
+// (where allocation is done randomly).
return createStrategy(strategy.snitch, dc, null, replicas, false);
}
{code}
was (Author: blambov):
This is an example of the allocation {{generatetokens}} is currently
constructing for the second nodes in a rack:
{code}Replicated node load in rack=0 after allocating node 3: max 1.33 min 0.56
stddev 0.0370.
Replicated node load in rack=1 after allocating node 4: max 1.67 min 0.70
stddev 0.0288.
Replicated node load in rack=2 after allocating node 5: max 1.16 min 0.84
stddev 0.0064.
{code} and this is what it should be {code}Replicated node load in rack=0 after
allocating node 3: max 1.06 min 0.94 stddev 0.0052.
Replicated node load in rack=1 after allocating node 4: max 1.06 min 0.94
stddev 0.0052.
Replicated node load in rack=2 after allocating node 5: max 1.06 min 0.94
stddev 0.0052.
{code}
The second result was generated after applying this patch:{code}diff --git
a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
index 184332907b..84ccb95ff4 100644
--- a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
+++ b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
@@ -239,7 +239,8 @@ public class TokenAllocation
private StrategyAdapter getOrCreateStrategy(String dc, String rack)
{
-return strategyByRackDc.computeIfAbsent(dc, k -> new
HashMap<>()).computeIfAbsent(rack, k -> createStrategy(dc, rack));
+return createStrategy(dc, rack);
+//return strategyByRackDc.computeIfAbsent(dc, k -> new
HashMap<>()).computeIfAbsent(rack, k -> createStrategy(dc, rack));
}
private StrategyAdapter createStrategy(String dc, String rack)
@@ -281,8 +282,11 @@ public class TokenAllocation
// group by rack
return createStrategy(strategy.snitch, dc, null, replicas, true);
}
-else if (racks == 1)
+else if (racks == 1 ||
topology.getDatacenterEndpoints().get(dc).size() < replicas)
{
+// One rack, each node treated as separate.
+// This is also used as a fallback when number of nodes is lower
than the replication factor
+// (where allocation is done randomly).
return createStrategy(strategy.snitch, dc, null, replicas, false);
}
{code}
> `generatetokens` uses the wrong allocation strategy
> ---
>
>
[jira] [Commented] (CASSANDRA-18093) `generatetokens` uses the wrong allocation strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643413#comment-17643413
]
Branimir Lambov commented on CASSANDRA-18093:
-
This is an example of the allocation {{generatetokens}} is currently
constructing for the second nodes in a rack:
{code}Replicated node load in rack=0 after allocating node 3: max 1.33 min 0.56
stddev 0.0370.
Replicated node load in rack=1 after allocating node 4: max 1.67 min 0.70
stddev 0.0288.
Replicated node load in rack=2 after allocating node 5: max 1.16 min 0.84
stddev 0.0064.
{code} and this is what it should be {code}Replicated node load in rack=0 after
allocating node 3: max 1.06 min 0.94 stddev 0.0052.
Replicated node load in rack=1 after allocating node 4: max 1.06 min 0.94
stddev 0.0052.
Replicated node load in rack=2 after allocating node 5: max 1.06 min 0.94
stddev 0.0052.
{code}
The second result was generated after applying this patch:{code}diff --git
a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
index 184332907b..84ccb95ff4 100644
--- a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
+++ b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
@@ -239,7 +239,8 @@ public class TokenAllocation
private StrategyAdapter getOrCreateStrategy(String dc, String rack)
{
-return strategyByRackDc.computeIfAbsent(dc, k -> new
HashMap<>()).computeIfAbsent(rack, k -> createStrategy(dc, rack));
+return createStrategy(dc, rack);
+//return strategyByRackDc.computeIfAbsent(dc, k -> new
HashMap<>()).computeIfAbsent(rack, k -> createStrategy(dc, rack));
}
private StrategyAdapter createStrategy(String dc, String rack)
@@ -281,8 +282,11 @@ public class TokenAllocation
// group by rack
return createStrategy(strategy.snitch, dc, null, replicas, true);
}
-else if (racks == 1)
+else if (racks == 1 ||
topology.getDatacenterEndpoints().get(dc).size() < replicas)
{
+// One rack, each node treated as separate.
+// This is also used as a fallback when number of nodes is lower
than the replication factor
+// (where allocation is done randomly).
return createStrategy(strategy.snitch, dc, null, replicas, false);
}
{code}
> `generatetokens` uses the wrong allocation strategy
> ---
>
> Key: CASSANDRA-18093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18093
> Project: Cassandra
> Issue Type: Bug
>Reporter: Branimir Lambov
>Priority: Normal
>
> When the number of racks is the same as the replication factor, token
> allocation should use `NoReplicationTokenAllocator`. Because `generatetokens`
> caches the allocation strategy
> [here|https://github.com/apache/cassandra/commit/2346ed8241022882e77433e283ab8ce3004d12b0#diff-a93e5fa817f4b6d64484e0c28391b76e1760f51860de7f4f036470766ff5090cR225],
> it uses one that was created before all the racks are defined and does not
> switch to the correct one.
> This has the effect of constructing very poor allocations for the racks = RF
> case, especially for the first couple of nodes per rack.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18094) Add python 3.11 to CI
[ https://issues.apache.org/jira/browse/CASSANDRA-18094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-18094: Assignee: Brandon Williams > Add python 3.11 to CI > - > > Key: CASSANDRA-18094 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18094 > Project: Cassandra > Issue Type: Task >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > Python 3.11 has a small divergence that necessitates a SaferScanner for that > version and those after it in CASSANDRA-18088, similar to what 3.8 did and we > solved with CASSANDRA-15573. We should add 3.11 to our docker images so we > can test with it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18094) Add python 3.11 to CI
Brandon Williams created CASSANDRA-18094: Summary: Add python 3.11 to CI Key: CASSANDRA-18094 URL: https://issues.apache.org/jira/browse/CASSANDRA-18094 Project: Cassandra Issue Type: Task Reporter: Brandon Williams Python 3.11 has a small divergence that necessitates a SaferScanner for that version and those after it in CASSANDRA-18088, similar to what 3.8 did and we solved with CASSANDRA-15573. We should add 3.11 to our docker images so we can test with it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18093) `generatetokens` uses the wrong allocation strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Branimir Lambov updated CASSANDRA-18093: Description: When the number of racks is the same as the replication factor, token allocation should use `NoReplicationTokenAllocator`. Because `generatetokens` caches the allocation strategy [here|https://github.com/apache/cassandra/commit/2346ed8241022882e77433e283ab8ce3004d12b0#diff-a93e5fa817f4b6d64484e0c28391b76e1760f51860de7f4f036470766ff5090cR225], it uses one that was created before all the racks are defined and does not switch to the correct one. This has the effect of constructing very poor allocations for the racks = RF case, especially for the first couple of nodes per rack. was: When the number of racks is the same as the replication factor, token allocation should use `NoReplicationTokenAllocator`. Because `generatetokens` caches the allocation strategy [here|https://github.com/apache/cassandra/commit/2346ed8241022882e77433e283ab8ce3004d12b0#diff-a93e5fa817f4b6d64484e0c28391b76e1760f51860de7f4f036470766ff5090cR225], it uses one that was created before all the racks are defined and does not switch to the correct one. This has the effect of constructing very poor allocations for the racks = RF case, especially for the first couple of nodes. > `generatetokens` uses the wrong allocation strategy > --- > > Key: CASSANDRA-18093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18093 > Project: Cassandra > Issue Type: Bug >Reporter: Branimir Lambov >Priority: Normal > > When the number of racks is the same as the replication factor, token > allocation should use `NoReplicationTokenAllocator`. Because `generatetokens` > caches the allocation strategy > [here|https://github.com/apache/cassandra/commit/2346ed8241022882e77433e283ab8ce3004d12b0#diff-a93e5fa817f4b6d64484e0c28391b76e1760f51860de7f4f036470766ff5090cR225], > it uses one that was created before all the racks are defined and does not > switch to the correct one. > This has the effect of constructing very poor allocations for the racks = RF > case, especially for the first couple of nodes per rack. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18093) `generatetokens` uses the wrong allocation strategy
Branimir Lambov created CASSANDRA-18093: --- Summary: `generatetokens` uses the wrong allocation strategy Key: CASSANDRA-18093 URL: https://issues.apache.org/jira/browse/CASSANDRA-18093 Project: Cassandra Issue Type: Bug Reporter: Branimir Lambov When the number of racks is the same as the replication factor, token allocation should use `NoReplicationTokenAllocator`. Because `generatetokens` caches the allocation strategy [here|https://github.com/apache/cassandra/commit/2346ed8241022882e77433e283ab8ce3004d12b0#diff-a93e5fa817f4b6d64484e0c28391b76e1760f51860de7f4f036470766ff5090cR225], it uses one that was created before all the racks are defined and does not switch to the correct one. This has the effect of constructing very poor allocations for the racks = RF case, especially for the first couple of nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18085) Add support for singletons on CQL collection functions
[
https://issues.apache.org/jira/browse/CASSANDRA-18085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643360#comment-17643360
]
Berenguer Blasi edited comment on CASSANDRA-18085 at 12/5/22 2:04 PM:
--
Yep I am following and waiting for the outcome of that discussion. I'll be
happy to help with the review if needed.
was (Author: bereng):
Yep I am following and waiting for the outcome of that discussion. I'll be
happy to help with the review.
> Add support for singletons on CQL collection functions
> --
>
> Key: CASSANDRA-18085
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18085
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18060 has added generic CQL functions to get the min, max, sum, avg
> and number of items in a collection. These functions can only be applied to
> collection values. The functions throw an {{InvalidRequestEception}} when
> applied to not-collection values.
> CASSANDRA-18078 has been pointed out that those functions could be applied
> also to not-collection values, considering that the not-collection argument
> can be considered a collection of a single element. For example:
> * collection_min(7) = collection_min([7]) = collection_min(\{7}) = 7
> * collection_max(7) = collection_max([7]) = collection_max(\{7}) = 7
> * collection_sum(7) = collection_sum([7]) = collection_sum(\{7}) = 7
> * collection_avg(7) = collection_avg([7]) = collection_avg(\{7}) = 7
> * collection_count(7) = collection_count([7]) = collection_count(\{7}) = 1
> This would be particularly useful when used in combination with functions
> such as {{writetime}} and {{{}ttl{}}}. Those functions can return either
> single values or collections of values depending on whether the column passed
> as argument is multicell. Thus, users interested on getting the
> min/max/sum/avg of the writetimes/ttls of a column need to consider the type
> of the column when choosing what functions they should use. With the proposed
> change they could just use, for example,
> {{collection_max(writetime(column))}} regardless of the column type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18085) Add support for singletons on CQL collection functions
[
https://issues.apache.org/jira/browse/CASSANDRA-18085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643360#comment-17643360
]
Berenguer Blasi commented on CASSANDRA-18085:
-
Yep I am following and waiting for the outcome of that discussion. I'll be
happy to help with the review.
> Add support for singletons on CQL collection functions
> --
>
> Key: CASSANDRA-18085
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18085
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18060 has added generic CQL functions to get the min, max, sum, avg
> and number of items in a collection. These functions can only be applied to
> collection values. The functions throw an {{InvalidRequestEception}} when
> applied to not-collection values.
> CASSANDRA-18078 has been pointed out that those functions could be applied
> also to not-collection values, considering that the not-collection argument
> can be considered a collection of a single element. For example:
> * collection_min(7) = collection_min([7]) = collection_min(\{7}) = 7
> * collection_max(7) = collection_max([7]) = collection_max(\{7}) = 7
> * collection_sum(7) = collection_sum([7]) = collection_sum(\{7}) = 7
> * collection_avg(7) = collection_avg([7]) = collection_avg(\{7}) = 7
> * collection_count(7) = collection_count([7]) = collection_count(\{7}) = 1
> This would be particularly useful when used in combination with functions
> such as {{writetime}} and {{{}ttl{}}}. Those functions can return either
> single values or collections of values depending on whether the column passed
> as argument is multicell. Thus, users interested on getting the
> min/max/sum/avg of the writetimes/ttls of a column need to consider the type
> of the column when choosing what functions they should use. With the proposed
> change they could just use, for example,
> {{collection_max(writetime(column))}} regardless of the column type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18092) Allow DB role names to prefix with a number
[
https://issues.apache.org/jira/browse/CASSANDRA-18092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18092:
-
Fix Version/s: 4.x
> Allow DB role names to prefix with a number
> ---
>
> Key: CASSANDRA-18092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18092
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
>Reporter: Johnny Miller
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> {{*Works -* CREATE ROLE IF NOT EXISTS test WITH PASSWORD='somepassword' AND
> LOGIN=true;}}
>
> {{*Works* - CREATE ROLE IF NOT EXISTS test123 WITH PASSWORD='somepassword'
> AND LOGIN=true;}}
>
> {{*Breaks* - CREATE ROLE IF NOT EXISTS 123test WITH PASSWORD='somepassword'
> AND LOGIN=true;}}
> {color:#de350b}{{SyntaxException: line 1:26 no viable alternative at input
> '123' (CREATE ROLE IF NOT EXISTS [123]...)}}{color}}}{}}}
>
> It would be helpful and more consistent to be able to prefix roles with a
> numeric value instead of only being able to do this as a suffix.
> Env Details are:
> [cqlsh 6.0.0 | Cassandra 4.0.3 | CQL spec 3.4.5 | Native protocol v5]
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18092) Allow DB role names to prefix with a number
[
https://issues.apache.org/jira/browse/CASSANDRA-18092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18092:
-
Change Category: Operability
Complexity: Normal
Component/s: Feature/Authorization
Fix Version/s: 4.0.x
4.1.x
Status: Open (was: Triage Needed)
> Allow DB role names to prefix with a number
> ---
>
> Key: CASSANDRA-18092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18092
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
>Reporter: Johnny Miller
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> {{*Works -* CREATE ROLE IF NOT EXISTS test WITH PASSWORD='somepassword' AND
> LOGIN=true;}}
>
> {{*Works* - CREATE ROLE IF NOT EXISTS test123 WITH PASSWORD='somepassword'
> AND LOGIN=true;}}
>
> {{*Breaks* - CREATE ROLE IF NOT EXISTS 123test WITH PASSWORD='somepassword'
> AND LOGIN=true;}}
> {color:#de350b}{{SyntaxException: line 1:26 no viable alternative at input
> '123' (CREATE ROLE IF NOT EXISTS [123]...)}}{color}}}{}}}
>
> It would be helpful and more consistent to be able to prefix roles with a
> numeric value instead of only being able to do this as a suffix.
> Env Details are:
> [cqlsh 6.0.0 | Cassandra 4.0.3 | CQL spec 3.4.5 | Native protocol v5]
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18092) Allow DB role names to prefix with a number
[
https://issues.apache.org/jira/browse/CASSANDRA-18092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johnny Miller updated CASSANDRA-18092:
--
Description:
{{*Works -* CREATE ROLE IF NOT EXISTS test WITH PASSWORD='somepassword' AND
LOGIN=true;}}
{{*Works* - CREATE ROLE IF NOT EXISTS test123 WITH PASSWORD='somepassword' AND
LOGIN=true;}}
{{*Breaks* - CREATE ROLE IF NOT EXISTS 123test WITH PASSWORD='somepassword' AND
LOGIN=true;}}
{color:#de350b}{{SyntaxException: line 1:26 no viable alternative at input
'123' (CREATE ROLE IF NOT EXISTS [123]...)}}{color}}}{}}}
It would be helpful and more consistent to be able to prefix roles with a
numeric value instead of only being able to do this as a suffix.
Env Details are:
[cqlsh 6.0.0 | Cassandra 4.0.3 | CQL spec 3.4.5 | Native protocol v5]
was:
{{*Works -* CREATE ROLE IF NOT EXISTS test WITH PASSWORD='somepassword' AND
LOGIN=true;}}
{{*Works* - CREATE ROLE IF NOT EXISTS test123 WITH PASSWORD='somepassword' AND
LOGIN=true;}}
{{*Breaks* - CREATE ROLE IF NOT EXISTS 123test WITH PASSWORD='somepassword' AND
LOGIN=true;}}
{color:#de350b}{{SyntaxException: line 1:26 no viable alternative at input
'123' (CREATE ROLE IF NOT EXISTS [123]...)}}{color}{{{}{}}}
It would be helpful and more consistent to be able to prefix roles with a
numeric value instead of only being able to do this as a suffix.
> Allow DB role names to prefix with a number
> ---
>
> Key: CASSANDRA-18092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18092
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Johnny Miller
>Priority: Normal
>
> {{*Works -* CREATE ROLE IF NOT EXISTS test WITH PASSWORD='somepassword' AND
> LOGIN=true;}}
>
> {{*Works* - CREATE ROLE IF NOT EXISTS test123 WITH PASSWORD='somepassword'
> AND LOGIN=true;}}
>
> {{*Breaks* - CREATE ROLE IF NOT EXISTS 123test WITH PASSWORD='somepassword'
> AND LOGIN=true;}}
> {color:#de350b}{{SyntaxException: line 1:26 no viable alternative at input
> '123' (CREATE ROLE IF NOT EXISTS [123]...)}}{color}}}{}}}
>
> It would be helpful and more consistent to be able to prefix roles with a
> numeric value instead of only being able to do this as a suffix.
> Env Details are:
> [cqlsh 6.0.0 | Cassandra 4.0.3 | CQL spec 3.4.5 | Native protocol v5]
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18092) Allow DB role names to prefix with a number
Johnny Miller created CASSANDRA-18092:
-
Summary: Allow DB role names to prefix with a number
Key: CASSANDRA-18092
URL: https://issues.apache.org/jira/browse/CASSANDRA-18092
Project: Cassandra
Issue Type: Improvement
Reporter: Johnny Miller
{{*Works -* CREATE ROLE IF NOT EXISTS test WITH PASSWORD='somepassword' AND
LOGIN=true;}}
{{*Works* - CREATE ROLE IF NOT EXISTS test123 WITH PASSWORD='somepassword' AND
LOGIN=true;}}
{{*Breaks* - CREATE ROLE IF NOT EXISTS 123test WITH PASSWORD='somepassword' AND
LOGIN=true;}}
{color:#de350b}{{SyntaxException: line 1:26 no viable alternative at input
'123' (CREATE ROLE IF NOT EXISTS [123]...)}}{color}{{{}{}}}
It would be helpful and more consistent to be able to prefix roles with a
numeric value instead of only being able to do this as a suffix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18086) Bug fix for 'wait' time to be in nanoseconds for consistency instead of microseconds
[ https://issues.apache.org/jira/browse/CASSANDRA-18086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18086: --- Fix Version/s: 4.1.x 4.x > Bug fix for 'wait' time to be in nanoseconds for consistency instead of > microseconds > > > Key: CASSANDRA-18086 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18086 > Project: Cassandra > Issue Type: Bug >Reporter: Marianne Lyne Manaog >Assignee: Marianne Lyne Manaog >Priority: Normal > Fix For: 4.1.x, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > While working on benchmarking Paxos improvements in OSS Cassandra, > [~benedict] was asked to review the work and thus found that the wait time > was input in microseconds but then output incorrectly in the > ContentionStrategy.java file, i.e., by summing up a wait time in nanoseconds > with another wait time in microseconds (two different units used mistakenly). > So, Benedict suggested the fix whereby the output wait time was then enforced > to be consistently in nanoseconds. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18085) Add support for singletons on CQL collection functions
[
https://issues.apache.org/jira/browse/CASSANDRA-18085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643317#comment-17643317
]
Andres de la Peña commented on CASSANDRA-18085:
---
Thanks for the review. I have tried to address the nits on the PR.
However I'm holding it a bit due to the after-review discussion on
CASSANDRA-18060, where [~benedict] mentions the possibility of using the same
{{{}max{}}}/{{{}min{}}}/{{{}sum{}}}/{{{}avg{}}} names for across-row aggregates
and collection functions, depending on the column type. We also mentioned that
option on CASSANDRA-17811 description, but we soon discarded it during the
review.
That would clash with what we are proposing here, since there would and
ambiguity when those functions are applied to single elements. That approach
would base the function selection on the column type, so users requesting the
min/max writetime/ttl of a column would require to know the type of the column
to decide whether they use the collection function or not. Failing to do so
would produce an unexpected collection or trigger an unexpected row
aggregation. I personally think that using separate {{collection_*}} function
names supporting singleton elements makes things clearer.
CC [~bereng]
> Add support for singletons on CQL collection functions
> --
>
> Key: CASSANDRA-18085
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18085
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18060 has added generic CQL functions to get the min, max, sum, avg
> and number of items in a collection. These functions can only be applied to
> collection values. The functions throw an {{InvalidRequestEception}} when
> applied to not-collection values.
> CASSANDRA-18078 has been pointed out that those functions could be applied
> also to not-collection values, considering that the not-collection argument
> can be considered a collection of a single element. For example:
> * collection_min(7) = collection_min([7]) = collection_min(\{7}) = 7
> * collection_max(7) = collection_max([7]) = collection_max(\{7}) = 7
> * collection_sum(7) = collection_sum([7]) = collection_sum(\{7}) = 7
> * collection_avg(7) = collection_avg([7]) = collection_avg(\{7}) = 7
> * collection_count(7) = collection_count([7]) = collection_count(\{7}) = 1
> This would be particularly useful when used in combination with functions
> such as {{writetime}} and {{{}ttl{}}}. Those functions can return either
> single values or collections of values depending on whether the column passed
> as argument is multicell. Thus, users interested on getting the
> min/max/sum/avg of the writetimes/ttls of a column need to consider the type
> of the column when choosing what functions they should use. With the proposed
> change they could just use, for example,
> {{collection_max(writetime(column))}} regardless of the column type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643262#comment-17643262
]
Andres de la Peña commented on CASSANDRA-18060:
---
Using {{size}} for collections to distinguish is similar to what MySQL does
with {{{}MAX{}}}/{{{}GREATEST{}}}, looking a kind of synonym to distinguish
between analogous functions applied to different data/element types. The
long-term problem with that strategy is that it's easy to run out of synonyms
on some cases, not to mention that {{size}} is a very generic name that could
be also be used for other things like calculating the size in bytes of any
column.
In contrast, using the {{collection_}} prefix avoids the need for looking for
synonyms, the function selection doesn't depend on the column type, and it
makes explicit the analogy between aggregate functions and their collection
counterparts.
There is also CASSANDRA-18085, which was proposed by [~yifanc] and [~frankgh].
That would make collection functions work of not-collection elements,
considering them as singleton collections, so for example:
* collection_min(7) = collection_min([7]) = collection_min(\{7}) = 7
* collection_max(7) = collection_max([7]) = collection_max(\{7}) = 7
That is particularly useful in combination with {{{}writetime{}}}/{{{}ttl{}}}
functions, that can return either a list, a set or a single number. The ability
to read single elements as collections would allow users to select, for
example:
{code}
collection_max(writetime(column))
{code}
without needing to know the type of the column. This however won't work if we
use the same {{max}} name for both aggregate and collection functions.
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggregation
> provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
> collections across rows. Here we only aggregate the items of a collection row
> per row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default c
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643180#comment-17643180 ] Stefan Miklosovic commented on CASSANDRA-12525: --- I put some comments in PR. [~xgerman42] could you please move this to "patch available" so I can review it formally etc? We should follow Jira workflow here. > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Low > Time Spent: 2h 20m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
