[cassandra-website] branch trunk updated: Releases 3.0.26, 3.11.12, 4.0.2
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new bb42048 Releases 3.0.26, 3.11.12, 4.0.2 bb42048 is described below commit bb420481054cbc035ddef5875fefebe60605f6d6 Author: mck AuthorDate: Fri Feb 11 09:42:47 2022 +0100 Releases 3.0.26, 3.11.12, 4.0.2 https://lists.apache.org/thread/3n9r6x3c2shq4g6p9ocrbs95w4v1jhmz https://lists.apache.org/thread/4bpk9nhg7dg1bw1cwp8opm5d65qo717s https://lists.apache.org/thread/7f4jsmvoynhsbg3ghohfzr3kr0pft16x --- site-content/source/modules/ROOT/pages/download.adoc | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/site-content/source/modules/ROOT/pages/download.adoc b/site-content/source/modules/ROOT/pages/download.adoc index 0bbc94c..5798bed 100644 --- a/site-content/source/modules/ROOT/pages/download.adoc +++ b/site-content/source/modules/ROOT/pages/download.adoc @@ -18,14 +18,14 @@ [discrete] Download the latest Apache Cassandra 4.0 GA release: [discrete] -== Released on 2021-09-07 +== Released on 2022-02-08 [discrete] == Maintained until 4.3.0 release (May-July 2024) [.btn.btn--alt] -https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz[4.0.1,window=blank] +https://www.apache.org/dyn/closer.lua/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz[4.0.2,window=blank] -(https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha512[sha512,window=blank]) +(https://downloads.apache.org/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz.sha512[sha512,window=blank]) -- [openblock, inline50 inline-top] @@ -35,14 +35,14 @@ https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin [discrete] Download the latest Apache Cassandra 3.11 release: [discrete] -== Released on 2021-07-28 +== Released on 2022-02-08 [discrete] == Maintained until 4.2.0 release (May-July 2023) [.btn.btn--alt] -https://www.apache.org/dyn/closer.lua/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz[3.11.11,window=blank] +https://www.apache.org/dyn/closer.lua/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz[3.11.12,window=blank] -(https://downloads.apache.org/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz.sha512[sha512,window=blank]) +(https://downloads.apache.org/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz.sha512[sha512,window=blank]) -- [openblock, inline50 inline-top] @@ -55,14 +55,14 @@ The following older Cassandra releases are still supported: [discrete] Apache Cassandra 3.0 [discrete] -== Released on 2021-02-01 +== Released on 2022-02-08 [discrete] == Maintained until 4.2.0 release (May-July 2023) [.btn.btn--alt] -https://www.apache.org/dyn/closer.lua/cassandra/3.0.25/apache-cassandra-3.0.25-bin.tar.gz[3.0.25,window=blank] +https://www.apache.org/dyn/closer.lua/cassandra/3.0.26/apache-cassandra-3.0.26-bin.tar.gz[3.0.26,window=blank] -(https://downloads.apache.org/cassandra/3.0.25/apache-cassandra-3.0.25-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/3.0.25/apache-cassandra-3.0.25-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/3.0.25/apache-cassandra-3.0.25-bin.tar.gz.sha512[sha512,window=blank]) +(https://downloads.apache.org/cassandra/3.0.26/apache-cassandra-3.0.26-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/3.0.26/apache-cassandra-3.0.26-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/3.0.26/apache-cassandra-3.0.26-bin.tar.gz.sha512[sha512,window=blank]) Older (unsupported) versions of Cassandra are archived https://archive.apache.org/dist/cassandra/[here,window=_blank]. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands,
[cassandra-website] branch asf-staging updated: ninja
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/asf-staging by this push: new 3119850 ninja 3119850 is described below commit 311985069da3e477f6d06c3d3ace4941afa9b38e Author: mck AuthorDate: Fri Feb 11 10:11:41 2022 +0100 ninja --- content/_/download.html | 66 - 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/content/_/download.html b/content/_/download.html index 35d9769..9705e5d 100644 --- a/content/_/download.html +++ b/content/_/download.html @@ -38,7 +38,7 @@ Get Started - + @@ -48,7 +48,7 @@ - + @@ -58,7 +58,7 @@ - + @@ -69,12 +69,12 @@ -Documentation +Documentation -Community +Community - + @@ -84,7 +84,7 @@ - + @@ -94,7 +94,7 @@ - + @@ -104,7 +104,7 @@ - + @@ -114,7 +114,7 @@ - + @@ -129,7 +129,7 @@ Learn - + @@ -139,7 +139,7 @@ - + @@ -149,7 +149,7 @@ - + @@ -160,7 +160,7 @@ -Download Now +Download Now @@ -183,13 +183,13 @@ Latest GA Version Download the latest Apache Cassandra 4.0 GA release: -Released on 2021-09-07 +Released on 2022-02-08 Maintained until 4.3.0 release (May-July 2024) -https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz"; target="blank">4.0.1 +https://www.apache.org/dyn/closer.lua/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz"; target="blank">4.0.2 -(https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.asc"; target="blank">pgp, https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha256"; target="blank">sha256 and https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha512"; target="blank">sha512) +(https://downloads.apache.org/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz.asc"; target="blank">pgp, https://downloads.apache.org/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz.sha256"; target="blank">sha256 and https://downloads.apache.org/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz.sha512"; target="blank">sha512) @@ -197,13 +197,13 @@ Previous Stable Version Download the latest Apache Cassandra 3.11 release: -Released on 2021-07-28 +Released on 2022-02-08 Maintained until 4.2.0 release (May-July 2023) -https://www.apache.org/dyn/closer.lua/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz"; target="blank">3.11.11 +https://www.apache.org/dyn/closer.lua/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz"; target="blank">3.11.12 -(https://downloads.apache.org/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz.asc"; target="blank">pgp, https://downloads.apache.org/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz.sha256"; target="blank">sha256 and https://downloads.apache.org/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz.sha512"; target="blank">sha512) +(https://downloads.apache.org/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz.asc"; target="blank">pgp, https://downloads.apache.org/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz.sha256"; target="blank">sha256 and https://downloads.apache.org/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz.sha512"; target="
[jira] [Commented] (CASSANDRA-17267) Snapshot true size is miscalculated
[
https://issues.apache.org/jira/browse/CASSANDRA-17267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490767#comment-17490767
]
Benjamin Lerer commented on CASSANDRA-17267:
Thanks [~paulo]. The patch looks good to me but the tests needs to be re-run.
> Snapshot true size is miscalculated
> ---
>
> Key: CASSANDRA-17267
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17267
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
>
> As far as I understand, the snapshot "size on disk" is the total size of the
> snapshot, while the "true size" is the (size_on_disk - size_of_live_sstables).
> I created a snapshot on a 3.11 node without traffic and I expected the "true
> size" to be 0KB since the original sstables were still present, but this
> didn't seem to be the case:
> {noformat}
> $ nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> test ks1 tbl1 4.86 KiB 5.69 KiB
> Total TrueDiskSpaceUsed: 4.86 KiB
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17267) Snapshot true size is miscalculated
[
https://issues.apache.org/jira/browse/CASSANDRA-17267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17267:
---
Reviewers: Benjamin Lerer
> Snapshot true size is miscalculated
> ---
>
> Key: CASSANDRA-17267
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17267
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
>
> As far as I understand, the snapshot "size on disk" is the total size of the
> snapshot, while the "true size" is the (size_on_disk - size_of_live_sstables).
> I created a snapshot on a 3.11 node without traffic and I expected the "true
> size" to be 0KB since the original sstables were still present, but this
> didn't seem to be the case:
> {noformat}
> $ nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> test ks1 tbl1 4.86 KiB 5.69 KiB
> Total TrueDiskSpaceUsed: 4.86 KiB
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated: ninja
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/asf-site by this push: new fec7fb2 ninja fec7fb2 is described below commit fec7fb288a8c7e3cf5e2510b29faa5c3ca749982 Author: mck AuthorDate: Fri Feb 11 10:11:41 2022 +0100 ninja --- content/_/download.html | 66 - 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/content/_/download.html b/content/_/download.html index 35d9769..9705e5d 100644 --- a/content/_/download.html +++ b/content/_/download.html @@ -38,7 +38,7 @@ Get Started - + @@ -48,7 +48,7 @@ - + @@ -58,7 +58,7 @@ - + @@ -69,12 +69,12 @@ -Documentation +Documentation -Community +Community - + @@ -84,7 +84,7 @@ - + @@ -94,7 +94,7 @@ - + @@ -104,7 +104,7 @@ - + @@ -114,7 +114,7 @@ - + @@ -129,7 +129,7 @@ Learn - + @@ -139,7 +139,7 @@ - + @@ -149,7 +149,7 @@ - + @@ -160,7 +160,7 @@ -Download Now +Download Now @@ -183,13 +183,13 @@ Latest GA Version Download the latest Apache Cassandra 4.0 GA release: -Released on 2021-09-07 +Released on 2022-02-08 Maintained until 4.3.0 release (May-July 2024) -https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz"; target="blank">4.0.1 +https://www.apache.org/dyn/closer.lua/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz"; target="blank">4.0.2 -(https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.asc"; target="blank">pgp, https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha256"; target="blank">sha256 and https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha512"; target="blank">sha512) +(https://downloads.apache.org/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz.asc"; target="blank">pgp, https://downloads.apache.org/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz.sha256"; target="blank">sha256 and https://downloads.apache.org/cassandra/4.0.2/apache-cassandra-4.0.2-bin.tar.gz.sha512"; target="blank">sha512) @@ -197,13 +197,13 @@ Previous Stable Version Download the latest Apache Cassandra 3.11 release: -Released on 2021-07-28 +Released on 2022-02-08 Maintained until 4.2.0 release (May-July 2023) -https://www.apache.org/dyn/closer.lua/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz"; target="blank">3.11.11 +https://www.apache.org/dyn/closer.lua/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz"; target="blank">3.11.12 -(https://downloads.apache.org/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz.asc"; target="blank">pgp, https://downloads.apache.org/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz.sha256"; target="blank">sha256 and https://downloads.apache.org/cassandra/3.11.11/apache-cassandra-3.11.11-bin.tar.gz.sha512"; target="blank">sha512) +(https://downloads.apache.org/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz.asc"; target="blank">pgp, https://downloads.apache.org/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz.sha256"; target="blank">sha256 and https://downloads.apache.org/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz.sha512"; target="blank"
[jira] [Updated] (CASSANDRA-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17352: Description: When running Apache Cassandra with the following configuration: enable_user_defined_functions: true enable_scripted_user_defined_functions: true enable_user_defined_functions_threads: false it is possible for an attacker to execute arbitrary code on the host. The attacker would need to have enough permissions to create user defined functions in the cluster to be able to exploit this. Note that this configuration is documented as unsafe, and will continue to be considered unsafe after this CVE. This issue is being tracked as CASSANDRA-17352 Mitigation: Set `enable_user_defined_functions_threads: true` (this is default) or 3.0 users should upgrade to 3.0.26 3.11 users should upgrade to 3.11.12 4.0 users should upgrade to 4.0.2 Credit: This issue was discovered by Omer Kaspi of the JFrog Security vulnerability research team. > CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs > - > > Key: CASSANDRA-17352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17352 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Priority: Normal > > When running Apache Cassandra with the following configuration: > enable_user_defined_functions: true > enable_scripted_user_defined_functions: true > enable_user_defined_functions_threads: false > it is possible for an attacker to execute arbitrary code on the host. The > attacker would need to have enough permissions to create user defined > functions in the cluster to be able to exploit this. Note that this > configuration is documented as unsafe, and will continue to be considered > unsafe after this CVE. > This issue is being tracked as CASSANDRA-17352 > Mitigation: > Set `enable_user_defined_functions_threads: true` (this is default) > or > 3.0 users should upgrade to 3.0.26 > 3.11 users should upgrade to 3.11.12 > 4.0 users should upgrade to 4.0.2 > Credit: > This issue was discovered by Omer Kaspi of the JFrog Security vulnerability > research team. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17352: Summary: CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs (was: TBD) > CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs > - > > Key: CASSANDRA-17352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17352 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17352: Bug Category: Parent values: Security(12985)Level 1 values: Remote Code Execution(13002) Complexity: Normal Component/s: Feature/UDF Discovered By: User Report Severity: Critical Assignee: Marcus Eriksson Status: Open (was: Triage Needed) > CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs > - > > Key: CASSANDRA-17352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17352 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDF >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > When running Apache Cassandra with the following configuration: > enable_user_defined_functions: true > enable_scripted_user_defined_functions: true > enable_user_defined_functions_threads: false > it is possible for an attacker to execute arbitrary code on the host. The > attacker would need to have enough permissions to create user defined > functions in the cluster to be able to exploit this. Note that this > configuration is documented as unsafe, and will continue to be considered > unsafe after this CVE. > This issue is being tracked as CASSANDRA-17352 > Mitigation: > Set `enable_user_defined_functions_threads: true` (this is default) > or > 3.0 users should upgrade to 3.0.26 > 3.11 users should upgrade to 3.11.12 > 4.0 users should upgrade to 4.0.2 > Credit: > This issue was discovered by Omer Kaspi of the JFrog Security vulnerability > research team. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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 (317f507 -> 0218d1f)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 317f507 Merge branch 'cassandra-3.0' into cassandra-3.11 new 1e015ed Increment version to 3.11.13 new 25828cb Increment version to 3.0.27 new 0218d1f Merge branch 'cassandra-3.0' into cassandra-3.11 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 3 +++ build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 10 insertions(+), 1 deletion(-) - 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: Increment version to 3.0.27
This is an automated email from the ASF dual-hosted git repository. mck 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 25828cb Increment version to 3.0.27 25828cb is described below commit 25828cb9b135d02fe462da3df81a30e2e6bd0536 Author: Mick Semb Wever AuthorDate: Fri Feb 11 11:03:51 2022 +0100 Increment version to 3.0.27 --- CHANGES.txt | 5 - build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 2b9cf2a..f0fefb2 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,7 @@ -3.0.26: +3.0.27 + + +3.0.26 * Fix conversion from megabits to bytes in streaming rate limiter (CASSANDRA-17243) * Upgrade logback to 1.2.9 (CASSANDRA-17204) * Avoid race in AbstractReplicationStrategy endpoint caching (CASSANDRA-16673) diff --git a/build.xml b/build.xml index 6dd09fe..a8fcaa6 100644 --- a/build.xml +++ b/build.xml @@ -24,7 +24,7 @@ - + https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/> diff --git a/debian/changelog b/debian/changelog index 6949bf4..91bb6f9 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (3.0.27) UNRELEASED; urgency=medium + + * New release + + -- Mick Semb Wever Mon, 07 Feb 2022 13:12:52 +0100 + cassandra (3.0.26) unstable; urgency=medium * New release - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 02/02: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 0218d1f6c8627227e996fd4b3fab64d237a685c5 Merge: 1e015ed 25828cb Author: Mick Semb Wever AuthorDate: Fri Feb 11 11:08:40 2022 +0100 Merge branch 'cassandra-3.0' into cassandra-3.11 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/02: Increment version to 4.0.3
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d0f4b42956c50e9f966e14c41bc175a5a7481a62 Author: Mick Semb Wever AuthorDate: Fri Feb 11 11:08:24 2022 +0100 Increment version to 4.0.3 --- CHANGES.txt | 3 +++ build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index ca9b6b3..de4876f 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,6 @@ +4.0.3 + + 4.0.2 * Full Java 11 support (CASSANDRA-16894) * Remove unused 'geomet' package from cqlsh path (CASSANDRA-17271) diff --git a/build.xml b/build.xml index b106199..9a5598f 100644 --- a/build.xml +++ b/build.xml @@ -24,7 +24,7 @@ - + https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/> diff --git a/debian/changelog b/debian/changelog index db2b2c5..51bcc33 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (4.0.3) UNRELEASED; urgency=medium + + * New release + + -- Mick Semb Wever Mon, 07 Feb 2022 14:42:07 +0100 + cassandra (4.0.2) unstable; urgency=medium * New release - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 02/02: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit f207460391f5a8f9faf90b784e5a665c37188bec Merge: d0f4b42 0218d1f Author: Mick Semb Wever AuthorDate: Fri Feb 11 11:09:22 2022 +0100 Merge branch 'cassandra-3.11' into cassandra-4.0 - 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 trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ab0a9fdd3f37e31bc335fcc075a4dec0bd721eed Merge: 4094e9c f207460 Author: Mick Semb Wever AuthorDate: Fri Feb 11 11:09:50 2022 +0100 Merge branch 'cassandra-4.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/02: Increment version to 3.11.13
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 1e015ed2a26a6c1c6a948eec842d7c8ea7d9917c Author: Mick Semb Wever AuthorDate: Fri Feb 11 11:06:21 2022 +0100 Increment version to 3.11.13 --- CHANGES.txt | 3 +++ build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index 579cea2..c166202 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,6 @@ +3.11.13 + + 3.11.12 * Upgrade snakeyaml to 1.26 in 3.11 (CASSANDRA=17028) * Add key validation to ssstablescrub (CASSANDRA-16969) diff --git a/build.xml b/build.xml index 9c847ff..60665e3 100644 --- a/build.xml +++ b/build.xml @@ -24,7 +24,7 @@ - + https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/> diff --git a/debian/changelog b/debian/changelog index afd3438..cfef5fd 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (3.11.13) UNRELEASED; urgency=medium + + * New release + + -- Mick Semb Wever Mon, 07 Feb 2022 13:55:35 +0100 + cassandra (3.11.12) unstable; urgency=medium * New release - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (4094e9c -> ab0a9fd)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 4094e9c ninja fix CHANGES.txt new d0f4b42 Increment version to 4.0.3 new 1e015ed Increment version to 3.11.13 new 25828cb Increment version to 3.0.27 new 0218d1f Merge branch 'cassandra-3.0' into cassandra-3.11 new f207460 Merge branch 'cassandra-3.11' into cassandra-4.0 new ab0a9fd Merge branch 'cassandra-4.0' into trunk The 6 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (f2816f5 -> f207460)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from f2816f5 Better isolate tests from each other in SSTableReaderTest new d0f4b42 Increment version to 4.0.3 new 1e015ed Increment version to 3.11.13 new 25828cb Increment version to 3.0.27 new 0218d1f Merge branch 'cassandra-3.0' into cassandra-3.11 new f207460 Merge branch 'cassandra-3.11' into cassandra-4.0 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: CHANGES.txt | 3 +++ build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 10 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490815#comment-17490815
]
Marcus Eriksson commented on CASSANDRA-17352:
-
It is possible for an attacker to create a scripted UDF which executes
arbitrary code on the server.
Attacker needs to have enough permissions to create user defined functions on
the server, and {{enable_user_defined_functions_threads}} must have been
changed from {{false}} to {{true}} by the operator
https://github.com/apache/cassandra/commit/5c9ba06dd31157cd224af2cec75521fefe2c9883
to continue running with {{enable_user_defined_functions_threads: false}}
setting {{allow_insecure_udfs: true}} is required
to continue accessing {{System.*}} classes, {{allow_extra_insecure_udfs: true}}
is required
> CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
> -
>
> Key: CASSANDRA-17352
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17352
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> When running Apache Cassandra with the following configuration:
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> enable_user_defined_functions_threads: false
> it is possible for an attacker to execute arbitrary code on the host. The
> attacker would need to have enough permissions to create user defined
> functions in the cluster to be able to exploit this. Note that this
> configuration is documented as unsafe, and will continue to be considered
> unsafe after this CVE.
> This issue is being tracked as CASSANDRA-17352
> Mitigation:
> Set `enable_user_defined_functions_threads: true` (this is default)
> or
> 3.0 users should upgrade to 3.0.26
> 3.11 users should upgrade to 3.11.12
> 4.0 users should upgrade to 4.0.2
> Credit:
> This issue was discovered by Omer Kaspi of the JFrog Security vulnerability
> research team.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17352: Test and Documentation Plan: cci run Status: Patch Available (was: Open) > CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs > - > > Key: CASSANDRA-17352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17352 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDF >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > When running Apache Cassandra with the following configuration: > enable_user_defined_functions: true > enable_scripted_user_defined_functions: true > enable_user_defined_functions_threads: false > it is possible for an attacker to execute arbitrary code on the host. The > attacker would need to have enough permissions to create user defined > functions in the cluster to be able to exploit this. Note that this > configuration is documented as unsafe, and will continue to be considered > unsafe after this CVE. > This issue is being tracked as CASSANDRA-17352 > Mitigation: > Set `enable_user_defined_functions_threads: true` (this is default) > or > 3.0 users should upgrade to 3.0.26 > 3.11 users should upgrade to 3.11.12 > 4.0 users should upgrade to 4.0.2 > Credit: > This issue was discovered by Omer Kaspi of the JFrog Security vulnerability > research team. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r52520 - in /release/cassandra: 3.0.25/ 3.11.11/ 4.0.1/
Author: mck Date: Fri Feb 11 11:25:11 2022 New Revision: 52520 Log: Releases 3.0.26, 3.11.12, 4.0.2 https://lists.apache.org/thread/3n9r6x3c2shq4g6p9ocrbs95w4v1jhmz https://lists.apache.org/thread/4bpk9nhg7dg1bw1cwp8opm5d65qo717s https://lists.apache.org/thread/7f4jsmvoynhsbg3ghohfzr3kr0pft16x Removed: release/cassandra/3.0.25/ release/cassandra/3.11.11/ release/cassandra/4.0.1/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product
[
https://issues.apache.org/jira/browse/CASSANDRA-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490859#comment-17490859
]
Andres de la Peña commented on CASSANDRA-17187:
---
Here is the patch:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1444]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/f532c245-0374-43ab-b991-c58fab0c135d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/57c48e3e-5fc0-4df1-82ae-c50592b79427]|
The patch is relatively simple but the patch is a bit noisy because we need to
pass the {{ClientState}} to {{PartitionKeySingleRestrictionSet}} and
\{{ClusteringColumnRestrictions{}, and this affects a bunch of classes in the
way.
There is also a minor refactor ofthe signatures of the utility methods
{{GuardrailTester#assertWarns}} and {{GuardrailTester#aasertFails}} that
(trivially) touches a bunch of tests. The reason for this refactor is that we
need to consider that a query can trigger multiple guardrails and thus produce
multiple warnings.
> Guardrail for SELECT IN terms and their cartesian product
> -
>
> Key: CASSANDRA-17187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: lhf
> Fix For: 4.x
>
>
> Add a guardrail to limit the number restrictions generated by the cartesian
> product of the {{IN}} restrictions of a {{SELECT}} query, for example:
> {code}
> # Guardrail to warn or abort when IN query creates a cartesian product with a
> # size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)"
> results in
> # cartesian product of 100.
> # The two thresholds default to -1 to disable.
> in_select_cartesian_product:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> As an example of why this guardrails is proposed, these queries bring a C*
> instance to its knees even before the query starts executing:
> {code}
> @Test
> public void testPartitionKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5
> int, pk6 int, pk7 int, pk8 int, pk9 int, " +
>"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
> execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> @Test
> public void testClusteringKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int,
> ck5 int, ck6 int, ck7 int, ck8 int, ck9 int, " +
> "PRIMARY KEY(pk, ck1, ck2, ck3, ck4, ck5, ck6, ck7, ck8, ck9))");
> execute("SELECT * FROM %s WHERE pk = 1 " +
> "AND ck1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> {code}
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on cartesian product in the
> guardrails section of cassandra.yaml.
> # Add a {{getInCartesianProduct}} method in {{GuardrailsConfig}} returning a
> {{Threshold.Config}} object
> # Implement that method in {{GuardrailsOptions}}, which is the default
> yaml-based implementation of {{GuardrailsConfig}}
> # Add a Threshold guardrail named {{inCartesianProduct}} in Guardrails, using
> the previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in {{GuardrailsMBean}}
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails#inCartesianProduct guard method. The
> {{MultiCBuilder}} look like good candidates for this.
> # Finally, add s
[jira] [Updated] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product
[
https://issues.apache.org/jira/browse/CASSANDRA-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17187:
--
Test and Documentation Plan: A new test class is included
Status: Patch Available (was: Open)
> Guardrail for SELECT IN terms and their cartesian product
> -
>
> Key: CASSANDRA-17187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: lhf
> Fix For: 4.x
>
>
> Add a guardrail to limit the number restrictions generated by the cartesian
> product of the {{IN}} restrictions of a {{SELECT}} query, for example:
> {code}
> # Guardrail to warn or abort when IN query creates a cartesian product with a
> # size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)"
> results in
> # cartesian product of 100.
> # The two thresholds default to -1 to disable.
> in_select_cartesian_product:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> As an example of why this guardrails is proposed, these queries bring a C*
> instance to its knees even before the query starts executing:
> {code}
> @Test
> public void testPartitionKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5
> int, pk6 int, pk7 int, pk8 int, pk9 int, " +
>"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
> execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> @Test
> public void testClusteringKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int,
> ck5 int, ck6 int, ck7 int, ck8 int, ck9 int, " +
> "PRIMARY KEY(pk, ck1, ck2, ck3, ck4, ck5, ck6, ck7, ck8, ck9))");
> execute("SELECT * FROM %s WHERE pk = 1 " +
> "AND ck1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> {code}
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on cartesian product in the
> guardrails section of cassandra.yaml.
> # Add a {{getInCartesianProduct}} method in {{GuardrailsConfig}} returning a
> {{Threshold.Config}} object
> # Implement that method in {{GuardrailsOptions}}, which is the default
> yaml-based implementation of {{GuardrailsConfig}}
> # Add a Threshold guardrail named {{inCartesianProduct}} in Guardrails, using
> the previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in {{GuardrailsMBean}}
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails#inCartesianProduct guard method. The
> {{MultiCBuilder}} look like good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend {{ThresholdTester}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product
[
https://issues.apache.org/jira/browse/CASSANDRA-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490859#comment-17490859
]
Andres de la Peña edited comment on CASSANDRA-17187 at 2/11/22, 11:26 AM:
--
Here is the patch:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1444]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/f532c245-0374-43ab-b991-c58fab0c135d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/57c48e3e-5fc0-4df1-82ae-c50592b79427]|
The guardrail is relatively simple but the patch is a bit noisy because we need
to pass the {{ClientState}} to {{PartitionKeySingleRestrictionSet}} and
\{{ClusteringColumnRestrictions{}, and this affects a bunch of classes in the
way.
There is also a minor refactor ofthe signatures of the utility methods
{{GuardrailTester#assertWarns}} and {{GuardrailTester#aasertFails}} that
(trivially) touches a bunch of tests. The reason for this refactor is that we
need to consider that a query can trigger multiple guardrails and thus produce
multiple warnings.
was (Author: adelapena):
Here is the patch:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1444]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/f532c245-0374-43ab-b991-c58fab0c135d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/57c48e3e-5fc0-4df1-82ae-c50592b79427]|
The patch is relatively simple but the patch is a bit noisy because we need to
pass the {{ClientState}} to {{PartitionKeySingleRestrictionSet}} and
\{{ClusteringColumnRestrictions{}, and this affects a bunch of classes in the
way.
There is also a minor refactor ofthe signatures of the utility methods
{{GuardrailTester#assertWarns}} and {{GuardrailTester#aasertFails}} that
(trivially) touches a bunch of tests. The reason for this refactor is that we
need to consider that a query can trigger multiple guardrails and thus produce
multiple warnings.
> Guardrail for SELECT IN terms and their cartesian product
> -
>
> Key: CASSANDRA-17187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: lhf
> Fix For: 4.x
>
>
> Add a guardrail to limit the number restrictions generated by the cartesian
> product of the {{IN}} restrictions of a {{SELECT}} query, for example:
> {code}
> # Guardrail to warn or abort when IN query creates a cartesian product with a
> # size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)"
> results in
> # cartesian product of 100.
> # The two thresholds default to -1 to disable.
> in_select_cartesian_product:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> As an example of why this guardrails is proposed, these queries bring a C*
> instance to its knees even before the query starts executing:
> {code}
> @Test
> public void testPartitionKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5
> int, pk6 int, pk7 int, pk8 int, pk9 int, " +
>"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
> execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> @Test
> public void testClusteringKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int,
> ck5 int, ck6 int, ck7 int, ck8 int, ck9 int, " +
> "PRIMARY KEY(pk, ck1, ck2, ck3, ck4, ck5, ck6, ck7, ck8, ck9))");
> execute("SELECT * FROM %s WHERE pk = 1 " +
> "AND ck1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
>
[jira] [Comment Edited] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product
[
https://issues.apache.org/jira/browse/CASSANDRA-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490859#comment-17490859
]
Andres de la Peña edited comment on CASSANDRA-17187 at 2/11/22, 11:27 AM:
--
Here is the patch:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1444]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/f532c245-0374-43ab-b991-c58fab0c135d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/57c48e3e-5fc0-4df1-82ae-c50592b79427]|
The guardrail is relatively simple but the patch is a bit noisy because we need
to pass the {{ClientState}} to {{PartitionKeySingleRestrictionSet}} and
{{{}ClusteringColumnRestrictions{}}}, and this affects a bunch of classes in
the way.
There is also a minor refactor ofthe signatures of the utility methods
{{GuardrailTester#assertWarns}} and {{GuardrailTester#aasertFails}} that
(trivially) touches a bunch of tests. The reason for this refactor is that we
need to consider that a query can trigger multiple guardrails and thus produce
multiple warnings.
was (Author: adelapena):
Here is the patch:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1444]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/f532c245-0374-43ab-b991-c58fab0c135d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/57c48e3e-5fc0-4df1-82ae-c50592b79427]|
The guardrail is relatively simple but the patch is a bit noisy because we need
to pass the {{ClientState}} to {{PartitionKeySingleRestrictionSet}} and
\{{ClusteringColumnRestrictions{}, and this affects a bunch of classes in the
way.
There is also a minor refactor ofthe signatures of the utility methods
{{GuardrailTester#assertWarns}} and {{GuardrailTester#aasertFails}} that
(trivially) touches a bunch of tests. The reason for this refactor is that we
need to consider that a query can trigger multiple guardrails and thus produce
multiple warnings.
> Guardrail for SELECT IN terms and their cartesian product
> -
>
> Key: CASSANDRA-17187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: lhf
> Fix For: 4.x
>
>
> Add a guardrail to limit the number restrictions generated by the cartesian
> product of the {{IN}} restrictions of a {{SELECT}} query, for example:
> {code}
> # Guardrail to warn or abort when IN query creates a cartesian product with a
> # size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)"
> results in
> # cartesian product of 100.
> # The two thresholds default to -1 to disable.
> in_select_cartesian_product:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> As an example of why this guardrails is proposed, these queries bring a C*
> instance to its knees even before the query starts executing:
> {code}
> @Test
> public void testPartitionKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5
> int, pk6 int, pk7 int, pk8 int, pk9 int, " +
>"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
> execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> @Test
> public void testClusteringKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int,
> ck5 int, ck6 int, ck7 int, ck8 int, ck9 int, " +
> "PRIMARY KEY(pk, ck1, ck2, ck3, ck4, ck5, ck6, ck7, ck8, ck9))");
> execute("SELECT * FROM %s WHERE pk = 1 " +
> "AND ck1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
>
[jira] [Comment Edited] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product
[
https://issues.apache.org/jira/browse/CASSANDRA-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490859#comment-17490859
]
Andres de la Peña edited comment on CASSANDRA-17187 at 2/11/22, 11:30 AM:
--
Here is the patch:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1444]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/f532c245-0374-43ab-b991-c58fab0c135d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/57c48e3e-5fc0-4df1-82ae-c50592b79427]|
The guardrail is relatively simple but the patch is a bit noisy because we need
to pass the {{ClientState}} to
[{{PartitionKeySingleRestrictionSet}}|https://github.com/apache/cassandra/blob/a6afd296e9accd29ee39d0394a4d0bcf126aa26d/src/java/org/apache/cassandra/cql3/restrictions/PartitionKeySingleRestrictionSet.java#L83-L97]
and
[{{ClusteringColumnRestrictions}}|https://github.com/apache/cassandra/blob/a6afd296e9accd29ee39d0394a4d0bcf126aa26d/src/java/org/apache/cassandra/cql3/restrictions/ClusteringColumnRestrictions.java#L106-L120],
and this affects a bunch of classes in the way.
There is also a minor refactor of the signatures of the utility methods
[{{GuardrailTester#assertWarns}}|https://github.com/apache/cassandra/blob/a6afd296e9accd29ee39d0394a4d0bcf126aa26d/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java#L183]
and
[{{GuardrailTester#assertFails}}|https://github.com/apache/cassandra/blob/a6afd296e9accd29ee39d0394a4d0bcf126aa26d/test/unit/org/apache/cassandra/db/guardrails/GuardrailTester.java#L193]
that (trivially) touches a bunch of tests. The reason for this refactor is
that we need to consider that a query can trigger multiple guardrails and thus
produce multiple warnings.
was (Author: adelapena):
Here is the patch:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1444]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/f532c245-0374-43ab-b991-c58fab0c135d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1296/workflows/57c48e3e-5fc0-4df1-82ae-c50592b79427]|
The guardrail is relatively simple but the patch is a bit noisy because we need
to pass the {{ClientState}} to {{PartitionKeySingleRestrictionSet}} and
{{{}ClusteringColumnRestrictions{}}}, and this affects a bunch of classes in
the way.
There is also a minor refactor ofthe signatures of the utility methods
{{GuardrailTester#assertWarns}} and {{GuardrailTester#aasertFails}} that
(trivially) touches a bunch of tests. The reason for this refactor is that we
need to consider that a query can trigger multiple guardrails and thus produce
multiple warnings.
> Guardrail for SELECT IN terms and their cartesian product
> -
>
> Key: CASSANDRA-17187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: lhf
> Fix For: 4.x
>
>
> Add a guardrail to limit the number restrictions generated by the cartesian
> product of the {{IN}} restrictions of a {{SELECT}} query, for example:
> {code}
> # Guardrail to warn or abort when IN query creates a cartesian product with a
> # size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)"
> results in
> # cartesian product of 100.
> # The two thresholds default to -1 to disable.
> in_select_cartesian_product:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> As an example of why this guardrails is proposed, these queries bring a C*
> instance to its knees even before the query starts executing:
> {code}
> @Test
> public void testPartitionKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5
> int, pk6 int, pk7 int, pk8 int, pk9 int, " +
>"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
> execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> @Test
> public void testClusteringKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int,
> ck5 int, ck6
[jira] [Assigned] (CASSANDRA-17353) Flatten guardrails configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-17353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-17353:
-
Assignee: Andres de la Peña
> Flatten guardrails configuration
>
>
> Key: CASSANDRA-17353
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17353
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Modify guardrails configuration at {{cassandra.yaml}} to have a flat format,
> instead of the current nested format. This ticket comes from the discussion
> around guardrails config on CASSANDRA-17292, CASSANDRA-17188 and
> CASSANDRA-17212, and doesn't include any of the other nested properties on
> {{cassandra.yaml}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17374) cassandra-website run.sh needs to move and prep files for content/ folder
Michael Semb Wever created CASSANDRA-17374: -- Summary: cassandra-website run.sh needs to move and prep files for content/ folder Key: CASSANDRA-17374 URL: https://issues.apache.org/jira/browse/CASSANDRA-17374 Project: Cassandra Issue Type: Bug Components: Documentation/Website Reporter: Michael Semb Wever Assignee: Anthony Grasso See manual steps still required here: https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:mck/16765#diff-1f760d89dfb81ea05a11d862007a4e4e586b38aac7ae87f62c5b2e86571809c0R1273-R1291 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17374) cassandra-website run.sh needs to move and prep files for content/ folder
[ https://issues.apache.org/jira/browse/CASSANDRA-17374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17374: --- Bug Category: Parent values: Documentation(13562) Complexity: Low Hanging Fruit Discovered By: User Report Reviewers: Michael Semb Wever Severity: Critical Status: Open (was: Triage Needed) > cassandra-website run.sh needs to move and prep files for content/ folder > - > > Key: CASSANDRA-17374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17374 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Anthony Grasso >Priority: Normal > > See manual steps still required here: > https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:mck/16765#diff-1f760d89dfb81ea05a11d862007a4e4e586b38aac7ae87f62c5b2e86571809c0R1273-R1291 > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17186:
--
Reviewers: Andres de la Peña
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Krishna Vadali
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17375) generate in-tree doc/antora.yml
Michael Semb Wever created CASSANDRA-17375: -- Summary: generate in-tree doc/antora.yml Key: CASSANDRA-17375 URL: https://issues.apache.org/jira/browse/CASSANDRA-17375 Project: Cassandra Issue Type: Bug Components: Documentation/Website Reporter: Michael Semb Wever Assignee: Anthony Grasso This file contains only metadata that can be auto-generated. Currently we can't build the website with ``` ANTORA_CONTENT_SOURCES_CASSANDRA_TAGS="cassandra-4.0.1 cassandra-3.11.12" ``` because the antora.yml files in those tags are clashing with their release branches. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17375) generate in-tree doc/antora.yml
[ https://issues.apache.org/jira/browse/CASSANDRA-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17375: --- Bug Category: Parent values: Documentation(13562) Complexity: Low Hanging Fruit Discovered By: User Report Reviewers: Michael Semb Wever Severity: Critical Status: Open (was: Triage Needed) > generate in-tree doc/antora.yml > --- > > Key: CASSANDRA-17375 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17375 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Anthony Grasso >Priority: Normal > > This file contains only metadata that can be auto-generated. > Currently we can't build the website with > ``` > ANTORA_CONTENT_SOURCES_CASSANDRA_TAGS="cassandra-4.0.1 cassandra-3.11.12" > ``` > because the antora.yml files in those tags are clashing with their release > branches. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17375) generate in-tree doc/antora.yml
[ https://issues.apache.org/jira/browse/CASSANDRA-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17375: --- Epic Link: CASSANDRA-16761 > generate in-tree doc/antora.yml > --- > > Key: CASSANDRA-17375 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17375 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Anthony Grasso >Priority: Normal > > This file contains only metadata that can be auto-generated. > Currently we can't build the website with > ``` > ANTORA_CONTENT_SOURCES_CASSANDRA_TAGS="cassandra-4.0.1 cassandra-3.11.12" > ``` > because the antora.yml files in those tags are clashing with their release > branches. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490897#comment-17490897
]
Andres de la Peña commented on CASSANDRA-17186:
---
[~tejavadali] thanks for the patch. Unfortunately CASSANDRA-17353 has changed
the format of the configuration for guardrails, so we would need to rebase the
patch and adapt it to the changes. Sorry for the inconvenience. The updated
configuration would look like:
{code:java}
# Guardrail to warn or fail when querying with an IN restriction selecting
# more partition keys than threshold.
# The two thresholds default to -1 to disable.
partition_keys_in_select_warn_threshold: -1
partition_keys_in_select_fail_threshold: -1
{code}
Other than that, the approach overall looks good to me, I have left a few
comments on the PR. The main point is that we need to pass the {{ClientState}}
of the query to the guardrail, so it's not applied to super user and internal
queries.
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Krishna Vadali
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17186:
--
Status: Review In Progress (was: Patch Available)
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Krishna Vadali
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17349) Fix flaky test - dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-17349: Assignee: Brandon Williams > Fix flaky test - > dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair > > > Key: CASSANDRA-17349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17349 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 2 times in the last 9 runs. Flakiness: 37%, Stability: 77% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. > Stacktrace > self = > def test_simple_sequential_repair(self): > """ > Calls simple repair test with a sequential repair > """ > > self._simple_repair(sequential=True) > repair_tests/repair_test.py:363: -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17327) Fix flaky test - dtest.offline_tools_test.TestOfflineTools.test_sstableverify
[ https://issues.apache.org/jira/browse/CASSANDRA-17327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490565#comment-17490565 ] Brandon Williams edited comment on CASSANDRA-17327 at 2/11/22, 1:04 PM: This doesn't fail in an instance of the jenkins testing docker image, either in isolation, or the offline tools suite. This is as close as possible to a jenkins instance and still won't reproduce, so this is going to be interesting. was (Author: brandon.williams): This doesn't fail in an instance of the jenkins testing docker image, either in isolation, or the offline tools suite. > Fix flaky test - dtest.offline_tools_test.TestOfflineTools.test_sstableverify > - > > Key: CASSANDRA-17327 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17327 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 15 times in the last 16 runs. Flakiness: 13%, Stability: 6% > Error Message > IndexError: list index out of range -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-17342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17342: Reviewers: Brandon Williams, Marcus Eriksson, Marcus Eriksson (was: Brandon Williams, Marcus Eriksson) Brandon Williams, Marcus Eriksson, Marcus Eriksson (was: Brandon Williams, Marcus Eriksson) Status: Review In Progress (was: Patch Available) > Performance problem for node restart with incremental range repairs > --- > > Key: CASSANDRA-17342 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17342 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Paul Chandler >Assignee: Paul Chandler >Priority: Normal > Fix For: 4.0.x > > Attachments: BulkRepairStateTest.java, > IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java > > > There is a performance problem when restarting cassandra for clusters doing > incremental repairs with range repairs. > We have clusters with 16 vnodes per node, and are splitting each vnode into > 100 ranges, this causes a node to take over 30 minutes to process the data > stored in the system.repairs table before the node can restart. Even when we > reduce this to 10 ranges per vnode this still takes 2 minutes to process. The > cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in > the system.repairs table. > > The problem seems to occur in the > org.apache.cassandra.repair.consistent.RepairState class where the add method > re processes the complete list, including sorting, every time a new Range is > added. This leads is an exponential growth in processing time, this is > demonstrated in the attached unit test. > > I have created a change, that collects the data read in from the > system.repairs table, in the > org.apache.cassandra.repair.consistent.LocalSessions class, before processing > it as a group at the end, this reduces the processing time to a couple of > seconds even for the 100 range version. > > This is my first attempt at changing the cassandra code, so I am in need of a > mentor to help me with the process, and validate what I have done. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-17342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17342: Status: Ready to Commit (was: Review In Progress) > Performance problem for node restart with incremental range repairs > --- > > Key: CASSANDRA-17342 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17342 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Paul Chandler >Assignee: Paul Chandler >Priority: Normal > Fix For: 4.0.x > > Attachments: BulkRepairStateTest.java, > IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java > > > There is a performance problem when restarting cassandra for clusters doing > incremental repairs with range repairs. > We have clusters with 16 vnodes per node, and are splitting each vnode into > 100 ranges, this causes a node to take over 30 minutes to process the data > stored in the system.repairs table before the node can restart. Even when we > reduce this to 10 ranges per vnode this still takes 2 minutes to process. The > cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in > the system.repairs table. > > The problem seems to occur in the > org.apache.cassandra.repair.consistent.RepairState class where the add method > re processes the complete list, including sorting, every time a new Range is > added. This leads is an exponential growth in processing time, this is > demonstrated in the attached unit test. > > I have created a change, that collects the data read in from the > system.repairs table, in the > org.apache.cassandra.repair.consistent.LocalSessions class, before processing > it as a group at the end, this reduces the processing time to a couple of > seconds even for the 100 range version. > > This is my first attempt at changing the cassandra code, so I am in need of a > mentor to help me with the process, and validate what I have done. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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: Improve start up processing of Incremental Repair information read from system.repairs
This is an automated email from the ASF dual-hosted git repository.
marcuse pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-4.0 by this push:
new c60ad61 Improve start up processing of Incremental Repair information
read from system.repairs
c60ad61 is described below
commit c60ad61b3b6145af100578f2c652819f61729018
Author: Paul Chandler
AuthorDate: Thu Feb 3 09:15:02 2022 +
Improve start up processing of Incremental Repair information read from
system.repairs
Patch by Paul Chandler, reviewed by Brandon Williams and Marcus Eriksson
for CASSANDRA-17342
---
CHANGES.txt| 2 +-
.../cassandra/repair/consistent/LocalSessions.java | 29 +++-
.../cassandra/repair/consistent/RepairedState.java | 33 +
.../repair/consistent/BulkRepairStateTest.java | 162 +
4 files changed, 192 insertions(+), 34 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index de4876f..d41d293 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,5 @@
4.0.3
-
+ * Improve start up processing of Incremental Repair information read from
system.repairs (CASSANDRA-17342)
4.0.2
* Full Java 11 support (CASSANDRA-16894)
diff --git a/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java
b/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java
index e6ca3ee..9ee0bb0 100644
--- a/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java
+++ b/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java
@@ -22,6 +22,7 @@ import java.io.IOException;
import java.net.UnknownHostException;
import java.nio.ByteBuffer;
import java.time.Instant;
+import java.util.ArrayList;
import java.util.Collection;
import java.util.Date;
import java.util.HashMap;
@@ -212,12 +213,7 @@ public class LocalSessions
private void maybeUpdateRepairedState(LocalSession session)
{
-if (session.getState() != FINALIZED)
-return;
-
-// if the session is finalized but has repairedAt set to 0, it was
-// a forced repair, and we shouldn't update the repaired state
-if (session.repairedAt == ActiveRepairService.UNREPAIRED_SSTABLE)
+if (!shouldStoreSession(session))
return;
for (TableId tid : session.tableIds)
@@ -227,6 +223,16 @@ public class LocalSessions
}
}
+private boolean shouldStoreSession(LocalSession session)
+{
+if (session.getState() != FINALIZED)
+return false;
+
+// if the session is finalized but has repairedAt set to 0, it was
+// a forced repair, and we shouldn't update the repaired state
+return session.repairedAt != ActiveRepairService.UNREPAIRED_SSTABLE;
+}
+
/**
* Determine if all ranges and tables covered by this session
* have since been re-repaired by a more recent session
@@ -341,13 +347,19 @@ public class LocalSessions
Preconditions.checkArgument(sessions.isEmpty(), "No sessions should be
added before start");
UntypedResultSet rows =
QueryProcessor.executeInternalWithPaging(String.format("SELECT * FROM %s.%s",
keyspace, table), 1000);
Map loadedSessions = new HashMap<>();
+Map> initialLevels = new
HashMap<>();
for (UntypedResultSet.Row row : rows)
{
try
{
LocalSession session = load(row);
-maybeUpdateRepairedState(session);
loadedSessions.put(session.sessionID, session);
+if (shouldStoreSession(session))
+{
+for (TableId tid : session.tableIds)
+initialLevels.computeIfAbsent(tid, (t) -> new
ArrayList<>())
+ .add(new
RepairedState.Level(session.ranges, session.repairedAt));
+}
}
catch (IllegalArgumentException | NullPointerException e)
{
@@ -356,6 +368,9 @@ public class LocalSessions
deleteRow(row.getUUID("parent_id"));
}
}
+for (Map.Entry> entry :
initialLevels.entrySet())
+getRepairedState(entry.getKey()).addAll(entry.getValue());
+
sessions = ImmutableMap.copyOf(loadedSessions);
failOngoingRepairs();
started = true;
diff --git a/src/java/org/apache/cassandra/repair/consistent/RepairedState.java
b/src/java/org/apache/cassandra/repair/consistent/RepairedState.java
index ac0e7cb..ea60eec 100644
--- a/src/java/org/apache/cassandra/repair/consistent/RepairedState.java
+++ b/src/java/org/apache/cassandra/repair/consistent/RepairedState.java
@@ -23,22 +23,16 @@ import java.util.Collection;
import java.util.Collections;
import java.util.Comparator;
import java.util.HashSet;
-import java.util.Iterator;
import java.util.List;
import java.ut
[cassandra] branch trunk updated (ab0a9fd -> 9649cb1)
This is an automated email from the ASF dual-hosted git repository.
marcuse pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git.
from ab0a9fd Merge branch 'cassandra-4.0' into trunk
new c60ad61 Improve start up processing of Incremental Repair information
read from system.repairs
new 9649cb1 Merge branch 'cassandra-4.0' into trunk
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
CHANGES.txt| 4 +-
.../cassandra/repair/consistent/LocalSessions.java | 29 --
.../cassandra/repair/consistent/RepairedState.java | 27 ++---
...pairStateTest.java => BulkRepairStateTest.java} | 110 ++---
4 files changed, 83 insertions(+), 87 deletions(-)
copy test/unit/org/apache/cassandra/repair/consistent/{RepairStateTest.java =>
BulkRepairStateTest.java} (50%)
-
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 trunk
This is an automated email from the ASF dual-hosted git repository. marcuse pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 9649cb1358a08f5f98413c556ef2f69fb7806c91 Merge: ab0a9fd c60ad61 Author: Marcus Eriksson AuthorDate: Fri Feb 11 14:09:43 2022 +0100 Merge branch 'cassandra-4.0' into trunk CHANGES.txt| 4 +- .../cassandra/repair/consistent/LocalSessions.java | 29 +++- .../cassandra/repair/consistent/RepairedState.java | 27 +--- .../repair/consistent/BulkRepairStateTest.java | 162 + 4 files changed, 193 insertions(+), 29 deletions(-) diff --cc CHANGES.txt index 444625f,d41d293..2a313ab --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,96 -1,6 +1,96 @@@ -4.0.3 +4.1 + * Limit the maximum hints size per host (CASSANDRA-17142) + * Add a virtual table for exposing batch metrics (CASSANDRA-17225) + * Flatten guardrails config (CASSANDRA-17353) + * Instance failed to start up due to NPE in StartupClusterConnectivityChecker (CASSANDRA-17347) + * add the shorter version of version flag (-v) in cqlsh (CASSANDRA-17236) + * Make vtables accessible via internode messaging (CASSANDRA-17295) + * Add support for PEM based key material for SSL (CASSANDRA-17031) + * Standardize storage configuration parameters' names. Support unit suffixes. (CASSANDRA-15234) + * Remove support for Windows (CASSANDRA-16956) + * Runtime-configurable YAML option to prohibit USE statements (CASSANDRA-17318) + * When streaming sees a ClosedChannelException this triggers the disk failure policy (CASSANDRA-17116) + * Add a virtual table for exposing prepared statements metrics (CASSANDRA-17224) + * Remove python 2.x support from cqlsh (CASSANDRA-17242) + * Prewarm role and credential caches to avoid timeouts at startup (CASSANDRA-16958) + * Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool (CASSANDRA-17063) + * Added startup check for read_ahead_kb setting (CASSANDRA-16436) + * Avoid unecessary array allocations and initializations when performing query checks (CASSANDRA-17209) + * Add guardrail for list operations that require read before write (CASSANDRA-17154) + * Migrate thresholds for number of keyspaces and tables to guardrails (CASSANDRA-17195) + * Remove self-reference in SSTableTidier (CASSANDRA-17205) + * Add guardrail for query page size (CASSANDRA-17189) + * Allow column_index_size_in_kb to be configurable through nodetool (CASSANDRA-17121) + * Emit a metric for number of local read and write calls + * Add non-blocking mode for CDC writes (CASSANDRA-17001) + * Add guardrails framework (CASSANDRA-17147) + * Harden resource management on SSTable components to prevent future leaks (CASSANDRA-17174) + * Make nodes more resilient to local unrelated files during startup (CASSANDRA-17082) + * repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout (CASSANDRA-16992) + * Log queries that fail on timeout or unavailable errors up to once per minute by default (CASSANDRA-17159) + * Refactor normal/preview/IR repair to standardize repair cleanup and error handling of failed RepairJobs (CASSANDRA-17069) + * Log missing peers in StartupClusterConnectivityChecker (CASSANDRA-17130) + * Introduce separate rate limiting settings for entire SSTable streaming (CASSANDRA-17065) + * Implement Virtual Tables for Auth Caches (CASSANDRA-16914) + * Actively update auth cache in the background (CASSANDRA-16957) + * Add unix time conversion functions (CASSANDRA-17029) + * JVMStabilityInspector.forceHeapSpaceOomMaybe should handle all non-heap OOMs rather than only supporting direct only (CASSANDRA-17128) + * Forbid other Future implementations with checkstyle (CASSANDRA-17055) + * commit log was switched from non-daemon to daemon threads, which causes the JVM to exit in some case as no non-daemon threads are active (CASSANDRA-17085) + * Add a Denylist to block reads and writes on specific partition keys (CASSANDRA-12106) + * v4+ protocol did not clean up client warnings, which caused leaking the state (CASSANDRA-17054) + * Remove duplicate toCQLString in ReadCommand (CASSANDRA-17023) + * Ensure hint window is persistent across restarts of a node (CASSANDRA-14309) + * Allow to GRANT or REVOKE multiple permissions in a single statement (CASSANDRA-17030) + * Allow to grant permission for all tables in a keyspace (CASSANDRA-17027) + * Log time spent writing keys during compaction (CASSANDRA-17037) + * Make nodetool compactionstats and sstable_tasks consistent (CASSANDRA-16976) + * Add metrics and logging around index summary redistribution (CASSANDRA-17036) + * Add configuration options for minimum allowable replication factor and default replication factor (CASSANDRA-14557) + * Expose information about stored hints via a nodetool command and a virtual tabl
[jira] [Updated] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-17342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17342: Fix Version/s: 4.0.3 (was: 4.0.x) Since Version: 4.0.0 Source Control Link: https://github.com/apache/cassandra/commit/c60ad61b3b6145af100578f2c652819f61729018 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed to 4.0 and merged up, thanks again for the patch! trunk tests look bad, but similar to [non-patched trunk|https://app.circleci.com/pipelines/github/krummas/cassandra/775/workflows/b0ede5ae-db7c-4a1d-b6ff-22245922bb46] [circleci 4.0|https://app.circleci.com/pipelines/github/krummas/cassandra/770/workflows/edfe8c85-0de6-4191-b4be-e7c4cb1a4c1e] [circleci trunk|https://app.circleci.com/pipelines/github/krummas/cassandra/769/workflows/6eea562c-0354-41e2-b253-32da2f929193] > Performance problem for node restart with incremental range repairs > --- > > Key: CASSANDRA-17342 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17342 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Paul Chandler >Assignee: Paul Chandler >Priority: Normal > Fix For: 4.0.3 > > Attachments: BulkRepairStateTest.java, > IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java > > > There is a performance problem when restarting cassandra for clusters doing > incremental repairs with range repairs. > We have clusters with 16 vnodes per node, and are splitting each vnode into > 100 ranges, this causes a node to take over 30 minutes to process the data > stored in the system.repairs table before the node can restart. Even when we > reduce this to 10 ranges per vnode this still takes 2 minutes to process. The > cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in > the system.repairs table. > > The problem seems to occur in the > org.apache.cassandra.repair.consistent.RepairState class where the add method > re processes the complete list, including sorting, every time a new Range is > added. This leads is an exponential growth in processing time, this is > demonstrated in the attached unit test. > > I have created a change, that collects the data read in from the > system.repairs table, in the > org.apache.cassandra.repair.consistent.LocalSessions class, before processing > it as a group at the end, this reduces the processing time to a couple of > seconds even for the 100 range version. > > This is my first attempt at changing the cassandra code, so I am in need of a > mentor to help me with the process, and validate what I have done. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-17342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17342: Fix Version/s: 4.1 > Performance problem for node restart with incremental range repairs > --- > > Key: CASSANDRA-17342 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17342 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Paul Chandler >Assignee: Paul Chandler >Priority: Normal > Fix For: 4.0.3, 4.1 > > Attachments: BulkRepairStateTest.java, > IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java > > > There is a performance problem when restarting cassandra for clusters doing > incremental repairs with range repairs. > We have clusters with 16 vnodes per node, and are splitting each vnode into > 100 ranges, this causes a node to take over 30 minutes to process the data > stored in the system.repairs table before the node can restart. Even when we > reduce this to 10 ranges per vnode this still takes 2 minutes to process. The > cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in > the system.repairs table. > > The problem seems to occur in the > org.apache.cassandra.repair.consistent.RepairState class where the add method > re processes the complete list, including sorting, every time a new Range is > added. This leads is an exponential growth in processing time, this is > demonstrated in the attached unit test. > > I have created a change, that collects the data read in from the > system.repairs table, in the > org.apache.cassandra.repair.consistent.LocalSessions class, before processing > it as a group at the end, this reduces the processing time to a couple of > seconds even for the 100 range version. > > This is my first attempt at changing the cassandra code, so I am in need of a > mentor to help me with the process, and validate what I have done. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17349) Fix flaky test - dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490938#comment-17490938 ] Brandon Williams commented on CASSANDRA-17349: -- This is broken by CASSANDRA-15252. [Repeatedly passing|https://app.circleci.com/pipelines/github/driftx/cassandra/355/workflows/8f4228a9-f769-4d64-9248-315d9cf16dba/jobs/4047] before the commit. [Failing|https://app.circleci.com/pipelines/github/driftx/cassandra/356/workflows/11ef3ae6-d59a-4d98-8a50-a23659118b7b/jobs/4048] afterward. > Fix flaky test - > dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair > > > Key: CASSANDRA-17349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17349 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 2 times in the last 9 runs. Flakiness: 37%, Stability: 77% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. > Stacktrace > self = > def test_simple_sequential_repair(self): > """ > Calls simple repair test with a sequential repair > """ > > self._simple_repair(sequential=True) > repair_tests/repair_test.py:363: -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17351) Pip doesn't install ccm every time
[ https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490949#comment-17490949 ] Ekaterina Dimitrova commented on CASSANDRA-17351: - As far as I am aware they use the same image, that is why I am confused... maybe [~mck] knows some detail I am missing? > Pip doesn't install ccm every time > -- > > Key: CASSANDRA-17351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17351 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Urgent > Fix For: 4.x > > > In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to > run without -e for ccm in order to address the moveable tag. That worked for > some time until last night. I successfully retagged and now ccm is not > re-installed in Circle CI. > Jenkins picked stuff though. But it was acting unreliably and weird so > rerunning now things there. Results pending. > Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still > pending results. I don't think this will be permanent solution and I am not > sure whether it will affect also the previous branches in a way. We need to > further investigate it and test. > For now I will ask people to test with -e until we figure it out. > CC [~mck] , [~bereng] , [~dcapwell] and [~stefan.miklosovic] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17351) Pip doesn't install ccm every time
[ https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490949#comment-17490949 ] Ekaterina Dimitrova edited comment on CASSANDRA-17351 at 2/11/22, 2:20 PM: --- [~dcapwell] as far as I am aware they use the same image, that is why I am confused... maybe [~mck] knows some detail I am missing? was (Author: e.dimitrova): As far as I am aware they use the same image, that is why I am confused... maybe [~mck] knows some detail I am missing? > Pip doesn't install ccm every time > -- > > Key: CASSANDRA-17351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17351 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Urgent > Fix For: 4.x > > > In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to > run without -e for ccm in order to address the moveable tag. That worked for > some time until last night. I successfully retagged and now ccm is not > re-installed in Circle CI. > Jenkins picked stuff though. But it was acting unreliably and weird so > rerunning now things there. Results pending. > Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still > pending results. I don't think this will be permanent solution and I am not > sure whether it will affect also the previous branches in a way. We need to > further investigate it and test. > For now I will ask people to test with -e until we figure it out. > CC [~mck] , [~bereng] , [~dcapwell] and [~stefan.miklosovic] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490952#comment-17490952
]
Benjamin Lerer commented on CASSANDRA-17190:
CI
[run|https://app.circleci.com/pipelines/github/blerer/cassandra/265/workflows/08917ba9-b2df-4779-b308-0be0e046e56b]
the failure is unrelated.
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17190:
---
Status: Ready to Commit (was: Review In Progress)
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17351) Pip doesn't install ccm every time
[ https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490954#comment-17490954 ] Ekaterina Dimitrova commented on CASSANDRA-17351: - There is something weird, at least to me. Some jobs use the base image in CircleCI, some use the other one which says that it caches ccm. But then we do pip3 install and as per the logs it says ccm installed so it is weird to me... I am missing something in the picture... > Pip doesn't install ccm every time > -- > > Key: CASSANDRA-17351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17351 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Urgent > Fix For: 4.x > > > In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to > run without -e for ccm in order to address the moveable tag. That worked for > some time until last night. I successfully retagged and now ccm is not > re-installed in Circle CI. > Jenkins picked stuff though. But it was acting unreliably and weird so > rerunning now things there. Results pending. > Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still > pending results. I don't think this will be permanent solution and I am not > sure whether it will affect also the previous branches in a way. We need to > further investigate it and test. > For now I will ask people to test with -e until we figure it out. > CC [~mck] , [~bereng] , [~dcapwell] and [~stefan.miklosovic] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Add support for string concatenations through the + operator
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 5cf62c6 Add support for string concatenations through the + operator
5cf62c6 is described below
commit 5cf62c6c02322505db9260d2aa9031386326fc75
Author: Manish Ghildiyal
AuthorDate: Sat Dec 18 18:26:31 2021 +0100
Add support for string concatenations through the + operator
Patch by Manish Ghildiyal; review by Benjamin Lerer, Berenguer Blassi,
Brandon Williams for CASSANDRA-17190
---
CHANGES.txt| 1 +
NEWS.txt | 1 +
src/java/org/apache/cassandra/cql3/Constants.java | 14 +++-
.../cassandra/cql3/functions/OperationFcts.java| 92 ++
.../apache/cassandra/db/marshal/StringType.java| 13 +++
.../cql3/functions/OperationFctsTest.java | 14
6 files changed, 118 insertions(+), 17 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 2a313ab..51e39bf 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Add support for string concatenations through the + operator
(CASSANDRA-17190)
* Limit the maximum hints size per host (CASSANDRA-17142)
* Add a virtual table for exposing batch metrics (CASSANDRA-17225)
* Flatten guardrails config (CASSANDRA-17353)
diff --git a/NEWS.txt b/NEWS.txt
index f5d76d5..26a1c8d 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -38,6 +38,7 @@ using the provided 'sstableupgrade' tool.
New features
+- Support for String concatenation has been added through the + operator.
- New configuration max_hints_size_per_host to limit the size of local
hints files per host in megabytes. Setting to
non-positive value disables the limit, which is the default behavior.
Setting to a positive value to ensure
the total size of the hints files per host does not exceed the limit.
diff --git a/src/java/org/apache/cassandra/cql3/Constants.java
b/src/java/org/apache/cassandra/cql3/Constants.java
index 3457e33..e8989ad 100644
--- a/src/java/org/apache/cassandra/cql3/Constants.java
+++ b/src/java/org/apache/cassandra/cql3/Constants.java
@@ -20,6 +20,7 @@ package org.apache.cassandra.cql3;
import java.math.BigDecimal;
import java.math.BigInteger;
import java.nio.ByteBuffer;
+import java.nio.charset.Charset;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -44,7 +45,18 @@ public abstract class Constants
public enum Type
{
-STRING,
+STRING
+{
+public AbstractType getPreferedTypeFor(String text)
+{
+ if(Charset.forName("US-ASCII").newEncoder().canEncode(text))
+ {
+ return AsciiType.instance;
+ }
+
+ return UTF8Type.instance;
+}
+},
INTEGER
{
public AbstractType getPreferedTypeFor(String text)
diff --git a/src/java/org/apache/cassandra/cql3/functions/OperationFcts.java
b/src/java/org/apache/cassandra/cql3/functions/OperationFcts.java
index 4994660..b00ced7 100644
--- a/src/java/org/apache/cassandra/cql3/functions/OperationFcts.java
+++ b/src/java/org/apache/cassandra/cql3/functions/OperationFcts.java
@@ -53,14 +53,24 @@ public final class OperationFcts
{
return type.addDuration(temporal, duration);
}
+
+@Override
+protected ByteBuffer excuteOnStrings(StringType resultType,
+ StringType leftType,
+ ByteBuffer left,
+ StringType rightType,
+ ByteBuffer right)
+{
+return resultType.concat(leftType, left, rightType, right);
+}
},
SUBSTRACTION('-', "_substract")
{
protected ByteBuffer executeOnNumerics(NumberType resultType,
- NumberType leftType,
- ByteBuffer left,
- NumberType rightType,
- ByteBuffer right)
+ NumberType leftType,
+ ByteBuffer left,
+ NumberType rightType,
+ ByteBuffer right)
{
return resultType.substract(leftType, left, rightType, right);
}
@@ -76,10 +86,10 @@ public final class OperationFcts
MULTIPLICATION('*', "_multiply")
{
protected ByteBuffer executeOnNumerics(NumberType resultType,
[cassandra-dtest] branch trunk updated: Take into account new contatenation support through the + operator
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 049b1c0 Take into account new contatenation support through the +
operator
049b1c0 is described below
commit 049b1c06aa35d6b10a0b3bab1a21d8c40a8ae4c0
Author: Manish Ghildiyal
AuthorDate: Sat Jan 15 10:23:58 2022 +0100
Take into account new contatenation support through the + operator
Patch by Manish Ghildiyal; Review by Benjamin Lerer for CASSANDRA-17190
---
user_functions_test.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/user_functions_test.py b/user_functions_test.py
index 4102352..24b2b1a 100644
--- a/user_functions_test.py
+++ b/user_functions_test.py
@@ -147,7 +147,7 @@ class TestUserFunctions(Tester):
session.execute("CREATE OR REPLACE FUNCTION overloaded(v ascii) called
on null input RETURNS text LANGUAGE java AS 'return \"f1\";'")
# ensure that works with correct specificity
-assert_invalid(session, "SELECT v FROM tab WHERE k =
overloaded('foo')")
+assert_none(session, "SELECT v FROM tab WHERE k = overloaded('foo')")
assert_none(session, "SELECT v FROM tab WHERE k = overloaded((text)
'foo')")
assert_none(session, "SELECT v FROM tab WHERE k = overloaded((ascii)
'foo')")
assert_none(session, "SELECT v FROM tab WHERE k = overloaded((varchar)
'foo')")
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17351) Pip doesn't install ccm every time
[ https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490958#comment-17490958 ] Michael Semb Wever commented on CASSANDRA-17351: Jenkins prunes its docker regularly… see `docker system prune` occurrences in https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy is this stuff that comes from inside the image deployed: https://github.com/apache/cassandra-builds/blob/trunk/docker/testing/ubuntu2004_j11.docker ? > Pip doesn't install ccm every time > -- > > Key: CASSANDRA-17351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17351 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Urgent > Fix For: 4.x > > > In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to > run without -e for ccm in order to address the moveable tag. That worked for > some time until last night. I successfully retagged and now ccm is not > re-installed in Circle CI. > Jenkins picked stuff though. But it was acting unreliably and weird so > rerunning now things there. Results pending. > Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still > pending results. I don't think this will be permanent solution and I am not > sure whether it will affect also the previous branches in a way. We need to > further investigate it and test. > For now I will ask people to test with -e until we figure it out. > CC [~mck] , [~bereng] , [~dcapwell] and [~stefan.miklosovic] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17190:
---
Fix Version/s: 4.1
(was: 4.x)
Source Control Link:
https://github.com/apache/cassandra/commit/5cf62c6c02322505db9260d2aa9031386326fc75
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into cassandra trunk at 5cf62c6c02322505db9260d2aa9031386326fc75
and DTest change committed into DTest trunk at
049b1c06aa35d6b10a0b3bab1a21d8c40a8ae4c0
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490967#comment-17490967
]
Benjamin Lerer commented on CASSANDRA-17190:
Thanks a lot for the patch [~manish.c.ghildi...@gmail.com]
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490967#comment-17490967
]
Benjamin Lerer edited comment on CASSANDRA-17190 at 2/11/22, 2:57 PM:
--
Thanks a lot for the patches [~manish.c.ghildi...@gmail.com]
was (Author: blerer):
Thanks a lot for the patch [~manish.c.ghildi...@gmail.com]
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17351) Pip doesn't install ccm every time
[ https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490999#comment-17490999 ] Ekaterina Dimitrova commented on CASSANDRA-17351: - Alright...this is confusing... So a few notes: * It seems J11 executors use the base image, J8 use the one with dependencies... I don't know of any specific reason for this difference. But now I ran in Circle with low resources the J11 cqlsh tests and I don't see the config issues Only those we see when running with low resources: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1377/workflows/d2a2f507-0264-4fc7-8417-0759c01134b8/jobs/8878 * Looking [here, |https://github.com/apache/cassandra-builds/blob/trunk/docker/testing/ubuntu2004_j11.docker] it seems we setup in the base image the virtual env used by CircleCI. So it can be we cache that one, but now... I changed to new virtual env and installed the requirements.txt packages myself in Circle config yesterday so I am lost about that... * Looking at the [cassandra_job_dsl_seed.groovy|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy], seems to me we use the base image for everything dtest which I assume means - python upgrade tests, dtests and cqlsh tests. So seems to me we have two options - I _think_ probably rebuilding the second image should solve the issue. If we opt in for that one I should probably change what image we use everywhere in Circle config, to align J8 and J11 if there are no obstacles. Wondering whether we should simply align with the way Jenkins works and it always work when we update ccm. Or... we should think the other way around whether we can benefit of moving to the second image in Jenkins and asking people to rebuild the image on ccm retagging? > Pip doesn't install ccm every time > -- > > Key: CASSANDRA-17351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17351 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Urgent > Fix For: 4.x > > > In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to > run without -e for ccm in order to address the moveable tag. That worked for > some time until last night. I successfully retagged and now ccm is not > re-installed in Circle CI. > Jenkins picked stuff though. But it was acting unreliably and weird so > rerunning now things there. Results pending. > Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still > pending results. I don't think this will be permanent solution and I am not > sure whether it will affect also the previous branches in a way. We need to > further investigate it and test. > For now I will ask people to test with -e until we figure it out. > CC [~mck] , [~bereng] , [~dcapwell] and [~stefan.miklosovic] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17351) Pip doesn't install ccm every time
[ https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490999#comment-17490999 ] Ekaterina Dimitrova edited comment on CASSANDRA-17351 at 2/11/22, 3:52 PM: --- Alright...this is confusing... So a few notes: * It seems J11 executors use the base image, J8 use the one with dependencies... I don't know of any specific reason for this difference. But now I ran in Circle with low resources the J11 cqlsh tests and I don't see the config issues Only those we see when running with low resources: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1377/workflows/d2a2f507-0264-4fc7-8417-0759c01134b8/jobs/8878] * Looking [here, |https://github.com/apache/cassandra-builds/blob/trunk/docker/testing/ubuntu2004_j11.docker] it seems we setup in the base image the virtual env used by CircleCI. So it can be we cache that one, but now... I changed to new virtual env and installed the requirements.txt packages myself in Circle config yesterday so I am lost about that... * Looking at the [cassandra_job_dsl_seed.groovy|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy], seems to me we use the base image for everything dtest which I assume means - python upgrade tests, dtests and cqlsh tests. So seems to me we have two options - I _think_ probably rebuilding the second image should solve the issue. If we opt in for that one I should probably change what image we use everywhere in Circle config, to align J8 and J11 if there are no obstacles and add a remark in the docs we need to rebuild the second image every time we retag ccm from now on. Wondering whether we should simply align with the way Jenkins works and it always works when we update ccm. Or... we should think the other way around whether we can benefit of moving to the second image in Jenkins and asking people to rebuild the image on ccm retagging? was (Author: e.dimitrova): Alright...this is confusing... So a few notes: * It seems J11 executors use the base image, J8 use the one with dependencies... I don't know of any specific reason for this difference. But now I ran in Circle with low resources the J11 cqlsh tests and I don't see the config issues Only those we see when running with low resources: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1377/workflows/d2a2f507-0264-4fc7-8417-0759c01134b8/jobs/8878] * Looking [here, |https://github.com/apache/cassandra-builds/blob/trunk/docker/testing/ubuntu2004_j11.docker] it seems we setup in the base image the virtual env used by CircleCI. So it can be we cache that one, but now... I changed to new virtual env and installed the requirements.txt packages myself in Circle config yesterday so I am lost about that... * Looking at the [cassandra_job_dsl_seed.groovy|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy], seems to me we use the base image for everything dtest which I assume means - python upgrade tests, dtests and cqlsh tests. So seems to me we have two options - I _think_ probably rebuilding the second image should solve the issue. If we opt in for that one I should probably change what image we use everywhere in Circle config, to align J8 and J11 if there are no obstacles and add a remark in the docs we need to rebuild the second image every time we retag ccm from now on. Wondering whether we should simply align with the way Jenkins works and it always work when we update ccm. Or... we should think the other way around whether we can benefit of moving to the second image in Jenkins and asking people to rebuild the image on ccm retagging? > Pip doesn't install ccm every time > -- > > Key: CASSANDRA-17351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17351 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Urgent > Fix For: 4.x > > > In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to > run without -e for ccm in order to address the moveable tag. That worked for > some time until last night. I successfully retagged and now ccm is not > re-installed in Circle CI. > Jenkins picked stuff though. But it was acting unreliably and weird so > rerunning now things there. Results pending. > Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still > pending results. I don't think this will be permanent solution and I am not > sure whether it will affect also the previous branches in a way. We need to > further investigate it and test. > For now I will ask people to test with -e until we figure it out. > CC [~mck] , [~bereng] , [
[jira] [Comment Edited] (CASSANDRA-17351) Pip doesn't install ccm every time
[ https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490999#comment-17490999 ] Ekaterina Dimitrova edited comment on CASSANDRA-17351 at 2/11/22, 3:52 PM: --- Alright...this is confusing... So a few notes: * It seems J11 executors use the base image, J8 use the one with dependencies... I don't know of any specific reason for this difference. But now I ran in Circle with low resources the J11 cqlsh tests and I don't see the config issues Only those we see when running with low resources: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1377/workflows/d2a2f507-0264-4fc7-8417-0759c01134b8/jobs/8878] * Looking [here, |https://github.com/apache/cassandra-builds/blob/trunk/docker/testing/ubuntu2004_j11.docker] it seems we setup in the base image the virtual env used by CircleCI. So it can be we cache that one, but now... I changed to new virtual env and installed the requirements.txt packages myself in Circle config yesterday so I am lost about that... * Looking at the [cassandra_job_dsl_seed.groovy|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy], seems to me we use the base image for everything dtest which I assume means - python upgrade tests, dtests and cqlsh tests. So seems to me we have two options - I _think_ probably rebuilding the second image should solve the issue. If we opt in for that one I should probably change what image we use everywhere in Circle config, to align J8 and J11 if there are no obstacles and add a remark in the docs we need to rebuild the second image every time we retag ccm from now on. Wondering whether we should simply align with the way Jenkins works and it always work when we update ccm. Or... we should think the other way around whether we can benefit of moving to the second image in Jenkins and asking people to rebuild the image on ccm retagging? was (Author: e.dimitrova): Alright...this is confusing... So a few notes: * It seems J11 executors use the base image, J8 use the one with dependencies... I don't know of any specific reason for this difference. But now I ran in Circle with low resources the J11 cqlsh tests and I don't see the config issues Only those we see when running with low resources: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1377/workflows/d2a2f507-0264-4fc7-8417-0759c01134b8/jobs/8878 * Looking [here, |https://github.com/apache/cassandra-builds/blob/trunk/docker/testing/ubuntu2004_j11.docker] it seems we setup in the base image the virtual env used by CircleCI. So it can be we cache that one, but now... I changed to new virtual env and installed the requirements.txt packages myself in Circle config yesterday so I am lost about that... * Looking at the [cassandra_job_dsl_seed.groovy|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy], seems to me we use the base image for everything dtest which I assume means - python upgrade tests, dtests and cqlsh tests. So seems to me we have two options - I _think_ probably rebuilding the second image should solve the issue. If we opt in for that one I should probably change what image we use everywhere in Circle config, to align J8 and J11 if there are no obstacles. Wondering whether we should simply align with the way Jenkins works and it always work when we update ccm. Or... we should think the other way around whether we can benefit of moving to the second image in Jenkins and asking people to rebuild the image on ccm retagging? > Pip doesn't install ccm every time > -- > > Key: CASSANDRA-17351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17351 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Urgent > Fix For: 4.x > > > In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to > run without -e for ccm in order to address the moveable tag. That worked for > some time until last night. I successfully retagged and now ccm is not > re-installed in Circle CI. > Jenkins picked stuff though. But it was acting unreliably and weird so > rerunning now things there. Results pending. > Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still > pending results. I don't think this will be permanent solution and I am not > sure whether it will affect also the previous branches in a way. We need to > further investigate it and test. > For now I will ask people to test with -e until we figure it out. > CC [~mck] , [~bereng] , [~dcapwell] and [~stefan.miklosovic] -- This message was sent by Atlassian Jira (v8.20.1#820001) ---
[jira] [Comment Edited] (CASSANDRA-17351) Pip doesn't install ccm every time
[ https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490999#comment-17490999 ] Ekaterina Dimitrova edited comment on CASSANDRA-17351 at 2/11/22, 3:55 PM: --- Alright...this is confusing... So a few notes: * It seems in CircleCI J11 executors use the base image, J8 use the one with dependencies... I don't know of any specific reason for this difference. But now I ran in Circle with low resources the J11 cqlsh tests and I don't see the config issues Only those we see when running with low resources: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1377/workflows/d2a2f507-0264-4fc7-8417-0759c01134b8/jobs/8878] * Looking [here, |https://github.com/apache/cassandra-builds/blob/trunk/docker/testing/ubuntu2004_j11.docker] it seems we setup in the base image the virtual env used by CircleCI. So it can be we cache that one, but now... I changed to new virtual env and installed the requirements.txt packages myself in Circle config yesterday so I am lost about that... * Looking at the [cassandra_job_dsl_seed.groovy|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy], seems to me we use the base image for everything dtest which I assume means - python upgrade tests, dtests and cqlsh tests. So seems to me we have two options - I _think_ probably rebuilding the second image should solve the issue. If we opt in for that one I should probably change what image we use everywhere in Circle config, to align J8 and J11 if there are no obstacles and add a remark in the docs we need to rebuild the second image every time we retag ccm from now on. Wondering whether we should simply align with the way Jenkins works and it always works when we update ccm. Or... we should think the other way around whether we can benefit of moving to the second image in Jenkins and asking people to rebuild the image on ccm retagging? was (Author: e.dimitrova): Alright...this is confusing... So a few notes: * It seems J11 executors use the base image, J8 use the one with dependencies... I don't know of any specific reason for this difference. But now I ran in Circle with low resources the J11 cqlsh tests and I don't see the config issues Only those we see when running with low resources: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1377/workflows/d2a2f507-0264-4fc7-8417-0759c01134b8/jobs/8878] * Looking [here, |https://github.com/apache/cassandra-builds/blob/trunk/docker/testing/ubuntu2004_j11.docker] it seems we setup in the base image the virtual env used by CircleCI. So it can be we cache that one, but now... I changed to new virtual env and installed the requirements.txt packages myself in Circle config yesterday so I am lost about that... * Looking at the [cassandra_job_dsl_seed.groovy|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy], seems to me we use the base image for everything dtest which I assume means - python upgrade tests, dtests and cqlsh tests. So seems to me we have two options - I _think_ probably rebuilding the second image should solve the issue. If we opt in for that one I should probably change what image we use everywhere in Circle config, to align J8 and J11 if there are no obstacles and add a remark in the docs we need to rebuild the second image every time we retag ccm from now on. Wondering whether we should simply align with the way Jenkins works and it always works when we update ccm. Or... we should think the other way around whether we can benefit of moving to the second image in Jenkins and asking people to rebuild the image on ccm retagging? > Pip doesn't install ccm every time > -- > > Key: CASSANDRA-17351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17351 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Urgent > Fix For: 4.x > > > In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to > run without -e for ccm in order to address the moveable tag. That worked for > some time until last night. I successfully retagged and now ccm is not > re-installed in Circle CI. > Jenkins picked stuff though. But it was acting unreliably and weird so > rerunning now things there. Results pending. > Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still > pending results. I don't think this will be permanent solution and I am not > sure whether it will affect also the previous branches in a way. We need to > further investigate it and test. > For now I will ask people to test with -e until we figure it out. > CC [~mck] ,
[jira] [Assigned] (CASSANDRA-17351) Pip doesn't install ccm every time
[ https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-17351: --- Assignee: Ekaterina Dimitrova > Pip doesn't install ccm every time > -- > > Key: CASSANDRA-17351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17351 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Urgent > Fix For: 4.x > > > In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to > run without -e for ccm in order to address the moveable tag. That worked for > some time until last night. I successfully retagged and now ccm is not > re-installed in Circle CI. > Jenkins picked stuff though. But it was acting unreliably and weird so > rerunning now things there. Results pending. > Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still > pending results. I don't think this will be permanent solution and I am not > sure whether it will affect also the previous branches in a way. We need to > further investigate it and test. > For now I will ask people to test with -e until we figure it out. > CC [~mck] , [~bereng] , [~dcapwell] and [~stefan.miklosovic] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17351) Pip doesn't install ccm every time
[ https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491012#comment-17491012 ] Brandon Williams commented on CASSANDRA-17351: -- bq. Wondering whether we should simply align with the way Jenkins work Two build systems already adds its own level of complexity, so I'd like to keep that minimized by keeping them aligned. > Pip doesn't install ccm every time > -- > > Key: CASSANDRA-17351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17351 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Urgent > Fix For: 4.x > > > In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to > run without -e for ccm in order to address the moveable tag. That worked for > some time until last night. I successfully retagged and now ccm is not > re-installed in Circle CI. > Jenkins picked stuff though. But it was acting unreliably and weird so > rerunning now things there. Results pending. > Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still > pending results. I don't think this will be permanent solution and I am not > sure whether it will affect also the previous branches in a way. We need to > further investigate it and test. > For now I will ask people to test with -e until we figure it out. > CC [~mck] , [~bereng] , [~dcapwell] and [~stefan.miklosovic] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17328) Fix flaky test - dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-17328: Assignee: Brandon Williams > Fix flaky test - > dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair > -- > > Key: CASSANDRA-17328 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17328 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 4 times in the last 26 runs. Flakiness: 28%, Stability: 84% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16565) Remove dependency on sigar
[ https://issues.apache.org/jira/browse/CASSANDRA-16565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-16565: -- Assignee: (was: Kanthi Subramanian) > Remove dependency on sigar > -- > > Key: CASSANDRA-16565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16565 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Priority: Normal > > sigar is used to check if the environment has good settings for running C*, > but requires we bundle a lot of native libraries to perform this check (which > can also be done elsewhere). This project also appears to be dead as the > last commit was around 6 years ago. > With the move to resolve artifacts rather than commit them, removing this > dependency would remove majority of the artifacts fetched from GitHub. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan updated CASSANDRA-17352: Fix Version/s: 4.0.2 3.11.12 3.0.26 > CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs > - > > Key: CASSANDRA-17352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17352 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDF >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.26, 3.11.12, 4.0.2 > > > When running Apache Cassandra with the following configuration: > enable_user_defined_functions: true > enable_scripted_user_defined_functions: true > enable_user_defined_functions_threads: false > it is possible for an attacker to execute arbitrary code on the host. The > attacker would need to have enough permissions to create user defined > functions in the cluster to be able to exploit this. Note that this > configuration is documented as unsafe, and will continue to be considered > unsafe after this CVE. > This issue is being tracked as CASSANDRA-17352 > Mitigation: > Set `enable_user_defined_functions_threads: true` (this is default) > or > 3.0 users should upgrade to 3.0.26 > 3.11 users should upgrade to 3.11.12 > 4.0 users should upgrade to 4.0.2 > Credit: > This issue was discovered by Omer Kaspi of the JFrog Security vulnerability > research team. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17352: - Status: Open (was: Patch Available) > CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs > - > > Key: CASSANDRA-17352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17352 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDF >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.26, 3.11.12, 4.0.2 > > > When running Apache Cassandra with the following configuration: > enable_user_defined_functions: true > enable_scripted_user_defined_functions: true > enable_user_defined_functions_threads: false > it is possible for an attacker to execute arbitrary code on the host. The > attacker would need to have enough permissions to create user defined > functions in the cluster to be able to exploit this. Note that this > configuration is documented as unsafe, and will continue to be considered > unsafe after this CVE. > This issue is being tracked as CASSANDRA-17352 > Mitigation: > Set `enable_user_defined_functions_threads: true` (this is default) > or > 3.0 users should upgrade to 3.0.26 > 3.11 users should upgrade to 3.11.12 > 4.0 users should upgrade to 4.0.2 > Credit: > This issue was discovered by Omer Kaspi of the JFrog Security vulnerability > research team. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-17352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17352: - Resolution: Fixed Status: Resolved (was: Open) > CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs > - > > Key: CASSANDRA-17352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17352 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDF >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.26, 3.11.12, 4.0.2 > > > When running Apache Cassandra with the following configuration: > enable_user_defined_functions: true > enable_scripted_user_defined_functions: true > enable_user_defined_functions_threads: false > it is possible for an attacker to execute arbitrary code on the host. The > attacker would need to have enough permissions to create user defined > functions in the cluster to be able to exploit this. Note that this > configuration is documented as unsafe, and will continue to be considered > unsafe after this CVE. > This issue is being tracked as CASSANDRA-17352 > Mitigation: > Set `enable_user_defined_functions_threads: true` (this is default) > or > 3.0 users should upgrade to 3.0.26 > 3.11 users should upgrade to 3.11.12 > 4.0 users should upgrade to 4.0.2 > Credit: > This issue was discovered by Omer Kaspi of the JFrog Security vulnerability > research team. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-17293: --- Summary: Update python test framework from nose to pytest (was: Update python test framework from nose to nose2) > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Yash Ladha >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to nose2 is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-17293: --- Description: I had trouble trying to install and run the python nose test from pip (nosetest not found). According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] h1. _Note to Users_ _Nose has been in maintenance mode for the past several years and will likely cease without a new person/team to take over maintainership. New projects should consider using [Nose2|https://github.com/nose-devs/nose2], [py.test|http://pytest.org/], or just plain unittest/unittest2._ Upgrading to pytest is likely the least effort. was: I had trouble trying to install and run the python nose test from pip (nosetest not found). According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] h1. _Note to Users_ _Nose has been in maintenance mode for the past several years and will likely cease without a new person/team to take over maintainership. New projects should consider using [Nose2|https://github.com/nose-devs/nose2], [py.test|http://pytest.org/], or just plain unittest/unittest2._ Upgrading to nose2 is likely the least effort. > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Yash Ladha >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17166) Enhance SnakeYAML properties to be reusable outside of YAML parsing, support camel case conversion to snake case, and add support to ignore properties
[ https://issues.apache.org/jira/browse/CASSANDRA-17166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491107#comment-17491107 ] David Capwell commented on CASSANDRA-17166: --- Added support for system properties (for fields that are not a collection type), this is disabled by default be can get enabled by adding -Dcassandra.config.allow_system_properties=true. If you add -Dcassandra.[Config name] or the nested name, then it will override what is present in the yaml. > Enhance SnakeYAML properties to be reusable outside of YAML parsing, support > camel case conversion to snake case, and add support to ignore properties > -- > > Key: CASSANDRA-17166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17166 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 40m > Remaining Estimate: 0h > > SnakeYaml is rather limited in the “object mapping” layer, which forces our > internal code to match specific patterns (all fields public and camel case); > we can remove this restriction by leveraging Jackson for property lookup, and > leaving the YAML handling to SnakeYAML -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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 (3119850 -> 5579183)
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 3119850 ninja omit 56da4b9 generate docs for ee56da10 add bb42048 Releases 3.0.26, 3.11.12, 4.0.2 new 5579183 generate docs for bb420481 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 (3119850) \ N -- N -- N refs/heads/asf-staging (5579183) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/_/download.html| 52 ++--- .../cassandra/configuration/cass_yaml_file.html| 211 - .../cassandra/configuration/cass_yaml_file.html| 211 - .../cassandra/configuration/cass_yaml_file.html| 211 - content/search-index.js| 2 +- .../source/modules/ROOT/pages/download.adoc| 18 +- site-ui/build/ui-bundle.zip| Bin 4740084 -> 4740084 bytes 7 files changed, 651 insertions(+), 54 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (5579183 -> 6568f4b)
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 5579183 generate docs for bb420481 new 6568f4b generate docs for bb420481 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 (5579183) \ N -- N -- N refs/heads/asf-staging (6568f4b) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740084 -> 4740084 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491145#comment-17491145
]
Andres de la Peña commented on CASSANDRA-17186:
---
CI is running, I have included some repeated runs of the new tests:
||Branch||CI||
|[trunk|https://github.com/adelapena/cassandra/tree/17186-trunk]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1297/workflows/f578a4e9-8d71-452c-b193-792330126722]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1297/workflows/0cca387d-e953-4dc0-982d-155b4a2e233d]|
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Krishna Vadali
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491150#comment-17491150
]
Ekaterina Dimitrova commented on CASSANDRA-16378:
-
Hey [~paulo], I see you mentioned as a second reviewer, do you still plan to
review it or should [~Bereng] (for example) steal it? :D
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491150#comment-17491150
]
Ekaterina Dimitrova edited comment on CASSANDRA-16378 at 2/11/22, 9:05 PM:
---
Hey [~paulo], I see you mentioned as a second reviewer, do you still plan to
review it or should [~Bereng] (for example) steal it? :D (jokes aside, I can
also take it :) )
was (Author: e.dimitrova):
Hey [~paulo], I see you mentioned as a second reviewer, do you still plan to
review it or should [~Bereng] (for example) steal it? :D
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16378:
Reviewers: Benjamin Lerer, Ekaterina Dimitrova (was: Benjamin Lerer, Paulo
Motta)
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16378:
Description:
Recent java-driver's
[com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
respects properties
[ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
and
[ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
It would be helpful to expose this information via virtual table
{{system_views.clients}} and with {{{}nodetool clientstats{}}}.
+Additional information for newcomers:+
The drivers can send as part of the {{STARTUP MESSAGE}} the
{{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
fields {{applicationName}} and {{applicationVersion}} need to be added to
{{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
retrieved in {{StartupMessage#execute}} and passed to the {{{}ClientState{}}}.
The new {{application_name}} and {{application_version}} columns need to be
added to the {{system_views.clients}} represented by the {{ClientsTable}}
class. The data then need to be retrieved from the {{ClientState}} through
{{{}ConnectedClient{}}}.
Some unit tests similat to {{SettingsTableTest}} should be added.
was:
Recent java-driver's
[com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
respects properties
[ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
and
[ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
It would be helpful to exposed this information via virtual table
{{system_views.clients}} and with {{nodetool clientstats}}.
+Additional information for newcomers:+
The drivers can send as part of the {{STARTUP MESSAGE}} the
{{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
fields {{applicationName}} and {{applicationVersion}} need to be added to
{{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
The new {{application_name}} and {{application_version}} columns need to be
added to the {{system_views.clients}} represented by the {{ClientsTable}}
class. The data then need to be retrieved from the {{ClientState}} through
{{ConnectedClient}}.
Some unit tests similat to {{SettingsTableTest}} should be added.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to t
[jira] [Updated] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16378:
Description:
Recent java-driver's
[com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
respects properties
[ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
and
[ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
It would be helpful to expose this information via virtual table
{{system_views.clients}} and with {{{}nodetool clientstats{}}}.
+Additional information for newcomers:+
The drivers can send as part of the {{STARTUP MESSAGE}} the
{{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
fields {{applicationName}} and {{applicationVersion}} need to be added to
{{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
retrieved in {{StartupMessage#execute}} and passed to the {{{}ClientState{}}}.
The new {{application_name}} and {{application_version}} columns need to be
added to the {{system_views.clients}} represented by the {{ClientsTable}}
class. The data then need to be retrieved from the {{ClientState}} through
{{{}ConnectedClient{}}}.
Some unit tests similat to {{SettingsTableTest}} should be added.
was:
Recent java-driver's
[com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
respects properties
[ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
and
[ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
It would be helpful to expose this information via virtual table
{{system_views.clients}} and with {{{}nodetool clientstats{}}}.
+Additional information for newcomers:+
The drivers can send as part of the {{STARTUP MESSAGE}} the
{{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
fields {{applicationName}} and {{applicationVersion}} need to be added to
{{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
retrieved in {{StartupMessage#execute}} and passed to the {{{}ClientState{}}}.
The new {{application_name}} and {{application_version}} columns need to be
added to the {{system_views.clients}} represented by the {{ClientsTable}}
class. The data then need to be retrieved from the {{ClientState}} through
{{{}ConnectedClient{}}}.
Some unit tests similat to {{SettingsTableTest}} should be added.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} a
[jira] [Updated] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16378:
Description:
Recent java-driver's
[com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
respects properties
[ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
and
[ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
It would be helpful to expose this information via virtual table
{{system_views.clients}} and with {{{}nodetool clientstats{}}}.
+Additional information for newcomers:+
The drivers can send as part of the {{STARTUP MESSAGE}} the
{{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
fields {{applicationName}} and {{applicationVersion}} need to be added to
{{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options need to be
retrieved in {{StartupMessage#execute}} and passed to the {{{}ClientState{}}}.
The new {{application_name}} and {{application_version}} columns need to be
added to the {{system_views.clients}} represented by the {{ClientsTable}}
class. The data then need to be retrieved from the {{ClientState}} through
{{{}ConnectedClient{}}}.
Some unit tests similat to {{SettingsTableTest}} should be added.
was:
Recent java-driver's
[com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
respects properties
[ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
and
[ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
It would be helpful to expose this information via virtual table
{{system_views.clients}} and with {{{}nodetool clientstats{}}}.
+Additional information for newcomers:+
The drivers can send as part of the {{STARTUP MESSAGE}} the
{{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
fields {{applicationName}} and {{applicationVersion}} need to be added to
{{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
retrieved in {{StartupMessage#execute}} and passed to the {{{}ClientState{}}}.
The new {{application_name}} and {{application_version}} columns need to be
added to the {{system_views.clients}} represented by the {{ClientsTable}}
class. The data then need to be retrieved from the {{ClientState}} through
{{{}ConnectedClient{}}}.
Some unit tests similat to {{SettingsTableTest}} should be added.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options need to be
> retrieved in {{StartupMessage#execute}
[jira] [Commented] (CASSANDRA-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491156#comment-17491156
]
Kanthi Subramanian commented on CASSANDRA-17198:
Hi [~blerer] , can you please take a look at the PR when u get a chance.
[https://github.com/apache/cassandra/pull/1373]
> Allow to filter using LIKE predicates
> -
>
> Key: CASSANDRA-17198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17198
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Kanthi Subramanian
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> {{LIKE}} predicates can only be used with the SASI indices. In several
> usecases (e.g. querying the {{settings}} virtual table) it makes sense to
> support them for filtering.
> +Additional information for newcomers:+
> There are some checks in the {{StatementRestrictions}} constructor and on
> {{LikeRestriction}} that need to be removed for allowing filtering using LIKE
> on clustering and regular columns.
> For filtering on partition columns the {{needFiltering}} methods in
> {{PartitionKeySingleRestrictionSet}} will need to be modified to return true
> when LIKE predicate are used.
> The unit tests should go in {{SelectTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-12937:
--
Assignee: (was: Kanthi Subramanian)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Priority: Low
> Labels: AdventCalendar2021, lhf
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17369) Set the config in In-JVM upgrade tests to the old format on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491166#comment-17491166 ] David Capwell commented on CASSANDRA-17369: --- +1 assuming tests are clean > Set the config in In-JVM upgrade tests to the old format on trunk > - > > Key: CASSANDRA-17369 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17369 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In-JVM upgrade tests do no support per-version config. > Revert the config in In-JVM upgrade tests to the old format on trunk. > CC [~dcapwell] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17369) Set the config in In-JVM upgrade tests to the old format on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17369: -- Reviewers: David Capwell, David Capwell David Capwell, David Capwell (was: David Capwell) Status: Review In Progress (was: Patch Available) > Set the config in In-JVM upgrade tests to the old format on trunk > - > > Key: CASSANDRA-17369 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17369 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In-JVM upgrade tests do no support per-version config. > Revert the config in In-JVM upgrade tests to the old format on trunk. > CC [~dcapwell] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17135) Update docs for CASSANDRA-17132
[
https://issues.apache.org/jira/browse/CASSANDRA-17135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez reassigned CASSANDRA-17135:
-
Assignee: Erick Ramirez
> Update docs for CASSANDRA-17132
> ---
>
> Key: CASSANDRA-17135
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17135
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Some cleaning of old parameters was done in CASSANDRA-17132.
> We need to update the docs respectively after the migration to ASCIIdoc is
> done:
> * Remove any references to {_}otc_backlog_expiration_interval_ms,
> otc_coalescing_strategy, otc_coalescing_window_us_default{_},
> _otc_coalescing_window_us,_ _otc_coalescing_enough_coalesced_messages,
> internode_application_timeout_in_ms._
> * The names of _internode_send_buff_size_in_bytes_ and
> _internode_recv_buff_size_in_bytes_ to be changed to
> _internode_socket_send_buffer_size_in_bytes_ and
> _internode_socket_recv_buffer_size_in_bytes_ everywhere in the docs
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17135) Update docs for CASSANDRA-17132
[
https://issues.apache.org/jira/browse/CASSANDRA-17135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491184#comment-17491184
]
Erick Ramirez commented on CASSANDRA-17135:
---
[James Brown raised a good point on the
ML|https://lists.apache.org/thread/z5zmv284cxfm5ljr0fogqr2fxbc9kwlw] that we
can improve the visibility of the change. I'll include an update to NEWS.txt in
this ticket.
> Update docs for CASSANDRA-17132
> ---
>
> Key: CASSANDRA-17135
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17135
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Some cleaning of old parameters was done in CASSANDRA-17132.
> We need to update the docs respectively after the migration to ASCIIdoc is
> done:
> * Remove any references to {_}otc_backlog_expiration_interval_ms,
> otc_coalescing_strategy, otc_coalescing_window_us_default{_},
> _otc_coalescing_window_us,_ _otc_coalescing_enough_coalesced_messages,
> internode_application_timeout_in_ms._
> * The names of _internode_send_buff_size_in_bytes_ and
> _internode_recv_buff_size_in_bytes_ to be changed to
> _internode_socket_send_buffer_size_in_bytes_ and
> _internode_socket_recv_buffer_size_in_bytes_ everywhere in the docs
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17132) Fix startup issue with internode_application_timeout_in_ms
[
https://issues.apache.org/jira/browse/CASSANDRA-17132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491195#comment-17491195
]
Jeff Jirsa commented on CASSANDRA-17132:
This commit broke users upgrading from 4.0.1 to 4.0.2.
We should NOT be making breaking changes in minor versions.
We also missed the {{NEWS.txt}} entry that notifies customers of breaking
changes.
> Fix startup issue with internode_application_timeout_in_ms
> --
>
> Key: CASSANDRA-17132
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17132
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.2, 4.1
>
>
> While testing my patch for CASSANDRA-17131 I found that there is a problem
> with _internode_application_timeout_in_ms_ in 4.0 and trunk.
> Seems to me that we can just safely remove it for now?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17377) Revert CASSANDRA-17132 and instead deprecate the parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-17377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17377: Summary: Revert CASSANDRA-17132 and instead deprecate the parameters (was: Revert CASSANDRA-17132) > Revert CASSANDRA-17132 and instead deprecate the parameters > --- > > Key: CASSANDRA-17377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17377 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17377) Revert CASSANDRA-17132
Ekaterina Dimitrova created CASSANDRA-17377: --- Summary: Revert CASSANDRA-17132 Key: CASSANDRA-17377 URL: https://issues.apache.org/jira/browse/CASSANDRA-17377 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17377) Revert CASSANDRA-17132 and instead deprecate the parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-17377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17377: Fix Version/s: 4.0.x > Revert CASSANDRA-17132 and instead deprecate the parameters > --- > > Key: CASSANDRA-17377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17377 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17376) Restore missing properties from CASSANDRA-17132
Brandon Williams created CASSANDRA-17376: Summary: Restore missing properties from CASSANDRA-17132 Key: CASSANDRA-17376 URL: https://issues.apache.org/jira/browse/CASSANDRA-17376 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams CASSANDRA-17132 removed the coalescing properties that, while having been noops since 3.11, were not properly deprecated. This ticket is to restore those and deprecate them. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17377) Revert CASSANDRA-17132 and instead deprecate the parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-17377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17377: Bug Category: Parent values: Degradation(12984) Complexity: Low Hanging Fruit Component/s: Build Discovered By: User Report Severity: Low Assignee: Ekaterina Dimitrova Status: Open (was: Triage Needed) > Revert CASSANDRA-17132 and instead deprecate the parameters > --- > > Key: CASSANDRA-17377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17377 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17376) Restore missing properties from CASSANDRA-17132
[ https://issues.apache.org/jira/browse/CASSANDRA-17376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17376: - Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: Local/Config Discovered By: User Report Fix Version/s: 4.0.x Severity: Normal Status: Open (was: Triage Needed) > Restore missing properties from CASSANDRA-17132 > --- > > Key: CASSANDRA-17376 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17376 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > > CASSANDRA-17132 removed the coalescing properties that, while having been > noops since 3.11, were not properly deprecated. This ticket is to restore > those and deprecate them. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17376) Restore missing properties from CASSANDRA-17132
[ https://issues.apache.org/jira/browse/CASSANDRA-17376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17376: Resolution: Duplicate Status: Resolved (was: Open) > Restore missing properties from CASSANDRA-17132 > --- > > Key: CASSANDRA-17376 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17376 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > > CASSANDRA-17132 removed the coalescing properties that, while having been > noops since 3.11, were not properly deprecated. This ticket is to restore > those and deprecate them. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17377) Revert CASSANDRA-17132 and instead deprecate the parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-17377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17377: Description: Follow up on [https://lists.apache.org/thread/z5zmv284cxfm5ljr0fogqr2fxbc9kwlw] by revert and instead deprecate the parameters removed in CASSANDRA-17132. > Revert CASSANDRA-17132 and instead deprecate the parameters > --- > > Key: CASSANDRA-17377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17377 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x > > > Follow up on > [https://lists.apache.org/thread/z5zmv284cxfm5ljr0fogqr2fxbc9kwlw] > by revert and instead deprecate the parameters removed in CASSANDRA-17132. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17132) Fix startup issue with internode_application_timeout_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-17132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491213#comment-17491213 ] Ekaterina Dimitrova commented on CASSANDRA-17132: - CASSANDRA-17377 opened to fix this > Fix startup issue with internode_application_timeout_in_ms > -- > > Key: CASSANDRA-17132 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17132 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.2, 4.1 > > > While testing my patch for CASSANDRA-17131 I found that there is a problem > with _internode_application_timeout_in_ms_ in 4.0 and trunk. > Seems to me that we can just safely remove it for now? -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17135) Update docs for CASSANDRA-17132
[
https://issues.apache.org/jira/browse/CASSANDRA-17135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491216#comment-17491216
]
Ekaterina Dimitrova commented on CASSANDRA-17135:
-
Thank you [~flightc] , now when the docs are migrated we need also to make the
updates there too. That is why this ticket was raised initially, being part of
our docs backlog...
> Update docs for CASSANDRA-17132
> ---
>
> Key: CASSANDRA-17135
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17135
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Some cleaning of old parameters was done in CASSANDRA-17132.
> We need to update the docs respectively after the migration to ASCIIdoc is
> done:
> * Remove any references to {_}otc_backlog_expiration_interval_ms,
> otc_coalescing_strategy, otc_coalescing_window_us_default{_},
> _otc_coalescing_window_us,_ _otc_coalescing_enough_coalesced_messages,
> internode_application_timeout_in_ms._
> * The names of _internode_send_buff_size_in_bytes_ and
> _internode_recv_buff_size_in_bytes_ to be changed to
> _internode_socket_send_buffer_size_in_bytes_ and
> _internode_socket_recv_buffer_size_in_bytes_ everywhere in the docs
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17135) Update docs for CASSANDRA-17132
[
https://issues.apache.org/jira/browse/CASSANDRA-17135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17135:
Description:
Some cleaning of old parameters was done in CASSANDRA-17132.
We need to update the docs respectively after the migration to ASCIIdoc is done:
* -Remove any references to {_}otc_backlog_expiration_interval_ms,
otc_coalescing_strategy, otc_coalescing_window_us_default{_},
_otc_coalescing_window_us,_ _otc_coalescing_enough_coalesced_messages,
internode_application_timeout_in_ms._- _Inform the users about deprecation of
otc_backlog_expiration_interval_ms, otc_coalescing_strategy,
otc_coalescing_window_us_default, otc_coalescing_window_us,
otc_coalescing_enough_coalesced_messages._
_internode_application_timeout_in_ms - this one never existed internally so I
am not sure whether we need to add it now to Config.java... It was only a
commented property in cassandra.yaml that never got into the release_
* The names of _internode_send_buff_size_in_bytes_ and
_internode_recv_buff_size_in_bytes_ to be changed to
_internode_socket_send_buffer_size_in_bytes_ and
_internode_socket_recv_buffer_size_in_bytes_ everywhere in the docs
was:
Some cleaning of old parameters was done in CASSANDRA-17132.
We need to update the docs respectively after the migration to ASCIIdoc is done:
* Remove any references to {_}otc_backlog_expiration_interval_ms,
otc_coalescing_strategy, otc_coalescing_window_us_default{_},
_otc_coalescing_window_us,_ _otc_coalescing_enough_coalesced_messages,
internode_application_timeout_in_ms._
* The names of _internode_send_buff_size_in_bytes_ and
_internode_recv_buff_size_in_bytes_ to be changed to
_internode_socket_send_buffer_size_in_bytes_ and
_internode_socket_recv_buffer_size_in_bytes_ everywhere in the docs
> Update docs for CASSANDRA-17132
> ---
>
> Key: CASSANDRA-17135
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17135
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Some cleaning of old parameters was done in CASSANDRA-17132.
> We need to update the docs respectively after the migration to ASCIIdoc is
> done:
> * -Remove any references to {_}otc_backlog_expiration_interval_ms,
> otc_coalescing_strategy, otc_coalescing_window_us_default{_},
> _otc_coalescing_window_us,_ _otc_coalescing_enough_coalesced_messages,
> internode_application_timeout_in_ms._- _Inform the users about deprecation
> of otc_backlog_expiration_interval_ms, otc_coalescing_strategy,
> otc_coalescing_window_us_default, otc_coalescing_window_us,
> otc_coalescing_enough_coalesced_messages._
> _internode_application_timeout_in_ms - this one never existed internally so I
> am not sure whether we need to add it now to Config.java... It was only a
> commented property in cassandra.yaml that never got into the release_
> * The names of _internode_send_buff_size_in_bytes_ and
> _internode_recv_buff_size_in_bytes_ to be changed to
> _internode_socket_send_buffer_size_in_bytes_ and
> _internode_socket_recv_buffer_size_in_bytes_ everywhere in the docs
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17377) Revert CASSANDRA-17132 and instead deprecate the parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-17377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491219#comment-17491219 ] Ekaterina Dimitrova commented on CASSANDRA-17377: - Patch [here|https://github.com/ekaterinadimitrova2/cassandra/commit/4cc1d8d9c5b75780b38616519147c91ec32e25c4] [~jjirsa] , [~brandon.williams] , is this enough? ADOCS are already to be updated in CASSANDRA-17135. They will require more work in the other repo. I don't see a reason to delay this one in the meantime. > Revert CASSANDRA-17132 and instead deprecate the parameters > --- > > Key: CASSANDRA-17377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17377 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x > > > Follow up on > [https://lists.apache.org/thread/z5zmv284cxfm5ljr0fogqr2fxbc9kwlw] > by revert and instead deprecate the parameters removed in CASSANDRA-17132. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17377) Revert CASSANDRA-17132 and instead deprecate the parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-17377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491222#comment-17491222 ] Ekaterina Dimitrova commented on CASSANDRA-17377: - Disregard, I pushed wrong commit trying to be quick... I will test and push the right one... > Revert CASSANDRA-17132 and instead deprecate the parameters > --- > > Key: CASSANDRA-17377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17377 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x > > > Follow up on > [https://lists.apache.org/thread/z5zmv284cxfm5ljr0fogqr2fxbc9kwlw] > by revert and instead deprecate the parameters removed in CASSANDRA-17132. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17377) Revert CASSANDRA-17132 and instead deprecate the parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-17377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491228#comment-17491228 ] Ekaterina Dimitrova edited comment on CASSANDRA-17377 at 2/12/22, 1:26 AM: --- So in CASSANDRA-17132 I removed from cassandra.yaml otc_backlog_expiration_interval_ms which I found It removed from Config class as part of CASSANDRA-15066 (the rewrite of the internode messaging subsystem). I guess it is just a good luck no one complained of missing it before. I didn't manage to identify NEWS.txt or CHANGES.txt entries for it so I added it back as deprecated in Config.java now, even if it wasn't removed by me. As a placeholder as the others just for clarity and to be on the safe side. Patch [here|https://github.com/ekaterinadimitrova2/cassandra/commit/a0f6b89127c1955a422dec922fb2624b4dbffd84] was (Author: e.dimitrova): So in CASSANDRA-17132 I removed from cassandra.yaml otc_backlog_expiration_interval_ms which I found It removed from Config class as part of CASSANDRA-15066 (the rewrite of the internode messaging subsystem). I guess it is just a good luck no one complained of missing it before. I didn't manage to identify NEWS.txt or CHANGES.txt entries for it so I added it back as deprecated in Config.java now, even if it wasn't removed by me. As a placeholder as the others just for clarity. Patch [here|https://github.com/ekaterinadimitrova2/cassandra/commit/a0f6b89127c1955a422dec922fb2624b4dbffd84] > Revert CASSANDRA-17132 and instead deprecate the parameters > --- > > Key: CASSANDRA-17377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17377 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x > > > Follow up on > [https://lists.apache.org/thread/z5zmv284cxfm5ljr0fogqr2fxbc9kwlw] > by revert and instead deprecate the parameters removed in CASSANDRA-17132. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17377) Revert CASSANDRA-17132 and instead deprecate the parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-17377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491228#comment-17491228 ] Ekaterina Dimitrova commented on CASSANDRA-17377: - So in CASSANDRA-17132 I removed from cassandra.yaml otc_backlog_expiration_interval_ms which I found It removed from Config class as part of CASSANDRA-15066 (the rewrite of the internode messaging subsystem). I guess it is just a good luck no one complained of missing it before. I didn't manage to identify NEWS.txt or CHANGES.txt entries for it so I added it back as deprecated in Config.java now, even if it wasn't removed by me. As a placeholder as the others just for clarity. Patch [here|https://github.com/ekaterinadimitrova2/cassandra/commit/a0f6b89127c1955a422dec922fb2624b4dbffd84] > Revert CASSANDRA-17132 and instead deprecate the parameters > --- > > Key: CASSANDRA-17377 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17377 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x > > > Follow up on > [https://lists.apache.org/thread/z5zmv284cxfm5ljr0fogqr2fxbc9kwlw] > by revert and instead deprecate the parameters removed in CASSANDRA-17132. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
