[jira] [Commented] (CASSANDRA-18148) netty-all vulnerability: CVE-2022-41881
[ https://issues.apache.org/jira/browse/CASSANDRA-18148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676508#comment-17676508 ] Norman Maurer commented on CASSANDRA-18148: --- Your assumption is correct... Cassandra is not affected as it not use the decoder in question > netty-all vulnerability: CVE-2022-41881 > --- > > Key: CASSANDRA-18148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18148 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This is showing in the OWASP scan. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676470#comment-17676470
]
Berenguer Blasi edited comment on CASSANDRA-18032 at 1/13/23 6:09 AM:
--
Ah that's not nice. I tested a few things manually but not this one. New PRs:
- [3.0|https://github.com/apache/cassandra/pull/2089]
- [3.11|https://github.com/apache/cassandra/pull/2090]
- [4.0|https://github.com/apache/cassandra/pull/2091]
- [4.1|https://github.com/apache/cassandra/pull/2092]
- [trunk|https://github.com/apache/cassandra/pull/2093]
I tested manually you can set an env var on all branches. Thx [~adelapena] for
the suggested fix.
was (Author: bereng):
Ah that's not nice. I tested a few things manually but not this one. New PRs:
- [3.0|https://github.com/apache/cassandra/pull/2089]
- [3.11|https://github.com/apache/cassandra/pull/2090]
- [4.0|https://github.com/apache/cassandra/pull/2091]
- [4.1|https://github.com/apache/cassandra/pull/2092]
- [trunk|https://github.com/apache/cassandra/pull/2093]
I tested manually you can set an env var on all branches.
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18032:
Status: Patch Available (was: Open)
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676470#comment-17676470
]
Berenguer Blasi commented on CASSANDRA-18032:
-
Ah that's not nice. I tested a few things manually but not this one. New PRs:
- [3.0|https://github.com/apache/cassandra/pull/2089]
- [3.11|https://github.com/apache/cassandra/pull/2090]
- [4.0|https://github.com/apache/cassandra/pull/2091]
- [4.1|https://github.com/apache/cassandra/pull/2092]
- [trunk|https://github.com/apache/cassandra/pull/2093]
I tested manually you can set an env var on all branches.
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (2eca5bb2 -> 14c7d9fc)
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 2eca5bb2 generate docs for b072ce0a new 14c7d9fc generate docs for b072ce0a 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 (2eca5bb2) \ N -- N -- N refs/heads/asf-staging (14c7d9fc) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970898 -> 4970898 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (5178cffb -> 2eca5bb2)
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 5178cffb generate docs for b072ce0a new 2eca5bb2 generate docs for b072ce0a 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 (5178cffb) \ N -- N -- N refs/heads/asf-staging (2eca5bb2) 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 4970898 -> 4970898 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-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676406#comment-17676406
]
Paulo Motta commented on CASSANDRA-14013:
-
Resubmitted 4.1 CI on
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2187/
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (f8d36a99 -> 5178cffb)
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 f8d36a99 generate docs for b072ce0a new 5178cffb generate docs for b072ce0a 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 (f8d36a99) \ N -- N -- N refs/heads/asf-staging (5178cffb) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970898 -> 4970898 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18151) org.apache.cassandra.distributed.test.SchemaTest timeout
[ https://issues.apache.org/jira/browse/CASSANDRA-18151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676386#comment-17676386 ] Brandon Williams commented on CASSANDRA-18151: -- Also [here|https://app.circleci.com/pipelines/github/driftx/cassandra/765/workflows/5baddcd1-fa80-4d87-aa7c-07cfe82627e9/jobs/9681]. > org.apache.cassandra.distributed.test.SchemaTest timeout > > > Key: CASSANDRA-18151 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18151 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.2 > > > See here for another timeout of this test > https://app.circleci.com/pipelines/github/bereng/cassandra/836/workflows/dd9f0441-df59-40e7-b00b-c0788f0235a6/jobs/7597/tests#failed-test-0 > It is unclear if it's an env issue or related to CASSANDRA-17819 or similar > ones as this test has some history to it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18146) commons-cli vulnerability: CVE-2021-37533
[ https://issues.apache.org/jira/browse/CASSANDRA-18146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676363#comment-17676363 ] Brandon Williams commented on CASSANDRA-18146: -- [This|https://app.circleci.com/pipelines/github/driftx/cassandra/768/workflows/d411c6a2-0536-42f8-bd28-751d2fe70181] is the correct 4.1 j11 link. > commons-cli vulnerability: CVE-2021-37533 > - > > Key: CASSANDRA-18146 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18146 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This CVE is being reported by the OWASP scan for: > commons-cli-1.1.jar: CVE-2021-37533 > commons-codec-1.9.jar: CVE-2021-37533 > commons-math3-3.2.jar: CVE-2021-37533 > additionally commons-lang3-3.1.jar is also reported on 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18146) commons-cli vulnerability: CVE-2021-37533
[ https://issues.apache.org/jira/browse/CASSANDRA-18146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676361#comment-17676361 ] Brandon Williams commented on CASSANDRA-18146: -- ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/766/workflows/67258c54-3a86-45d8-bbed-c2e6804bb299]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/764/workflows/afe9a03c-b1d2-49ec-92ff-298fd080be12]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/767/workflows/27d9948e-efe3-4534-94c7-f14b3e2c95cd], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/767/workflows/478662cf-6f37-4a9d-b72d-8480ed69d696]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/768/workflows/896e3f91-9872-4064-b0ff-c7fe0b072deb], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/767/workflows/478662cf-6f37-4a9d-b72d-8480ed69d696]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/765/workflows/48bb0afd-f8ae-4f09-ad09-d96a2cb93561], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/765/workflows/5baddcd1-fa80-4d87-aa7c-07cfe82627e9]| > commons-cli vulnerability: CVE-2021-37533 > - > > Key: CASSANDRA-18146 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18146 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This CVE is being reported by the OWASP scan for: > commons-cli-1.1.jar: CVE-2021-37533 > commons-codec-1.9.jar: CVE-2021-37533 > commons-math3-3.2.jar: CVE-2021-37533 > additionally commons-lang3-3.1.jar is also reported on 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16895: Summary: Build with Java 17 (was: Build Java 17) > Build with Java 17 > -- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Epic > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > This ticket is intended to group all issues found to support Java 17 in the > future. > Upgrade steps: > * [Dependencies > |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to > be updated (not all but at least those that require an update in order to > work with Java 17) > * More encapsulated JDK internal APIs. Some of the issues might be solved > with the dependencies updates > * Currently trunk compiles if we remove the Nashorn dependency (ant script > tag, used for the test environment; UDFs) . The oracle recommendation to use > Nashorn-core won't work for the project as it is under GPL 2.0. Most probably > we will opt in for graal-sdk licensed under UPL > * All tests to be cleaned > * CI environment to be setup > *NOTE:* GC tuning, performance testing were never agreed to be part of this > ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16895) Build Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16895: Summary: Build Java 17 (was: Support Java 17) > Build Java 17 > - > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Epic > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > This ticket is intended to group all issues found to support Java 17 in the > future. > Upgrade steps: > * [Dependencies > |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to > be updated (not all but at least those that require an update in order to > work with Java 17) > * More encapsulated JDK internal APIs. Some of the issues might be solved > with the dependencies updates > * Currently trunk compiles if we remove the Nashorn dependency (ant script > tag, used for the test environment; UDFs) . The oracle recommendation to use > Nashorn-core won't work for the project as it is under GPL 2.0. Most probably > we will opt in for graal-sdk licensed under UPL > * All tests to be cleaned > * CI environment to be setup > *NOTE:* GC tuning, performance testing were never agreed to be part of this > ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-18146) commons-cli vulnerability: CVE-2021-37533
[ https://issues.apache.org/jira/browse/CASSANDRA-18146 ] Brandon Williams deleted comment on CASSANDRA-18146: -- was (Author: brandon.williams): The 4.0 j11 link above should be [this|https://app.circleci.com/pipelines/github/driftx/cassandra/762/workflows/c0c683f5-d0f3-47b9-81a1-b05f8a63abc5] instead but editing that comment makes jira angry with me. > commons-cli vulnerability: CVE-2021-37533 > - > > Key: CASSANDRA-18146 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18146 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This CVE is being reported by the OWASP scan for: > commons-cli-1.1.jar: CVE-2021-37533 > commons-codec-1.9.jar: CVE-2021-37533 > commons-math3-3.2.jar: CVE-2021-37533 > additionally commons-lang3-3.1.jar is also reported on 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-18146) commons-cli vulnerability: CVE-2021-37533
[ https://issues.apache.org/jira/browse/CASSANDRA-18146 ] Brandon Williams deleted comment on CASSANDRA-18146: -- was (Author: brandon.williams): Patches to suppress. ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/761/workflows/3bab9a0d-22c2-4383-af47-7c795f270341]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/759/workflows/592aab33-153e-41ba-9bb4-f3a1f3846538]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/762/workflows/bd2fa3ca-8e02-4910-9cab-39f71b3b1bd9], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/760/workflows/205a2d88-e28a-48c2-a5ad-1b281a5cf963]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/763/workflows/68abb0f7-d583-447d-ba82-c85beb769c35], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/763/workflows/bd663f65-d0aa-479e-837a-e238480eba31]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/760/workflows/18ee3008-8517-4ca2-b1d4-d1ab99683093], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/760/workflows/205a2d88-e28a-48c2-a5ad-1b281a5cf963]| > commons-cli vulnerability: CVE-2021-37533 > - > > Key: CASSANDRA-18146 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18146 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This CVE is being reported by the OWASP scan for: > commons-cli-1.1.jar: CVE-2021-37533 > commons-codec-1.9.jar: CVE-2021-37533 > commons-math3-3.2.jar: CVE-2021-37533 > additionally commons-lang3-3.1.jar is also reported on 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676358#comment-17676358 ] Ekaterina Dimitrova commented on CASSANDRA-18121: - The patch files need update so generate.sh -m can change the new jobs to use Large containers. Confirmed to work in offline discussion > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18154) CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows
[ https://issues.apache.org/jira/browse/CASSANDRA-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18154: -- Source Control Link: https://github.com/apache/cassandra/commit/46d10778da6d1a76454ff7bb404c232bcd7255ae Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN > clauses to return multiple partitions/rows > - > > Key: CASSANDRA-18154 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18154 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > Time Spent: 50m > Remaining Estimate: 0h > > There are many cases where the user wants to be able to return multiple > partitions in one result, this exists today using IN clause to return for a > single table; we should support this in Accord. > This work is not to include multiple partitions from different tables as that > would require client integration (different schemas). This work is also not > to allow multiple SELECT statements, just to only rely on the IN clause. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cep-15-accord updated: CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch cep-15-accord
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cep-15-accord by this push:
new 46d10778da CEP-15: (C*) Enhance returning SELECT to allow partition
and clustering IN clauses to return multiple partitions/rows
46d10778da is described below
commit 46d10778da6d1a76454ff7bb404c232bcd7255ae
Author: David Capwell
AuthorDate: Thu Jan 12 14:24:32 2023 -0800
CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN
clauses to return multiple partitions/rows
patch by David Capwell; reviewed by Caleb Rackliffe for CASSANDRA-18154
---
.../cql3/statements/TransactionStatement.java | 43 +++--
.../cassandra/service/accord/txn/TxnDataName.java | 5 ++
.../distributed/test/accord/AccordCQLTest.java | 56 ++
3 files changed, 99 insertions(+), 5 deletions(-)
diff --git
a/src/java/org/apache/cassandra/cql3/statements/TransactionStatement.java
b/src/java/org/apache/cassandra/cql3/statements/TransactionStatement.java
index 4d3c732da0..e4893154b2 100644
--- a/src/java/org/apache/cassandra/cql3/statements/TransactionStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/TransactionStatement.java
@@ -182,6 +182,24 @@ public class TransactionStatement implements CQLStatement
return new TxnNamedRead(namedSelect.name,
Iterables.getOnlyElement(selectQuery.queries));
}
+List createNamedReads(NamedSelect namedSelect, QueryOptions
options)
+{
+SelectStatement select = namedSelect.select;
+ReadQuery readQuery = select.getQuery(options, 0);
+
+// We reject reads from both LET and SELECT that do not specify a
single row.
+@SuppressWarnings("unchecked")
+SinglePartitionReadQuery.Group selectQuery
= (SinglePartitionReadQuery.Group) readQuery;
+
+if (selectQuery.queries.size() == 1)
+return Collections.singletonList(new
TxnNamedRead(namedSelect.name, Iterables.getOnlyElement(selectQuery.queries)));
+
+List list = new ArrayList<>(selectQuery.queries.size());
+for (int i = 0; i < selectQuery.queries.size(); i++)
+list.add(new TxnNamedRead(TxnDataName.returning(i),
selectQuery.queries.get(i)));
+return list;
+}
+
private List createNamedReads(QueryOptions options,
Consumer keyConsumer)
{
List reads = new ArrayList<>(assignments.size() + 1);
@@ -195,9 +213,11 @@ public class TransactionStatement implements CQLStatement
if (returningSelect != null)
{
-TxnNamedRead read = createNamedRead(returningSelect, options);
-keyConsumer.accept(read.key());
-reads.add(read);
+for (TxnNamedRead read : createNamedReads(returningSelect,
options))
+{
+keyConsumer.accept(read.key());
+reads.add(read);
+}
}
for (NamedSelect select : autoReads.values())
@@ -314,10 +334,23 @@ public class TransactionStatement implements CQLStatement
if (returningSelect != null)
{
-FilteredPartition partition =
data.get(TxnDataName.returning());
+SinglePartitionReadQuery.Group
selectQuery = (SinglePartitionReadQuery.Group)
returningSelect.select.getQuery(options, 0);
Selection.Selectors selectors =
returningSelect.select.getSelection().newSelectors(options);
ResultSetBuilder result = new
ResultSetBuilder(returningSelect.select.getResultMetadata(), selectors, null);
-
returningSelect.select.processPartition(partition.rowIterator(), options,
result, FBUtilities.nowInSeconds());
+if (selectQuery.queries.size() == 1)
+{
+FilteredPartition partition =
data.get(TxnDataName.returning());
+
returningSelect.select.processPartition(partition.rowIterator(), options,
result, FBUtilities.nowInSeconds());
+}
+else
+{
+int nowInSec = FBUtilities.nowInSeconds();
+for (int i = 0; i < selectQuery.queries.size(); i++)
+{
+FilteredPartition partition =
data.get(TxnDataName.returning(i));
+
returningSelect.select.processPartition(partition.rowIterator(), options,
result, nowInSec);
+}
+}
return new ResultMessage.Rows(result.build());
}
diff --git a/src/java/org/apache/cassandra/service/accord/txn/TxnDataName.java
b/src/java/org/apache/cassandra/service/accord/txn/TxnDataName.java
index 65b659747f..de672cad2e 100644
--- a/src/java/org/apache/cassandra/service/accord/txn/TxnDataName.java
+++
[jira] [Updated] (CASSANDRA-18114) Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
[
https://issues.apache.org/jira/browse/CASSANDRA-18114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18114:
Source Control Link:
https://github.com/apache/cassandra/commit/530bc10bd0a053f5dcd8439fd3f5c72cd7952ea6
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks for the review!
> Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
> ---
>
> Key: CASSANDRA-18114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18114
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{CollectionSerializer}} and its subclasses have completely ignored
> {{ProtocolVersion}} for a very long time. It’s possible we may need to
> version their behavior in the future, but there’s no reason to keep the dead
> code in the meantime, as it causes confusion around whether code that uses
> these classes needs to provide a version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676352#comment-17676352 ] Brandon Williams edited comment on CASSANDRA-18121 at 1/12/23 9:57 PM: --- [This|https://app.circleci.com/pipelines/github/driftx/cassandra/763/workflows/68abb0f7-d583-447d-ba82-c85beb769c35] is interesting, the same failures on a completely unrelated ticket with absolutely no code changes. The [j8|https://app.circleci.com/pipelines/github/driftx/cassandra/763/workflows/68abb0f7-d583-447d-ba82-c85beb769c35] run failed the same way too. was (Author: brandon.williams): [This|https://app.circleci.com/pipelines/github/driftx/cassandra/763/workflows/68abb0f7-d583-447d-ba82-c85beb769c35] is intersting, the same failures on a completely unrelated ticket with absolutely no code changes. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
This is an automated email from the ASF dual-hosted git repository.
maedhroz 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 530bc10bd0 Remove ProtocolVersion entirely from the
CollectionSerializer ecosystem
530bc10bd0 is described below
commit 530bc10bd0a053f5dcd8439fd3f5c72cd7952ea6
Author: Caleb Rackliffe
AuthorDate: Wed Jan 11 13:04:06 2023 -0600
Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
patch by Caleb Rackliffe; reviewed by David Capwell for CASSANDRA-18114
---
CHANGES.txt| 1 +
src/java/org/apache/cassandra/cql3/CQL3Type.java | 44 ++---
src/java/org/apache/cassandra/cql3/Constants.java | 2 +-
src/java/org/apache/cassandra/cql3/Lists.java | 26
src/java/org/apache/cassandra/cql3/Maps.java | 41
src/java/org/apache/cassandra/cql3/Sets.java | 44 -
src/java/org/apache/cassandra/cql3/Term.java | 3 +-
src/java/org/apache/cassandra/cql3/Terms.java | 6 +-
src/java/org/apache/cassandra/cql3/Tuples.java | 32 +
.../apache/cassandra/cql3/UntypedResultSet.java| 31 +
src/java/org/apache/cassandra/cql3/UserTypes.java | 2 +-
.../cassandra/cql3/functions/CollectionFcts.java | 2 +-
.../cassandra/cql3/functions/FunctionCall.java | 8 +--
.../cql3/restrictions/MultiColumnRestriction.java | 28 +---
.../cql3/restrictions/SingleColumnRestriction.java | 3 +-
.../cassandra/cql3/selection/ColumnTimestamps.java | 2 +-
.../cassandra/cql3/selection/ListSelector.java | 2 +-
.../cassandra/cql3/selection/MapSelector.java | 2 +-
.../apache/cassandra/cql3/selection/Selector.java | 2 +-
.../cassandra/cql3/selection/SetSelector.java | 2 +-
.../cassandra/db/marshal/CollectionType.java | 48 +++---
.../org/apache/cassandra/db/marshal/ListType.java | 10 +--
.../org/apache/cassandra/db/marshal/MapType.java | 73 +++--
.../org/apache/cassandra/db/marshal/SetType.java | 10 +--
.../org/apache/cassandra/db/marshal/TupleType.java | 6 +-
.../serializers/AbstractMapSerializer.java | 31 +
.../serializers/CollectionSerializer.java | 76 +++---
.../cassandra/serializers/ListSerializer.java | 37 ++-
.../cassandra/serializers/MapSerializer.java | 56 +---
.../cassandra/serializers/SetSerializer.java | 40 +++-
.../apache/cassandra/cql3/CQL3TypeLiteralTest.java | 2 +-
.../apache/cassandra/transport/SerDeserTest.java | 70
32 files changed, 394 insertions(+), 348 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index b1bc6f0cc9..a3eb241153 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
(CASSANDRA-18114)
* Fix serialization error in new getsstables --show-levels option
(CASSANDRA-18140)
* Use checked casts when reading vints as ints (CASSANDRA-18099)
* Add Mutation Serialization Caching (CASSANDRA-17998)
diff --git a/src/java/org/apache/cassandra/cql3/CQL3Type.java
b/src/java/org/apache/cassandra/cql3/CQL3Type.java
index 1c20e6b0ff..6c9bd41839 100644
--- a/src/java/org/apache/cassandra/cql3/CQL3Type.java
+++ b/src/java/org/apache/cassandra/cql3/CQL3Type.java
@@ -24,13 +24,13 @@ import java.util.List;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
-import org.apache.cassandra.schema.Schema;
import org.apache.cassandra.db.marshal.*;
import org.apache.cassandra.db.marshal.CollectionType.Kind;
import org.apache.cassandra.exceptions.InvalidRequestException;
import org.apache.cassandra.exceptions.ConfigurationException;
import org.apache.cassandra.exceptions.SyntaxException;
import org.apache.cassandra.schema.KeyspaceMetadata;
+import org.apache.cassandra.schema.Schema;
import org.apache.cassandra.schema.Types;
import org.apache.cassandra.serializers.CollectionSerializer;
import org.apache.cassandra.serializers.MarshalException;
@@ -54,7 +54,6 @@ public interface CQL3Type
}
public AbstractType getType();
-default public AbstractType getUDFType() { return getType(); }
/**
* Generates CQL literal from a binary value of this type.
@@ -101,11 +100,6 @@ public interface CQL3Type
return type;
}
-public AbstractType getUDFType()
-{
-return this == TIMEUUID ? UUID.type : type;
-}
-
/**
* Delegate to
* {@link
org.apache.cassandra.serializers.TypeSerializer#toCQLLiteral(ByteBuffer)}
@@ -176,9 +170,9 @@ public interface CQL3Type
public static class Collection implements CQL3Type
{
-private final CollectionType type;
+private final CollectionType type;
-public
[jira] [Commented] (CASSANDRA-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676352#comment-17676352 ] Brandon Williams commented on CASSANDRA-18121: -- [This|https://app.circleci.com/pipelines/github/driftx/cassandra/763/workflows/68abb0f7-d583-447d-ba82-c85beb769c35] is intersting, the same failures on a completely unrelated ticket with absolutely no code changes. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18146) commons-cli vulnerability: CVE-2021-37533
[ https://issues.apache.org/jira/browse/CASSANDRA-18146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676351#comment-17676351 ] Brandon Williams commented on CASSANDRA-18146: -- The 4.0 j11 link above should be [this|https://app.circleci.com/pipelines/github/driftx/cassandra/762/workflows/c0c683f5-d0f3-47b9-81a1-b05f8a63abc5] instead but editing that comment makes jira angry with me. > commons-cli vulnerability: CVE-2021-37533 > - > > Key: CASSANDRA-18146 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18146 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This CVE is being reported by the OWASP scan for: > commons-cli-1.1.jar: CVE-2021-37533 > commons-codec-1.9.jar: CVE-2021-37533 > commons-math3-3.2.jar: CVE-2021-37533 > additionally commons-lang3-3.1.jar is also reported on 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17869:
Status: Review In Progress (was: Patch Available)
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18150) Prefer snakeyaml's SafeConstructor over Constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676292#comment-17676292 ] Brandon Williams edited comment on CASSANDRA-18150 at 1/12/23 9:47 PM: --- I've posted patches above w/CI, so it's already done and ready for review. was (Author: brandon.williams): I've posted patches above w/CI, so it's already done and ready for review. > Prefer snakeyaml's SafeConstructor over Constructor > --- > > Key: CASSANDRA-18150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > CVE-2022-1471 allows RCE through the Constructor class. While this isn't a > concern since yaml is only used for configuration, it is simple enough to > switch to SafeConstructor and harden the server a little more. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18150) Prefer snakeyaml's SafeConstructor over Constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676292#comment-17676292 ] Brandon Williams edited comment on CASSANDRA-18150 at 1/12/23 9:47 PM: --- I've posted patches above w/CI, so it's already done and ready for review. was (Author: brandon.williams): I've posted patches above w/CI, so it's already done and ready for review. > Prefer snakeyaml's SafeConstructor over Constructor > --- > > Key: CASSANDRA-18150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > CVE-2022-1471 allows RCE through the Constructor class. While this isn't a > concern since yaml is only used for configuration, it is simple enough to > switch to SafeConstructor and harden the server a little more. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18114) Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
[
https://issues.apache.org/jira/browse/CASSANDRA-18114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18114:
Status: Ready to Commit (was: Review In Progress)
> Remove ProtocolVersion entirely from the CollectionSerializer ecosystem
> ---
>
> Key: CASSANDRA-18114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18114
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CollectionSerializer}} and its subclasses have completely ignored
> {{ProtocolVersion}} for a very long time. It’s possible we may need to
> version their behavior in the future, but there’s no reason to keep the dead
> code in the meantime, as it causes confusion around whether code that uses
> these classes needs to provide a version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18154) CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows
[ https://issues.apache.org/jira/browse/CASSANDRA-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18154: -- Status: Ready to Commit (was: Review In Progress) Caleb +1ed in GH > CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN > clauses to return multiple partitions/rows > - > > Key: CASSANDRA-18154 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18154 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > Time Spent: 40m > Remaining Estimate: 0h > > There are many cases where the user wants to be able to return multiple > partitions in one result, this exists today using IN clause to return for a > single table; we should support this in Accord. > This work is not to include multiple partitions from different tables as that > would require client integration (different schemas). This work is also not > to allow multiple SELECT statements, just to only rely on the IN clause. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18154) CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows
[ https://issues.apache.org/jira/browse/CASSANDRA-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18154: Fix Version/s: NA (was: 4.x) > CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN > clauses to return multiple partitions/rows > - > > Key: CASSANDRA-18154 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18154 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > Time Spent: 40m > Remaining Estimate: 0h > > There are many cases where the user wants to be able to return multiple > partitions in one result, this exists today using IN clause to return for a > single table; we should support this in Accord. > This work is not to include multiple partitions from different tables as that > would require client integration (different schemas). This work is also not > to allow multiple SELECT statements, just to only rely on the IN clause. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18154) CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows
[ https://issues.apache.org/jira/browse/CASSANDRA-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676339#comment-17676339 ] Caleb Rackliffe commented on CASSANDRA-18154: - +1 > CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN > clauses to return multiple partitions/rows > - > > Key: CASSANDRA-18154 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18154 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > There are many cases where the user wants to be able to return multiple > partitions in one result, this exists today using IN clause to return for a > single table; we should support this in Accord. > This work is not to include multiple partitions from different tables as that > would require client integration (different schemas). This work is also not > to allow multiple SELECT statements, just to only rely on the IN clause. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18125) AssertionError on thread MemtableReclaimMemory in MemtablePool$SubPool.released(MemtablePool.java:193)
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676336#comment-17676336
]
Benedict Elliott Smith commented on CASSANDRA-18125:
Are you able to (privately) share detailed logs and schema information, so we
can perhaps ascertain some information about the workload that might have
triggered this problem?
The exception you mention is very unlikely to be related, though it does
suggest this is all happening on startup?
> AssertionError on thread MemtableReclaimMemory in
> MemtablePool$SubPool.released(MemtablePool.java:193)
> --
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
>Reporter: Nicolas Henneaux
>Priority: Normal
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (4786a7b3 -> f8d36a99)
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 4786a7b3 generate docs for b072ce0a new f8d36a99 generate docs for b072ce0a 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 (4786a7b3) \ N -- N -- N refs/heads/asf-staging (f8d36a99) 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 4970898 -> 4970898 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] [Updated] (CASSANDRA-18154) CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows
[ https://issues.apache.org/jira/browse/CASSANDRA-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18154: Reviewers: Caleb Rackliffe Status: Review In Progress (was: Patch Available) > CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN > clauses to return multiple partitions/rows > - > > Key: CASSANDRA-18154 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18154 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > There are many cases where the user wants to be able to return multiple > partitions in one result, this exists today using IN clause to return for a > single table; we should support this in Accord. > This work is not to include multiple partitions from different tables as that > would require client integration (different schemas). This work is also not > to allow multiple SELECT statements, just to only rely on the IN clause. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18154) CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows
[ https://issues.apache.org/jira/browse/CASSANDRA-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18154: -- Summary: CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows (was: CEP-15: Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows) > CEP-15: (C*) Enhance returning SELECT to allow partition and clustering IN > clauses to return multiple partitions/rows > - > > Key: CASSANDRA-18154 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18154 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > There are many cases where the user wants to be able to return multiple > partitions in one result, this exists today using IN clause to return for a > single table; we should support this in Accord. > This work is not to include multiple partitions from different tables as that > would require client integration (different schemas). This work is also not > to allow multiple SELECT statements, just to only rely on the IN clause. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17112) CEP-15: (C*) Strict Serializability verification
[ https://issues.apache.org/jira/browse/CASSANDRA-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17112: -- Status: Changes Suggested (was: Review In Progress) > CEP-15: (C*) Strict Serializability verification > > > Key: CASSANDRA-17112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17112 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17112) CEP-15: (C*) Strict Serializability verification
[ https://issues.apache.org/jira/browse/CASSANDRA-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17112: -- Reviewers: Benedict Elliott Smith Status: Review In Progress (was: Patch Available) > CEP-15: (C*) Strict Serializability verification > > > Key: CASSANDRA-17112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17112 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17112) CEP-15: (C*) Strict Serializability verification
[ https://issues.apache.org/jira/browse/CASSANDRA-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676322#comment-17676322 ] David Capwell commented on CASSANDRA-17112: --- Created CASSANDRA-18154 based off the feedback we should do CQL and not bypass the CQL layer to get access to rows... So CASSANDRA-18154 is needed to support returning multiple partitions, which was the major motivation behind bypassing CQL layer. > CEP-15: (C*) Strict Serializability verification > > > Key: CASSANDRA-17112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17112 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676316#comment-17676316
]
Adriano Bonacin edited comment on CASSANDRA-18153 at 1/12/23 8:09 PM:
--
Storage service is not yet initiated during CommitLogReplay and
MetadataCollection calls StorageService.instance.getLocalHostUUID.
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java#L127]
{{public MetadataCollector(ClusteringComparator comparator)}}
{{ {}}
{{ this(comparator, StorageService.instance.getLocalHostUUID());}}
{{ }}}
StorageService.instance.getLocalHostUUID() will return null and all Memtables
will be flushed without this information.
Next time cassandra starts and these SStables are present, this test will fail
because originatingHostId is null:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L337]
{{ UUID originatingHostId =
reader.getSSTableMetadata().originatingHostId;}}
{{ if (originatingHostId != null &&
originatingHostId.equals(localhostId))}}
{{
builder.addAll(reader.getSSTableMetadata().commitLogIntervals);}}
{{ else}}
{{ skippedSSTables.add(reader.getFilename());}}
I thought of implementing it using same strategy as CommitLog.java
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L211]
{{
Optional.ofNullable(StorageService.instance.getLocalHostUUID()).orElseGet(SystemKeyspace::getLocalHostId);}}
was (Author: JIRAUSER294901):
Storage service is not yet initiated during CommitLogReplay and
MetadataCollection calls StorageService.instance.getLocalHostUUID.
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java#L127]
StorageService.instance.getLocalHostUUID() will return null and all Memtables
will be flushed without this information.
Next time cassandra starts and these SStables are present, this test will fail
because originatingHostId is null:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L337]
{{ UUID originatingHostId =
reader.getSSTableMetadata().originatingHostId;}}
{{ if (originatingHostId != null &&
originatingHostId.equals(localhostId))}}
{{
builder.addAll(reader.getSSTableMetadata().commitLogIntervals);}}
{{ else}}
{{ skippedSSTables.add(reader.getFilename());}}
I thought of implementing it using same strategy as CommitLog.java
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L211]
{{
Optional.ofNullable(StorageService.instance.getLocalHostUUID()).orElseGet(SystemKeyspace::getLocalHostId);}}
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18154) CEP-15: Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows
[ https://issues.apache.org/jira/browse/CASSANDRA-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18154: -- Change Category: Semantic Complexity: Low Hanging Fruit Fix Version/s: 4.x Assignee: David Capwell Status: Open (was: Triage Needed) > CEP-15: Enhance returning SELECT to allow partition and clustering IN clauses > to return multiple partitions/rows > > > Key: CASSANDRA-18154 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18154 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > There are many cases where the user wants to be able to return multiple > partitions in one result, this exists today using IN clause to return for a > single table; we should support this in Accord. > This work is not to include multiple partitions from different tables as that > would require client integration (different schemas). This work is also not > to allow multiple SELECT statements, just to only rely on the IN clause. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18154) CEP-15: Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows
[ https://issues.apache.org/jira/browse/CASSANDRA-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18154: -- Test and Documentation Plan: new tests Status: Patch Available (was: Open) > CEP-15: Enhance returning SELECT to allow partition and clustering IN clauses > to return multiple partitions/rows > > > Key: CASSANDRA-18154 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18154 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > There are many cases where the user wants to be able to return multiple > partitions in one result, this exists today using IN clause to return for a > single table; we should support this in Accord. > This work is not to include multiple partitions from different tables as that > would require client integration (different schemas). This work is also not > to allow multiple SELECT statements, just to only rely on the IN clause. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18154) CEP-15: Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows
David Capwell created CASSANDRA-18154: - Summary: CEP-15: Enhance returning SELECT to allow partition and clustering IN clauses to return multiple partitions/rows Key: CASSANDRA-18154 URL: https://issues.apache.org/jira/browse/CASSANDRA-18154 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: David Capwell There are many cases where the user wants to be able to return multiple partitions in one result, this exists today using IN clause to return for a single table; we should support this in Accord. This work is not to include multiple partitions from different tables as that would require client integration (different schemas). This work is also not to allow multiple SELECT statements, just to only rely on the IN clause. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676316#comment-17676316
]
Adriano Bonacin commented on CASSANDRA-18153:
-
Storage service is not yet initiated during CommitLogReplay and
MetadataCollection calls StorageService.instance.getLocalHostUUID.
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java#L127]
StorageService.instance.getLocalHostUUID() will return null and all Memtables
will be flushed without this information.
Next time cassandra starts and these SStables are present, this test will fail
because originatingHostId is null:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L337]
{{ UUID originatingHostId =
reader.getSSTableMetadata().originatingHostId;}}
{{ if (originatingHostId != null &&
originatingHostId.equals(localhostId))}}
{{
builder.addAll(reader.getSSTableMetadata().commitLogIntervals);}}
{{ else}}
{{ skippedSSTables.add(reader.getFilename());}}
I thought of implementing it using same strategy as CommitLog.java
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L211]
{{
Optional.ofNullable(StorageService.instance.getLocalHostUUID()).orElseGet(SystemKeyspace::getLocalHostId);}}
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676307#comment-17676307
]
Ekaterina Dimitrova commented on CASSANDRA-18153:
-
CC [~jlewandowski]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
Adriano Bonacin created CASSANDRA-18153:
---
Summary: Memtable being flushed without hostId in version "me" and
newer during CommitLogReplay
Key: CASSANDRA-18153
URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
Project: Cassandra
Issue Type: Bug
Reporter: Adriano Bonacin
Assignee: Adriano Bonacin
On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
HostID in the new "me" SSTable version.
But SSTables flushed during CommitLogReplay miss this HostID info.
In the next Cassandra startup, if these SSTables were still present, system.log
will show:
{{WARN Origin of 3 sstables is unknown or doesn't match the local node;
commitLogIntervals for them were ignored}}
{{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
And debug.log will show a list of SSTables, witch can include "md" and "me"
version (before upgradesstables):
{{Ignored commitLogIntervals from the following sstables:
[/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18146) commons-cli vulnerability: CVE-2021-37533
[ https://issues.apache.org/jira/browse/CASSANDRA-18146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676296#comment-17676296 ] Brandon Williams commented on CASSANDRA-18146: -- Patches to suppress. ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/761/workflows/3bab9a0d-22c2-4383-af47-7c795f270341]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/759/workflows/592aab33-153e-41ba-9bb4-f3a1f3846538]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/762/workflows/bd2fa3ca-8e02-4910-9cab-39f71b3b1bd9], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/760/workflows/205a2d88-e28a-48c2-a5ad-1b281a5cf963]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/763/workflows/68abb0f7-d583-447d-ba82-c85beb769c35], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/763/workflows/bd663f65-d0aa-479e-837a-e238480eba31]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18146-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/760/workflows/18ee3008-8517-4ca2-b1d4-d1ab99683093], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/760/workflows/205a2d88-e28a-48c2-a5ad-1b281a5cf963]| > commons-cli vulnerability: CVE-2021-37533 > - > > Key: CASSANDRA-18146 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18146 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This CVE is being reported by the OWASP scan for: > commons-cli-1.1.jar: CVE-2021-37533 > commons-codec-1.9.jar: CVE-2021-37533 > commons-math3-3.2.jar: CVE-2021-37533 > additionally commons-lang3-3.1.jar is also reported on 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (dd3735a2 -> 4786a7b3)
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 dd3735a2 generate docs for b072ce0a new 4786a7b3 generate docs for b072ce0a 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 (dd3735a2) \ N -- N -- N refs/heads/asf-staging (4786a7b3) 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: .../cassandra/configuration/cass_yaml_file.html| 41 + .../cassandra/configuration/cass_yaml_file.html| 41 + .../cassandra/configuration/cass_yaml_file.html| 41 + .../cassandra/configuration/cass_yaml_file.html| 41 + content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4970898 -> 4970898 bytes 6 files changed, 165 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-18150) Prefer snakeyaml's SafeConstructor over Constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676292#comment-17676292 ] Brandon Williams commented on CASSANDRA-18150: -- I've posted patches above w/CI, so it's already done and ready for review. > Prefer snakeyaml's SafeConstructor over Constructor > --- > > Key: CASSANDRA-18150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > CVE-2022-1471 allows RCE through the Constructor class. While this isn't a > concern since yaml is only used for configuration, it is simple enough to > switch to SafeConstructor and harden the server a little more. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18150) Prefer snakeyaml's SafeConstructor over Constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676291#comment-17676291 ] Kamalesh Palanisamy commented on CASSANDRA-18150: - [~brandon.williams] is there a PR ready for this or are you looking for someone to take over this task? > Prefer snakeyaml's SafeConstructor over Constructor > --- > > Key: CASSANDRA-18150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > CVE-2022-1471 allows RCE through the Constructor class. While this isn't a > concern since yaml is only used for configuration, it is simple enough to > switch to SafeConstructor and harden the server a little more. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaman Ziadeh updated CASSANDRA-15458:
-
Status: In Progress (was: Changes Suggested)
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaman Ziadeh updated CASSANDRA-15458:
-
Status: Patch Available (was: In Progress)
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676287#comment-17676287
]
Yaman Ziadeh commented on CASSANDRA-15458:
--
The tests that failed were all to do with auto completion, they can be found
here: pylib/cqlshlib/test/test_cqlsh_completion.py.
Whenever new tables or types are added to
pylib/cqlshlib/test/test_keyspace_init.cql, their name must be added to the
appropriate completion tests. In this case, I fixed the broken tests by firstly
renaming the new table 't1' to a more standard name 'escape_quotes' and the new
type 'random' to 'quote_udt', then adding them to completion tests
test_complete_in_create_type, test_complete_in_alter_type, and
test_complete_in_alter_table respectively.
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-14013:
Reviewers: Benjamin Lerer, Michael Semb Wever, Paulo Motta (was: Benjamin
Lerer, Michael Semb Wever)
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18101) Jenkins: cqlsh tests should be run with all Python versions they are run in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18101: - Complexity: Normal (was: Low Hanging Fruit) > Jenkins: cqlsh tests should be run with all Python versions they are run in > CircleCI > > > Key: CASSANDRA-18101 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18101 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Michael Semb Wever >Priority: Normal > > We don't test with all Python versions in Jenkins. the way we do in CircleCI. > We need to fix that. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676280#comment-17676280 ] David Capwell commented on CASSANDRA-16325: --- Merged to 4.1 and trunk, so events now include the delta > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > Fix For: 4.2 > > Time Spent: 10h 10m > Remaining Estimate: 0h > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18110) Streaming progress virtual table lock contention can trigger TCP_USER_TIMEOUT and fail streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-18110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18110:
--
Fix Version/s: 4.1.1
(was: 4.1.x)
Since Version: 4.1.0
Source Control Link:
https://github.com/apache/cassandra/commit/5be1038c5d38af32d3cbb0545d867f21304f3a46
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Streaming progress virtual table lock contention can trigger TCP_USER_TIMEOUT
> and fail streaming
>
>
> Key: CASSANDRA-18110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18110
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Jon Meredith
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.1
>
>
> Running four concurrent host replacements on a 4.1.0 development cluster has
> repeatably failed to complete bootstrap with all four hosts failing bootsrrap
> and staying in JOINING, logging the message.
> {code:java}
> ERROR 2022-12-07T21:15:48,860 [main]
> org.apache.cassandra.service.StorageService:2019 - Error while waiting on
> bootstrap to complete. Bootstrap will have to be restarted.
> {code}
> Bootstrap fails as the the FileStreamTasks on the streaming followers
> encounter an EOF while transmitting the files.
> {code:java}
> ERROR 2022-12-07T15:49:39,164 [NettyStreaming-Outbound-/1.2.3.4.7000:2]
> org.apache.cassandra.streaming.StreamSession:718 - [Stream
> #8d313690-7674-11ed-813f-95c261b64a82] Streaming error occurred on session
> with peer 1.2.3.4:7000 through 1.2.3.4:40292
> org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException: The channel
> this output stream was writing to has been closed
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.propagateFailedFlush(AsyncChannelOutputPlus.java:200)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitUntilFlushed(AsyncChannelOutputPlus.java:158)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitForSpace(AsyncChannelOutputPlus.java:140)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.beginFlush(AsyncChannelOutputPlus.java:97)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.lambda$writeToChannel$0(AsyncStreamingOutputPlus.java:124)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.lambda$write$0(CassandraCompressedStreamWriter.java:89)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.writeToChannel(AsyncStreamingOutputPlus.java:120)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.write(CassandraCompressedStreamWriter.java:88)
> ~[cassandra.jar]
>at
> org.apache.cassandra.db.streaming.CassandraOutgoingFile.write(CassandraOutgoingFile.java:177)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage.serialize(OutgoingStreamMessage.java:87)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:45)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:34)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:39)
> ~[cassandra.jar]
>at
> org.apache.cassandra.streaming.async.StreamingMultiplexedChannel$FileStreamTask.run(StreamingMultiplexedChannel.java:311)
> [cassandra.jar]
>at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> [cassandra.jar]
>at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> [cassandra.jar]
>at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
>at java.lang.Thread.run(Thread.java:829) [?:?]
>Suppressed: java.nio.channels.ClosedChannelException
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.doFlush(AsyncStreamingOutputPlus.java:82)
> ~[cassandra.jar]
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.flush(AsyncChannelOutputPlus.java:229)
>
[cassandra] branch cassandra-4.1 updated: Streaming progress virtual table lock contention can trigger TCP_USER_TIMEOUT and fail streaming
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-4.1 by this push:
new 5be1038c5d Streaming progress virtual table lock contention can
trigger TCP_USER_TIMEOUT and fail streaming
5be1038c5d is described below
commit 5be1038c5d38af32d3cbb0545d867f21304f3a46
Author: David Capwell
AuthorDate: Wed Jan 11 13:40:57 2023 -0800
Streaming progress virtual table lock contention can trigger
TCP_USER_TIMEOUT and fail streaming
patch by David Capwell; reviewed by Abe Ratnofsky, Jon Meredith for
CASSANDRA-18110
---
CHANGES.txt| 3 +-
conf/cassandra.yaml| 10 ++
src/java/org/apache/cassandra/config/Config.java | 3 +
.../cassandra/config/DatabaseDescriptor.java | 27
.../org/apache/cassandra/config/DurationSpec.java | 10 ++
.../streaming/CassandraCompressedStreamReader.java | 7 +-
.../streaming/CassandraCompressedStreamWriter.java | 3 +-
.../CassandraEntireSSTableStreamReader.java| 2 +-
.../CassandraEntireSSTableStreamWriter.java| 2 +-
.../db/streaming/CassandraStreamReader.java| 7 +-
.../db/streaming/CassandraStreamWriter.java| 6 +-
.../apache/cassandra/streaming/ProgressInfo.java | 5 +-
.../apache/cassandra/streaming/StreamEvent.java| 4 +-
.../apache/cassandra/streaming/StreamManager.java | 26
.../cassandra/streaming/StreamManagerMBean.java| 20 +++
.../cassandra/streaming/StreamResultFuture.java| 15 ++-
.../apache/cassandra/streaming/StreamSession.java | 22 ++--
.../apache/cassandra/streaming/StreamingState.java | 143 +
.../management/ProgressInfoCompositeData.java | 3 +
.../test/streaming/RebuildStreamingTest.java | 33 -
.../test/streaming/StreamingStatsDisabledTest.java | 65 ++
.../distributed/util/QueryResultUtil.java | 7 +
.../db/virtual/StreamingVirtualTableTest.java | 85 +---
.../cassandra/streaming/SessionInfoTest.java | 4 +-
24 files changed, 361 insertions(+), 151 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index c6ceac0575..c5d192a9c8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
4.1.1
-* Fix perpetual load of denylist on read in cases where denylist can never be
loaded (CASSANDRA-18116)
+ * Streaming progress virtual table lock contention can trigger
TCP_USER_TIMEOUT and fail streaming (CASSANDRA-18110)
+ * Fix perpetual load of denylist on read in cases where denylist can never be
loaded (CASSANDRA-18116)
Merged from 4.0:
* Avoid ConcurrentModificationException in STCS/DTCS/TWCS.getSSTables
(CASSANDRA-17977)
* Restore internode custom tracing on 4.0's new messaging system
(CASSANDRA-17981)
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index ef7cc72605..f54c0d4617 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -1161,6 +1161,16 @@ slow_query_log_timeout: 500ms
# bound (for example a few nodes with big files).
# streaming_connections_per_host: 1
+# Settings for stream stats tracking; used by system_views.streaming table
+# How long before a stream is evicted from tracking; this impacts both
historic and currently running
+# streams.
+# streaming_state_expires: 3d
+# How much memory may be used for tracking before evicting session from
tracking; once crossed
+# historic and currently running streams maybe impacted.
+# streaming_state_size: 40MiB
+# Enable/Disable tracking of streaming stats
+# streaming_stats_enabled: true
+
# Allows denying configurable access (rw/rr) to operations on configured ks,
table, and partitions, intended for use by
# operators to manage cluster health vs application access. See
CASSANDRA-12106 and CEP-13 for more details.
# partition_denylist_enabled: false
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index df419e780c..8a59ca2cda 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -852,6 +852,9 @@ public class Config
public volatile DurationSpec.LongNanosecondsBound streaming_state_expires
= new DurationSpec.LongNanosecondsBound("3d");
public volatile DataStorageSpec.LongBytesBound streaming_state_size = new
DataStorageSpec.LongBytesBound("40MiB");
+public volatile boolean streaming_stats_enabled = true;
+public volatile DurationSpec.IntSecondsBound
streaming_slow_events_log_timeout = new DurationSpec.IntSecondsBound("10s");
+
/** The configuration of startup checks. */
public volatile Map> startup_checks
= new HashMap<>();
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index
[cassandra] branch trunk updated (995c3abc42 -> 7df4530882)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 995c3abc42 Merge branch 'cassandra-4.1' into trunk new 5be1038c5d Streaming progress virtual table lock contention can trigger TCP_USER_TIMEOUT and fail streaming new 7df4530882 Merge branch 'cassandra-4.1' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + conf/cassandra.yaml| 10 ++ src/java/org/apache/cassandra/config/Config.java | 3 + .../cassandra/config/DatabaseDescriptor.java | 27 .../org/apache/cassandra/config/DurationSpec.java | 10 ++ .../streaming/CassandraCompressedStreamReader.java | 7 +- .../streaming/CassandraCompressedStreamWriter.java | 3 +- .../CassandraEntireSSTableStreamReader.java| 2 +- .../CassandraEntireSSTableStreamWriter.java| 2 +- .../db/streaming/CassandraStreamReader.java| 7 +- .../db/streaming/CassandraStreamWriter.java| 6 +- .../apache/cassandra/streaming/ProgressInfo.java | 5 +- .../apache/cassandra/streaming/StreamEvent.java| 4 +- .../apache/cassandra/streaming/StreamManager.java | 26 .../cassandra/streaming/StreamManagerMBean.java| 20 +++ .../cassandra/streaming/StreamResultFuture.java| 15 ++- .../apache/cassandra/streaming/StreamSession.java | 22 ++-- .../apache/cassandra/streaming/StreamingState.java | 143 + .../management/ProgressInfoCompositeData.java | 3 + .../test/streaming/RebuildStreamingTest.java | 33 - .../test/streaming/StreamingStatsDisabledTest.java | 65 ++ .../distributed/util/QueryResultUtil.java | 7 + .../db/virtual/StreamingVirtualTableTest.java | 85 +--- .../cassandra/streaming/SessionInfoTest.java | 4 +- 24 files changed, 360 insertions(+), 150 deletions(-) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/streaming/StreamingStatsDisabledTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 7df4530882c44f6de942b225af455f6399b66302 Merge: 995c3abc42 5be1038c5d Author: David Capwell AuthorDate: Thu Jan 12 09:46:57 2023 -0800 Merge branch 'cassandra-4.1' into trunk CHANGES.txt| 1 + conf/cassandra.yaml| 10 ++ src/java/org/apache/cassandra/config/Config.java | 3 + .../cassandra/config/DatabaseDescriptor.java | 27 .../org/apache/cassandra/config/DurationSpec.java | 10 ++ .../streaming/CassandraCompressedStreamReader.java | 7 +- .../streaming/CassandraCompressedStreamWriter.java | 3 +- .../CassandraEntireSSTableStreamReader.java| 2 +- .../CassandraEntireSSTableStreamWriter.java| 2 +- .../db/streaming/CassandraStreamReader.java| 7 +- .../db/streaming/CassandraStreamWriter.java| 6 +- .../apache/cassandra/streaming/ProgressInfo.java | 5 +- .../apache/cassandra/streaming/StreamEvent.java| 4 +- .../apache/cassandra/streaming/StreamManager.java | 26 .../cassandra/streaming/StreamManagerMBean.java| 20 +++ .../cassandra/streaming/StreamResultFuture.java| 15 ++- .../apache/cassandra/streaming/StreamSession.java | 22 ++-- .../apache/cassandra/streaming/StreamingState.java | 143 + .../management/ProgressInfoCompositeData.java | 3 + .../test/streaming/RebuildStreamingTest.java | 33 - .../test/streaming/StreamingStatsDisabledTest.java | 65 ++ .../distributed/util/QueryResultUtil.java | 7 + .../db/virtual/StreamingVirtualTableTest.java | 85 +--- .../cassandra/streaming/SessionInfoTest.java | 4 +- 24 files changed, 360 insertions(+), 150 deletions(-) diff --cc CHANGES.txt index 682316e397,c5d192a9c8..b1bc6f0cc9 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,103 -1,27 +1,104 @@@ -4.1.1 +4.2 + * Fix serialization error in new getsstables --show-levels option (CASSANDRA-18140) + * Use checked casts when reading vints as ints (CASSANDRA-18099) + * Add Mutation Serialization Caching (CASSANDRA-17998) + * Only reload compaction strategies if disk boundaries change (CASSANDRA-17874) + * CEP-10: Simulator Java11 Support (CASSANDRA-17178) + * Set the major compaction type correctly for compactionstats (CASSANDRA-18055) + * Print exception message without stacktrace when nodetool commands fail on probe.getOwnershipWithPort() (CASSANDRA-18079) + * Add option to print level in nodetool getsstables output (CASSANDRA-18023) + * Implement a guardrail for not having zero default_time_to_live on tables with TWCS (CASSANDRA-18042) + * Add CQL scalar functions for collection aggregation (CASSANDRA-18060) + * Make cassandra.replayList property for CommitLogReplayer possible to react on keyspaces only (CASSANDRA-18044) + * Add Mathematical functions (CASSANDRA-17221) + * Make incremental backup configurable per table (CASSANDRA-15402) + * Change shebangs of Python scripts to resolve Python 3 from env command (CASSANDRA-17832) + * Add reasons to guardrail messages and consider guardrails in the error message for needed ALLOW FILTERING (CASSANDRA-17967) + * Add support for CQL functions on collections, tuples and UDTs (CASSANDRA-17811) + * Add flag to exclude nodes from local DC when running nodetool rebuild (CASSANDRA-17870) + * Adding endpoint verification option to client_encryption_options (CASSANDRA-18034) + * Replace 'wcwidth.py' with pypi module (CASSANDRA-17287) + * Add nodetool forcecompact to remove tombstoned or ttl'd data ignoring GC grace for given table and partition keys (CASSANDRA-17711) + * Offer IF (NOT) EXISTS in cqlsh completion for CREATE TYPE, DROP TYPE, CREATE ROLE and DROP ROLE (CASSANDRA-16640) + * Nodetool bootstrap resume will now return an error if the operation fails (CASSANDRA-16491) + * Disable resumable bootstrap by default (CASSANDRA-17679) + * Include Git SHA in --verbose flag for nodetool version (CASSANDRA-17753) + * Update Byteman to 4.0.20 and Jacoco to 0.8.8 (CASSANDRA-16413) + * Add memtable option among possible tab completions for a table (CASSANDRA-17982) + * Adds a trie-based memtable implementation (CASSANDRA-17240) + * Further improves precision of memtable heap tracking (CASSANDRA-17240) + * Fix formatting of metrics documentation (CASSANDRA-17961) + * Keep sstable level when streaming for decommission and move (CASSANDRA-17969) + * Add Unavailables metric for CASWrite in the docs (CASSANDRA-16357) + * Make Cassandra logs able to be viewed in the virtual table system_views.system_logs (CASSANDRA-17946) + * IllegalArgumentException in Gossiper#order due to concurrent mutations to elements being applied (CASSANDRA-17908) + * Include estimated active compaction remaining write size when
[jira] [Updated] (CASSANDRA-18149) snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064
[ https://issues.apache.org/jira/browse/CASSANDRA-18149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18149: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064 > -- > > Key: CASSANDRA-18149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18149 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > The OWASP scan is reporting these for both snakeyaml-1.11 and snakeyaml-1.26. > These are similar to CASSANDRA-17907 in that they require access to the yaml > to have any effect. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676248#comment-17676248
]
Brandon Williams edited comment on CASSANDRA-18032 at 1/12/23 5:31 PM:
---
A non-zero error code is definitely being returned even upon success now.
was (Author: brandon.williams):
A non-zero error code is definitely be returned even upon success now.
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676274#comment-17676274
]
Andres de la Peña commented on CASSANDRA-18032:
---
[Here|https://github.com/apache/cassandra/compare/trunk...adelapena:18032-trunk-followup]
is a possible fix.
The problem was that [the calls to grep inside this
subshell|https://github.com/apache/cassandra/blob/trunk/.circleci/generate.sh#L206-L211]
were returning 1 (not found) when the diff is empty, and the new {{set -e}}
was interrupting the execution due to that not-zero return code. The solution
is just suppressing that code, which can be done in multiple ways.
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-15458:
Mentor: Paulo Motta (was: Benjamin Lerer)
Status: Changes Suggested (was: Review In Progress)
cancelling patch as there seems to some failures on
[TestCqlshCompletion|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2159/]
due to creation of new table
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-15458:
Status: Review In Progress (was: Needs Committer)
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18143) upgradesstables does not always upgrade tables in proper order.
[ https://issues.apache.org/jira/browse/CASSANDRA-18143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676257#comment-17676257 ] Claude Warren commented on CASSANDRA-18143: --- Pull request is at https://github.com/apache/cassandra/pull/2081 > upgradesstables does not always upgrade tables in proper order. > --- > > Key: CASSANDRA-18143 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18143 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > > The SSTableUpgrader accepts tools in the hash order provided by > Directories.SSTableLister rather than ordering them to ensure that they are > upgraded in the proper order. > They should be ordered by their id. The comparator for SSTableId is available > in SSTableIdFactory.COMPARATOR. > > Dev discussion thread: > https://lists.apache.org/thread/w6pm5hbdxt295mtvlckv0joyk8x4o8nf -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (2dad32b2 -> dd3735a2)
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 2dad32b2 generate docs for b072ce0a new dd3735a2 generate docs for b072ce0a 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 (2dad32b2) \ N -- N -- N refs/heads/asf-staging (dd3735a2) 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 4970898 -> 4970898 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-18148) netty-all vulnerability: CVE-2022-41881
[ https://issues.apache.org/jira/browse/CASSANDRA-18148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676253#comment-17676253 ] Brandon Williams commented on CASSANDRA-18148: -- [~norman] I don't suppose you can advise? > netty-all vulnerability: CVE-2022-41881 > --- > > Key: CASSANDRA-18148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18148 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This is showing in the OWASP scan. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18149) snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064
[ https://issues.apache.org/jira/browse/CASSANDRA-18149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676250#comment-17676250 ] Brandon Williams edited comment on CASSANDRA-18149 at 1/12/23 4:37 PM: --- Patches to suppress these. We'll need to suppress 1471 even after CASSANDRA-18150 is committed. ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/757/workflows/1cb40cef-9b42-4e52-a0e5-738fc28e2fba]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/756/workflows/437ba05b-82a6-48d8-975e-d3a22fe8b2fe]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/fc941ea8-46a7-436f-8ea1-77c16466bf80], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/2911192c-a53f-431d-971a-88ecdfe82837]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/9b75ac22-7f2b-486f-b922-90425da1f7d7], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/755/workflows/4644601b-1723-4178-9d18-dc64e6ef720c], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/755/workflows/ba37ace8-807f-40b2-bd45-50efd1837a61]| was (Author: brandon.williams): Patches to suppress these. We'll need to suppress 1471 even after CASSANDRA-18150 is committed. ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/757/workflows/1cb40cef-9b42-4e52-a0e5-738fc28e2fba]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/756/workflows/437ba05b-82a6-48d8-975e-d3a22fe8b2fe]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/fc941ea8-46a7-436f-8ea1-77c16466bf80], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/2911192c-a53f-431d-971a-88ecdfe82837]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/9b75ac22-7f2b-486f-b922-90425da1f7d7], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/9b75ac22-7f2b-486f-b922-90425da1f7d7], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| > snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064 > -- > > Key: CASSANDRA-18149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18149 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > The OWASP scan is reporting these for both snakeyaml-1.11 and snakeyaml-1.26. > These are similar to CASSANDRA-17907 in that they require access to the yaml > to have any effect. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18149) snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064
[ https://issues.apache.org/jira/browse/CASSANDRA-18149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676250#comment-17676250 ] Brandon Williams edited comment on CASSANDRA-18149 at 1/12/23 4:34 PM: --- Patches to suppress these. We'll need to suppress 1471 even after CASSANDRA-18150 is committed. ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/757/workflows/1cb40cef-9b42-4e52-a0e5-738fc28e2fba]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/756/workflows/437ba05b-82a6-48d8-975e-d3a22fe8b2fe]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/fc941ea8-46a7-436f-8ea1-77c16466bf80], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/2911192c-a53f-431d-971a-88ecdfe82837]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/9b75ac22-7f2b-486f-b922-90425da1f7d7], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/9b75ac22-7f2b-486f-b922-90425da1f7d7], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| was (Author: brandon.williams): Patches to suppress these. We'll need to suppress 1471 even after CASSANDRA-18150 is committed. ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/757/workflows/1cb40cef-9b42-4e52-a0e5-738fc28e2fba]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/756/workflows/437ba05b-82a6-48d8-975e-d3a22fe8b2fe]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/fc941ea8-46a7-436f-8ea1-77c16466bf80], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/2911192c-a53f-431d-971a-88ecdfe82837]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/9b75ac22-7f2b-486f-b922-90425da1f7d7], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-trunk]|[j8|], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| > snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064 > -- > > Key: CASSANDRA-18149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18149 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > The OWASP scan is reporting these for both snakeyaml-1.11 and snakeyaml-1.26. > These are similar to CASSANDRA-17907 in that they require access to the yaml > to have any effect. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18149) snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064
[ https://issues.apache.org/jira/browse/CASSANDRA-18149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676250#comment-17676250 ] Brandon Williams edited comment on CASSANDRA-18149 at 1/12/23 4:33 PM: --- Patches to suppress these. We'll need to suppress 1471 even after CASSANDRA-18150 is committed. ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/757/workflows/1cb40cef-9b42-4e52-a0e5-738fc28e2fba]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/756/workflows/437ba05b-82a6-48d8-975e-d3a22fe8b2fe]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/fc941ea8-46a7-436f-8ea1-77c16466bf80], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/2911192c-a53f-431d-971a-88ecdfe82837]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/9b75ac22-7f2b-486f-b922-90425da1f7d7], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-trunk]|[j8|], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| was (Author: brandon.williams): Patches to suppress these. We'll need to suppress 1471 even after CASSANDRA-18150 is committed. ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/757/workflows/1cb40cef-9b42-4e52-a0e5-738fc28e2fba]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/756/workflows/437ba05b-82a6-48d8-975e-d3a22fe8b2fe]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/fc941ea8-46a7-436f-8ea1-77c16466bf80][j11|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/2911192c-a53f-431d-971a-88ecdfe82837]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/9b75ac22-7f2b-486f-b922-90425da1f7d7][j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-trunk]|[j8|][j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| > snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064 > -- > > Key: CASSANDRA-18149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18149 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > The OWASP scan is reporting these for both snakeyaml-1.11 and snakeyaml-1.26. > These are similar to CASSANDRA-17907 in that they require access to the yaml > to have any effect. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18149) snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064
[ https://issues.apache.org/jira/browse/CASSANDRA-18149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676250#comment-17676250 ] Brandon Williams commented on CASSANDRA-18149: -- Patches to suppress these. We'll need to suppress 1471 even after CASSANDRA-18150 is committed. ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/757/workflows/1cb40cef-9b42-4e52-a0e5-738fc28e2fba]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/756/workflows/437ba05b-82a6-48d8-975e-d3a22fe8b2fe]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/fc941ea8-46a7-436f-8ea1-77c16466bf80][j11|https://app.circleci.com/pipelines/github/driftx/cassandra/754/workflows/2911192c-a53f-431d-971a-88ecdfe82837]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/9b75ac22-7f2b-486f-b922-90425da1f7d7][j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18149-trunk]|[j8|][j11|https://app.circleci.com/pipelines/github/driftx/cassandra/758/workflows/e3091d43-b6a1-482c-99c4-2be1085ced05]| > snakeyaml vulnerabilities: CVE-2021-4235, CVE-2022-1471, CVE-2022-3064 > -- > > Key: CASSANDRA-18149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18149 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > The OWASP scan is reporting these for both snakeyaml-1.11 and snakeyaml-1.26. > These are similar to CASSANDRA-17907 in that they require access to the yaml > to have any effect. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676248#comment-17676248
]
Brandon Williams commented on CASSANDRA-18032:
--
A non-zero error code is definitely be returned even upon success now.
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676243#comment-17676243
]
Andres de la Peña edited comment on CASSANDRA-18032 at 1/12/23 4:06 PM:
I'm afraid that, as reported by [~stefan.miklosovic], the {{set -e}} is
breaking the writing of env vars, including those used for test multiplexer.
For example, if you run:
{code:java}
.circleci/generate.sh -l -e
REPEATED_JVM_DTESTS=org.apache.cassandra.distributed.test.AuthTest
{code}
The {{REPEATED_JVM_DTESTS}} is not written:
{code:java}
Generating new config.yml file with low resources from config-2_1.yml
Detecting new or modified tests with git diff --diff-filter=AMR trunk...HEAD:
{code}
I suspect that [this
subshell|https://github.com/apache/cassandra/blob/trunk/.circleci/generate.sh#L206-L211]
is producing a not-zero output that immediately stops execution. That happens
after the resource config has been written, but the automatic test detection
fails and the writing of env vars is skipped.
was (Author: adelapena):
I'm afraid that, as reported by [~stefan.miklosovic], the {{set -e}} is
breaking the writing of env vars, including those used for test multiplexer.
For example, if you run:
{code:java}
.circleci/generate.sh -l -e
REPEATED_JVM_DTESTS=org.apache.cassandra.distributed.test.AuthTest
{code}
The {{REPEATED_JVM_DTESTS}} is not written:
{code:java}
Generating new config.yml file with low resources from config-2_1.yml
Detecting new or modified tests with git diff --diff-filter=AMR trunk...HEAD:
{code}
I suspect that [this
subshell|https://github.com/apache/cassandra/blob/trunk/.circleci/generate.sh#L206-L211]
is producing a not-zero output that immediately stops execution.
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18032:
--
Resolution: (was: Fixed)
Status: Open (was: Resolved)
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676243#comment-17676243
]
Andres de la Peña commented on CASSANDRA-18032:
---
I'm afraid that, as reported by [~stefan.miklosovic], the {{set -e}} is
breaking the writing of env vars, including those used for test multiplexer.
For example, if you run:
{code:java}
.circleci/generate.sh -l -e
REPEATED_JVM_DTESTS=org.apache.cassandra.distributed.test.AuthTest
{code}
The {{REPEATED_JVM_DTESTS}} is not written:
{code:java}
Generating new config.yml file with low resources from config-2_1.yml
Detecting new or modified tests with git diff --diff-filter=AMR trunk...HEAD:
{code}
I suspect that [this
subshell|https://github.com/apache/cassandra/blob/trunk/.circleci/generate.sh#L206-L211]
is producing a not-zero output that immediately stops execution.
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18150) Prefer snakeyaml's SafeConstructor over Constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18150: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > Prefer snakeyaml's SafeConstructor over Constructor > --- > > Key: CASSANDRA-18150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > CVE-2022-1471 allows RCE through the Constructor class. While this isn't a > concern since yaml is only used for configuration, it is simple enough to > switch to SafeConstructor and harden the server a little more. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18134:
---
Fix Version/s: 4.x
(was: 5.x)
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice instead of min/max clusterings.
> The difference is that for slices there is available the type of a bound
> rather than just a clustering. In particular it will provide the information
> whether the lower and upper bound of an sstable is opened or closed.
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # The above two changes required to introduce a new major format for SSTables
> - {{oa}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (38cd3542 -> 2dad32b2)
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 38cd3542 generate docs for b072ce0a new 2dad32b2 generate docs for b072ce0a 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 (38cd3542) \ N -- N -- N refs/heads/asf-staging (2dad32b2) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970898 -> 4970898 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[
https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676047#comment-17676047
]
Stefan Miklosovic commented on CASSANDRA-18061:
---
Correct, nodetool compaction history would return "{}" (string representation
of empty map). So no default value is needed.
Please incorporate this work and I will review again.
Thank you!
> Add compaction type output result for nodetool compactionhistory
>
>
> Key: CASSANDRA-18061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18061
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction, Tool/nodetool
>Reporter: maxwellguo
>Assignee: maxwellguo
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 9h
> Remaining Estimate: 0h
>
> If we want to see whether we have made a compaction and what kind of
> compaction we have done for this node, we may go to see the
> compaction_history system table for some deftails or use nodetool
> compactionhistory command , But I found that the table do not specify the
> compaction type so does the compactionhistory command too, like index build ,
> compaction type, clean or scrub for this node. So I think may be it is need
> to add a type of compaction column to specify the compaction tpe for
> system.compaction_history and so we can get the type of compaction through
> system.compaction_history table or nodetool compactionhistory to see whether
> we have made a major compact for this node .:)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676042#comment-17676042 ] maxwellguo commented on CASSANDRA-18061: Hi [~smiklosovic], that means emtyp map will return as the nodetool compactionhistory output ? then no default value is needed? Besides I have left one comment on the git and mention , can you take a look if you are convenient。:D > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 8h 50m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (546d5dfa -> 38cd3542)
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 546d5dfa generate docs for b072ce0a new 38cd3542 generate docs for b072ce0a 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 (546d5dfa) \ N -- N -- N refs/heads/asf-staging (38cd3542) 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 4970898 -> 4970898 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] [Created] (CASSANDRA-18152) mockito-inline causes tests to fail beacause o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
Stefan Miklosovic created CASSANDRA-18152: - Summary: mockito-inline causes tests to fail beacause o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean Key: CASSANDRA-18152 URL: https://issues.apache.org/jira/browse/CASSANDRA-18152 Project: Cassandra Issue Type: Bug Reporter: Stefan Miklosovic While working on CASSANDRA-14361, when we included mockito-inline into the build to test the new functionality, unrelated tests in CI started to fail. (1) This is happening because mockito, together with stuff which enables static mocking, just does not play together with our way of doing things in dtest framework. The workaround is consisting of removing Mockito from InternalNodeProbe, it tries to spy on StorageService to not send any notifications back. This might be workarounded so we do not need Mockito hence tests are fixed and mocking of static methods is possible without any other tests failing. (1) https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2168/#showFailuresLink see also: [https://github.com/mockito/mockito/issues/2203] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18101) Jenkins: cqlsh tests should be run with all Python versions they are run in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18101: --- Epic Link: CASSANDRA-18137 (was: CASSANDRA-18007) > Jenkins: cqlsh tests should be run with all Python versions they are run in > CircleCI > > > Key: CASSANDRA-18101 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18101 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Michael Semb Wever >Priority: Normal > > We don't test with all Python versions in Jenkins. the way we do in CircleCI. > We need to fix that. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18143) upgradesstables does not always upgrade tables in proper order.
[ https://issues.apache.org/jira/browse/CASSANDRA-18143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676005#comment-17676005 ] Jacek Lewandowski commented on CASSANDRA-18143: --- [~claude] please attach a link to the pull request you've created > upgradesstables does not always upgrade tables in proper order. > --- > > Key: CASSANDRA-18143 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18143 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > > The SSTableUpgrader accepts tools in the hash order provided by > Directories.SSTableLister rather than ordering them to ensure that they are > upgraded in the proper order. > They should be ordered by their id. The comparator for SSTableId is available > in SSTableIdFactory.COMPARATOR. > > Dev discussion thread: > https://lists.apache.org/thread/w6pm5hbdxt295mtvlckv0joyk8x4o8nf -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17056) Pluggable SSTable format (SSTable format API)
[ https://issues.apache.org/jira/browse/CASSANDRA-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-17056: -- Fix Version/s: 5.x > Pluggable SSTable format (SSTable format API) > - > > Key: CASSANDRA-17056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17056 > Project: Cassandra > Issue Type: New Feature > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18027) Use G1GC as default
[ https://issues.apache.org/jira/browse/CASSANDRA-18027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676003#comment-17676003 ] Brandon Williams commented on CASSANDRA-18027: -- Alex's post for reference: https://thelastpickle.com/blog/2020/06/29/cassandra_4-0_garbage_collectors_performance_benchmarks.html > Use G1GC as default > --- > > Key: CASSANDRA-18027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18027 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 4.1.x, 4.x > > > G1GC is well battle tested now, and the recommended configuration for most > users. CMS can work well on smaller heaps but requires more tuning, initially > and over time. G1GC just works. CMS was deprecated in JDK 9. > Patch at > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/7486/trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18150) Prefer snakeyaml's SafeConstructor over Constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675996#comment-17675996 ] Brandon Williams commented on CASSANDRA-18150: -- ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18150-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/753/workflows/1558103b-ceb4-40f2-9d0e-c0ab91c02af3]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18150-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/749/workflows/0b77ff19-a983-4a98-8718-28bcefbf9d33]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18150-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/750/workflows/f5f31556-5733-48b6-86d0-c3fce767dfa0], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/750/workflows/88316075-39bf-496c-9932-1144f3762e2d]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18150-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/751/workflows/e9c27e14-f6f7-4d42-9004-09f9fe718d09], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/751/workflows/dab4175c-0181-4fb8-a32b-1e9c27057e15]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18150-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/752/workflows/a93698a6-18f0-4de0-8d15-bf86dcc67fdb], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/752/workflows/ab13bef0-945c-4ce3-8125-387fc5bd8220]| > Prefer snakeyaml's SafeConstructor over Constructor > --- > > Key: CASSANDRA-18150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > CVE-2022-1471 allows RCE through the Constructor class. While this isn't a > concern since yaml is only used for configuration, it is simple enough to > switch to SafeConstructor and harden the server a little more. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18027) Use G1GC as default
[ https://issues.apache.org/jira/browse/CASSANDRA-18027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675994#comment-17675994 ] Michael Semb Wever commented on CASSANDRA-18027: Summary to date of the thread: no vetoes to the change in trunk, there were vetoes to 4.1.0, and there was a desire to have benchmarking heap data presented. It is unclear if the vetoes against 4.1.0 also apply to 4.1.1, and the extent of benchmarking required when we know G1 is really the only option when CASSANDRA-16895 / CASSANDRA-16501 lands. It's also worth re-iterating that Alex's blog post does put data on the table for us, if we're happy to go with that this time while we work on what our pre-commit performance testing for the project is (ref: [this dev thread|https://lists.apache.org/thread/kzbv632tm0j99mg10z24wb8f09z0r81z]). > Use G1GC as default > --- > > Key: CASSANDRA-18027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18027 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 4.1.x, 4.x > > > G1GC is well battle tested now, and the recommended configuration for most > users. CMS can work well on smaller heaps but requires more tuning, initially > and over time. G1GC just works. CMS was deprecated in JDK 9. > Patch at > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/7486/trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18134:
--
Description:
This patch improves the following things:
# SSTable metadata will store a covered slice instead of min/max clusterings.
The difference is that for slices there is available the type of a bound rather
than just a clustering. In particular it will provide the information whether
the lower and upper bound of an sstable is opened or closed.
# SSTable metadata will store a flag whether the SSTable contains any partition
level deletions or not
# The above two changes required to introduce a new major format for SSTables -
{{oa}}
# Single partition read command makes use of the above changes. In particular
an sstable can be skipped when it does not intersect with the column filter,
does not have partition level deletions and does not have statics; In case
there are partition level deletions, but the other conditions are satisfied,
only the partition header needs to be accessed (tests attached)
# Skipping sstables assuming those three conditions are satisfied has been
implemented also for partition range queries (tests attached). Also added minor
separate statistics to record the number of accessed sstables in partition
reads because now not all of them need to be accessed. That statistics is also
needed in tests to confirm skipping.
# Artificial lower bound marker is now an object on its own and is not
implemented as a special case of range tombstone bound. Instead it sorts right
before the lowest available bound in the data
# Extended the lower bound optimization usage due the 1 and 2
# Do not initialize iterator just to get a cached partition and associated
columns index. The purpose of using lower bound optimization was to avoid
opening an iterator of an sstable if possible.
See also CASSANDRA-14861
The changes in this patch include work of [~blambov], [~slebresne],
[~jakubzytka] and [~jlewandowski]
was:
This patch improves the following things:
# SSTable metadata will store a covered slice instead of min/max clusterings.
The difference is that for slices there is available the type of a bound rather
than just a clustering. In particular it will provide the information whether
the lower and upper bound of an sstable is opened or closed.
# SSTable metadata will store a flag whether the SSTable contains any partition
level deletions or not
# The above two changes required to introduce a new major format for SSTables -
{{oa}}
# Single partition read command makes use of the above changes. In particular
an sstable can be skipped when it does not intersect with the column filter,
does not have partition level deletions and does not have statics; In case
there are partition level deletions, but the other conditions are satisfied,
only the partition header needs to be accessed (tests attached)
# Skipping sstables assuming those three conditions are satisfied has been
implemented also for partition range queries (tests attached). Also added minor
separate statistics to record the number of accessed sstables in partition
reads because now not all of them need to be accessed. That statistics is also
needed in tests to confirm skipping.
# Artificial lower bound marker is now an object on its own and is not
implemented as a special case of range tombstone bound. Instead it sorts right
before the lowest available bound in the data
# Extended the lower bound optimization usage due the 1 and 2
# Do not initialize iterator just to get a cached partition and associated
columns index. The purpose of using lower bound optimization was to avoid
opening an iterator of an sstable if possible.
See also CASSANDRA-14861
The changes in this patch includes work of [~blambov], [~slebresne],
[~jakubzytka] and [~jlewandowski]
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice instead of min/max clusterings.
> The difference is that for slices there is available the type of a bound
> rather than just a clustering. In particular it will provide the information
> whether the lower and upper bound of an sstable is opened or closed.
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # The above two changes required to introduce a new major format for SSTables
> - {{oa}}
> # Single partition read
[jira] [Commented] (CASSANDRA-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default c
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675969#comment-17675969 ] Stefan Miklosovic commented on CASSANDRA-12525: --- Yeah I'll backport that. It seems to be very easy patch. > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra credentials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema, Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default c
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675968#comment-17675968 ] Brandon Williams commented on CASSANDRA-12525: -- Sorry, I meant 'branch and run CI', if you are keen to fix it in all the branches. > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra credentials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema, Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[
https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675962#comment-17675962
]
Stefan Miklosovic commented on CASSANDRA-18061:
---
Hey [~maxwellguo]
We we discussing with [~jlewandowski] this improvement:
{code}
cqlsh> CREATE KEYSPACE ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> CREATE TABLE ks.tb ( id int, compaction_properties frozen>, primary KEY (id));
cqlsh> INSERT INTO ks.tb (id) VALUES ( 1);
cqlsh> select * from ks.tb ;
id | compaction_properties
+---
1 | null
(1 rows)
cqlsh> update ks.tb SET compaction_properties = {} WHERE id = 1;
cqlsh> select * from ks.tb ;
id | compaction_properties
+---
1 | {}
(1 rows)
cqlsh> CREATE TABLE ks.tb2 ( id int, compaction_properties map,
primary KEY (id));
cqlsh> INSERT INTO ks.tb2 (id) VALUES ( 1);
cqlsh> update ks.tb2 SET compaction_properties = {} WHERE id = 1;
cqlsh> select * from ks.tb2 ;
id | compaction_properties
+---
1 | null
(1 rows)
{code}
Could you please change the type of compaction_properties to frozen> ?
We were suggesting in above comments to have empty map inserted with no
defaults in case the original value was null.
When that is done, when we migrate, we would insert empty map ({}) into
compaction_properties and not map with one entry. It is very easy that way as
we do not need any additional logic in CompactionHistoryProperty and I think
that class can be completely removed.
> Add compaction type output result for nodetool compactionhistory
>
>
> Key: CASSANDRA-18061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18061
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction, Tool/nodetool
>Reporter: maxwellguo
>Assignee: maxwellguo
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 7h 50m
> Remaining Estimate: 0h
>
> If we want to see whether we have made a compaction and what kind of
> compaction we have done for this node, we may go to see the
> compaction_history system table for some deftails or use nodetool
> compactionhistory command , But I found that the table do not specify the
> compaction type so does the compactionhistory command too, like index build ,
> compaction type, clean or scrub for this node. So I think may be it is need
> to add a type of compaction column to specify the compaction tpe for
> system.compaction_history and so we can get the type of compaction through
> system.compaction_history table or nodetool compactionhistory to see whether
> we have made a major compact for this node .:)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675959#comment-17675959 ] Andres de la Peña edited comment on CASSANDRA-14361 at 1/12/23 11:42 AM: - Changes look good to me, +1. I have started [a CI run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2545/workflows/eaa36a20-abab-4a3d-950f-36c692920534] including 500 repetitions of the new test. Thanks for notifying the mail list, I guess no one will oppose the new dependency. Let's wait a bit before merge to see if someone has any objection. was (Author: adelapena): Changes look good to me, +1. I have started [a CI run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2545/workflows/eaa36a20-abab-4a3d-950f-36c692920534] including 500 repetitions of the new test. Thanks for notifying the mail list, I guess no one will oppose the new dependency. Let's wait a bit before merge to see in anyone has any objection. > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ben Bromhead >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 4.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675959#comment-17675959 ] Andres de la Peña commented on CASSANDRA-14361: --- Changes look good to me, +1. I have started [a CI run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2545/workflows/eaa36a20-abab-4a3d-950f-36c692920534] including 500 repetitions of the new test. Thanks for notifying the mail list, I guess no one will oppose the new dependency. Let's wait a bit before merge to see in anyone has any objection. > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ben Bromhead >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 4.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675958#comment-17675958
]
Stefan Miklosovic commented on CASSANDRA-14013:
---
seems good to me but 4.1 build somehow finished in half? (too low number of
tests run and it returned as errorneous), I will rerun 4.1 branch.
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18134:
---
Fix Version/s: 5.x
(was: 4.2)
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice instead of min/max clusterings.
> The difference is that for slices there is available the type of a bound
> rather than just a clustering. In particular it will provide the information
> whether the lower and upper bound of an sstable is opened or closed.
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # The above two changes required to introduce a new major format for SSTables
> - {{oa}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch includes work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18125) AssertionError on thread MemtableReclaimMemory in MemtablePool$SubPool.released(MemtablePool.java:193)
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675883#comment-17675883
]
Nicolas Vollmar edited comment on CASSANDRA-18125 at 1/12/23 11:17 AM:
---
Recently we ran into this as well, immediately preceding the exception there
was the warn log:
{code:java}
Unable to lock JVM memory (ENOMEM). This can result in part of the JVM being
swapped out, especially with mmapped I/O enabled. Increase RLIMIT_MEMLOCK.
{code}
(Cassandra 4.0.7 / OpenJDK 11.0.17)
was (Author: JIRAUSER297793):
Recently we ran into this as well, immediately preceding the exception there
was the warn log:
{code:java}
Unable to lock JVM memory (ENOMEM). This can result in part of the JVM being
swapped out, especially with mmapped I/O enabled. Increase RLIMIT_MEMLOCK.
{code}
> AssertionError on thread MemtableReclaimMemory in
> MemtablePool$SubPool.released(MemtablePool.java:193)
> --
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
>Reporter: Nicolas Henneaux
>Priority: Normal
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (e5691961 -> 546d5dfa)
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 e5691961 generate docs for b072ce0a new 546d5dfa generate docs for b072ce0a 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 (e5691961) \ N -- N -- N refs/heads/asf-staging (546d5dfa) 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 4970898 -> 4970898 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-18130) Log hardware and container params during test runs to help troubleshoot intermittent failures
[
https://issues.apache.org/jira/browse/CASSANDRA-18130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675947#comment-17675947
]
Michael Semb Wever commented on CASSANDRA-18130:
Let's unblock this from both 17869 and 18133, and put what we need into the
groovy dsl asap.
> Log hardware and container params during test runs to help troubleshoot
> intermittent failures
> -
>
> Key: CASSANDRA-18130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18130
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java, Test/dtest/python, Test/unit
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> {color:#00}We’ve long had flakiness in our containerized ASF CI
> environment that we don’t see in circleci. The environment itself is both
> containerized and heterogenous, so there are differences in both the hardware
> environment and the software environment in which it executes. For reference,
> see:
> [https://github.com/apache/cassandra-builds/blob/trunk/ASF-jenkins-agents.md#current-agents]{color}
> {color:#00} {color}
> {color:#00}We should log a variety of hardware, container, and software
> environment details to help get to the bottom of where some test failures may
> be occurring. As we don’t have shell access to the machines it’ll be easier
> to have this information logged / retrieved during test runs than to try and
> profile each host independently.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675941#comment-17675941 ] Stefan Miklosovic commented on CASSANDRA-16418: --- could you please create a PR from your branch so we may potentially comment on it? > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 50m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default c
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675940#comment-17675940 ] Stefan Miklosovic commented on CASSANDRA-12525: --- ah wait a minute, we need to fix this from 3.0 up, right? > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra credentials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema, Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
