[jira] [Created] (CASSANDRA-19798) Update Drivers subproject internal docs
Michael Semb Wever created CASSANDRA-19798: -- Summary: Update Drivers subproject internal docs Key: CASSANDRA-19798 URL: https://issues.apache.org/jira/browse/CASSANDRA-19798 Project: Cassandra Issue Type: Sub-task Reporter: Michael Semb Wever Add the driver to the Drivers subprojects wiki page. -- 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-19797) Setup cassandra-gocql-driver docs
Michael Semb Wever created CASSANDRA-19797: -- Summary: Setup cassandra-gocql-driver docs Key: CASSANDRA-19797 URL: https://issues.apache.org/jira/browse/CASSANDRA-19797 Project: Cassandra Issue Type: Sub-task Reporter: Michael Semb Wever This may be continuing docs where they are currently, but adjusting any language about name, organisation, and location. -- 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-19799) Add .asf.yml and GH to ML connections
Michael Semb Wever created CASSANDRA-19799: -- Summary: Add .asf.yml and GH to ML connections Key: CASSANDRA-19799 URL: https://issues.apache.org/jira/browse/CASSANDRA-19799 Project: Cassandra Issue Type: Sub-task Reporter: Michael Semb Wever Ensure .asf.yml is setup per project practices. -- 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-19796) Setup cassandra-gocql-driver CI
Michael Semb Wever created CASSANDRA-19796: -- Summary: Setup cassandra-gocql-driver CI Key: CASSANDRA-19796 URL: https://issues.apache.org/jira/browse/CASSANDRA-19796 Project: Cassandra Issue Type: Sub-task Components: CI Reporter: Michael Semb Wever This may be just confirming GHA still works. -- 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-19787) Remove centos7 (and use vault mirror for ant-junit rpm download)
[ https://issues.apache.org/jira/browse/CASSANDRA-19787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19787: --- Fix Version/s: 5.1 (was: 5.x) (was: 5.0.x) Since Version: 5.0-alpha1 Source Control Link: https://github.com/apache/cassandra/commit/1e08f3bfa75e9cf303ef85ac92c080626af7c56c Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as https://github.com/apache/cassandra/commit/1e08f3bfa75e9cf303ef85ac92c080626af7c56c > Remove centos7 (and use vault mirror for ant-junit rpm download) > > > Key: CASSANDRA-19787 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19787 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.1 > > > centos7 is EOL, and its rpm repository is gone. > Use almalinux for the noboolean builds, and use the redhat vault repository > to get the ant-junit rpm. -- 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-19787) Remove centos7 (and use vault mirror for ant-junit rpm download)
[ https://issues.apache.org/jira/browse/CASSANDRA-19787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19787: --- Fix Version/s: 5.0.1 > Remove centos7 (and use vault mirror for ant-junit rpm download) > > > Key: CASSANDRA-19787 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19787 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.1, 5.1 > > > centos7 is EOL, and its rpm repository is gone. > Use almalinux for the noboolean builds, and use the redhat vault repository > to get the ant-junit rpm. -- 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-19787) Remove centos7 (and use vault mirror for ant-junit rpm download)
[ https://issues.apache.org/jira/browse/CASSANDRA-19787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19787: --- Bug Category: Parent values: Packaging(13660)Level 1 values: Package Distribution(13662) Complexity: Low Hanging Fruit Discovered By: Unit Test Severity: Critical Status: Open (was: Triage Needed) > Remove centos7 (and use vault mirror for ant-junit rpm download) > > > Key: CASSANDRA-19787 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19787 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > > centos7 is EOL, and its rpm repository is gone. > Use almalinux for the noboolean builds, and use the redhat vault repository > to get the ant-junit rpm. -- 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-19787) Remove centos7 (and use vault mirror for ant-junit rpm download)
Michael Semb Wever created CASSANDRA-19787: -- Summary: Remove centos7 (and use vault mirror for ant-junit rpm download) Key: CASSANDRA-19787 URL: https://issues.apache.org/jira/browse/CASSANDRA-19787 Project: Cassandra Issue Type: Bug Components: Packaging Reporter: Michael Semb Wever Assignee: Michael Semb Wever centos7 is EOL, and its rpm repository is gone. Use almalinux for the noboolean builds, and use the redhat vault repository to get the ant-junit rpm. -- 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-18942) Repeatable java test runs on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17867599#comment-17867599 ] Michael Semb Wever edited comment on CASSANDRA-18942 at 7/21/24 12:17 PM: -- Patch updated, so Jenkinsfile uses new parameter format. CI - post-commit profile: [^ CASSANDRA-18942_122_ci_summary.html] and [^CASSANDRA-18942_122_results_details.tar.xz] One unrelated (timeout) failure. was (Author: michaelsembwever): Patch updated, so Jenkinsfile uses new parameter format. CI - post-commit profile: [^ CASSANDRA-18942_122_ci_summary.html] and [^CASSANDRA-18942_122_results_details.tar.xz] > Repeatable java test runs on jenkins > > > Key: CASSANDRA-18942 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18942 > Project: Cassandra > Issue Type: New Feature > Components: Build, CI >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-18942_122_ci_summary.html, > CASSANDRA-18942_118_ci_summary.html, > CASSANDRA-18942_118_results_details.tar.xz, > CASSANDRA-18942_122_results_details.tar.xz, jenkins_job.xml, testJava.txt, > testJavaDocker.txt, testJavaSplits.txt > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is our policy to loop new introduced tests to avoid introducing flakies. > We also want to add the possibility to repeat a test N number of times to > test robustness, debug flakies, etc. -- 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-18942) Repeatable java test runs on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17867599#comment-17867599 ] Michael Semb Wever commented on CASSANDRA-18942: Patch updated, so Jenkinsfile uses new parameter format. CI - post-commit profile: [^ CASSANDRA-18942_122_ci_summary.html] and [^CASSANDRA-18942_122_results_details.tar.xz] > Repeatable java test runs on jenkins > > > Key: CASSANDRA-18942 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18942 > Project: Cassandra > Issue Type: New Feature > Components: Build, CI >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-18942_122_ci_summary.html, > CASSANDRA-18942_118_ci_summary.html, > CASSANDRA-18942_118_results_details.tar.xz, > CASSANDRA-18942_122_results_details.tar.xz, jenkins_job.xml, testJava.txt, > testJavaDocker.txt, testJavaSplits.txt > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is our policy to loop new introduced tests to avoid introducing flakies. > We also want to add the possibility to repeat a test N number of times to > test robustness, debug flakies, etc. -- 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-18942) Repeatable java test runs on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18942: --- Attachment: CASSANDRA-18942_122_results_details.tar.xz > Repeatable java test runs on jenkins > > > Key: CASSANDRA-18942 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18942 > Project: Cassandra > Issue Type: New Feature > Components: Build, CI >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-18942_122_ci_summary.html, > CASSANDRA-18942_118_ci_summary.html, > CASSANDRA-18942_118_results_details.tar.xz, > CASSANDRA-18942_122_results_details.tar.xz, jenkins_job.xml, testJava.txt, > testJavaDocker.txt, testJavaSplits.txt > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is our policy to loop new introduced tests to avoid introducing flakies. > We also want to add the possibility to repeat a test N number of times to > test robustness, debug flakies, etc. -- 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-18942) Repeatable java test runs on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18942: --- Attachment: CASSANDRA-18942_122_ci_summary.html > Repeatable java test runs on jenkins > > > Key: CASSANDRA-18942 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18942 > Project: Cassandra > Issue Type: New Feature > Components: Build, CI >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-18942_122_ci_summary.html, > CASSANDRA-18942_118_ci_summary.html, > CASSANDRA-18942_118_results_details.tar.xz, > CASSANDRA-18942_122_results_details.tar.xz, jenkins_job.xml, testJava.txt, > testJavaDocker.txt, testJavaSplits.txt > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is our policy to loop new introduced tests to avoid introducing flakies. > We also want to add the possibility to repeat a test N number of times to > test robustness, debug flakies, etc. -- 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-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18399:
---
Reviewers: (was: Michael Semb Wever)
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> git merge -s ours --log --no-edit cassandra-3.0
> git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
> fixes
> git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index)
> && git commit -a --amend --no-edit # Remove all changes in .circleci
> directory if you need to
> git diff --name-only origin/cassandra-3.11..HEAD # print a list of all
> changes files
> # jacek-lewandowski/CASSANDRA-18153-4.0 -> cassandra-4.0
> #
>
> git switch cassandra-4.0
> git reset --hard origin/cassandra-4.0
> git merge -s ours --log --no-edit cassandra-3.11
> git cherry-pick -n 2227c5c7af && git commit -a --amend --no-edit # 2227c5c7af
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n a71d4e3408 && git commit -a --amend --no-edit # a71d4e3408
> DO NOT MERGE - CircleCI config
> git cherry-pick -n 6dc53f4e97 && git commit -a --amend --no-edit # 6dc53f4e97
> fixes
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-4.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-4.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-4.1 -> cassandra-4.1
> #
>
> git switch cassandra-4.1
> git reset --hard origin/cassandra-4.1
> git merge -s ours --log --no-edit cassandra-4.0
> git cherry-pick -n 3584d17b36 && git commit -a --amend --no-edit # 3584d17b36
> Save host id to system.local and
[jira] [Updated] (CASSANDRA-19554) Website - Download section - Update / remove EOL dates
[ https://issues.apache.org/jira/browse/CASSANDRA-19554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19554: --- Resolution: Fixed Status: Resolved (was: Open) ci-cassandra's job builds and pushes to the asf-staging branch. Then manually (after checking cassandra.staged.apache.org) the asf-site branch is updated (hard reset) to match the asf-staging branch. ref: https://github.com/apache/cassandra-website?tab=readme-ov-file#merging-asf-staging-to-asf-site > Website - Download section - Update / remove EOL dates > -- > > Key: CASSANDRA-19554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19554 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Thomas Steinmaurer >Assignee: Himanshu Jindal >Priority: Normal > Fix For: NA > > Attachments: image-2024-04-11-13-15-52-317.png > > > Enterprise customers with on-prem Cassandra usage can be pretty nitpicking in > terms of EOL, running unsupported Cassandra versions and they often refer to > what is stated in https://cassandra.apache.org/_/download.html (as the only > source available?) and don't really think about the dependency to 5.0 GA, but > just reflecting EOL date information there. > As of April 11, 2024, the download section states the following information: > !image-2024-04-11-13-15-52-317.png! > According to that, 3.x is unmaintained, 4.0 soon to be EOL etc ... > Either remove these EOL estimates or keep them strongly maintained aligned > with an updated 5.0 GA timeline. > Thanks! -- 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-19783) In-jvm dtest to detect InstanceClassLoaderLeaks
[
https://issues.apache.org/jira/browse/CASSANDRA-19783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17867518#comment-17867518
]
Michael Semb Wever commented on CASSANDRA-19783:
+1
> In-jvm dtest to detect InstanceClassLoaderLeaks
> ---
>
> Key: CASSANDRA-19783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19783
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> It is currently very easy to add dependencies/code that cause in-jvm dtest
> {{InstanceClassLoader}} leaks, and hard to find them. These patches add a
> WeakHashSet that allows us to count the number of reachable
> InstanceClassLoaders in the in-jvm dtest API, so that we can use it in the
> ResourceLeakTest in the actual Cassandra branches in CI (it only takes 2
> iterations to find the leak recently introduced by the inclusion of the
> {{oshi.jna}} library, which was fixed in
> [https://github.com/apache/cassandra-in-jvm-dtest-api/pull/38])
> Notes:
> The trunk patch +requires+ the changes made in the in-jvm-dtest-api project
> in order to compile.
> Additionally, ResourceLeakTest#looperEverythingTest (the newly-enabled test)
> won't fail once we pick up the changes made to include `osha.jna` in the
> in-jvm-dtest-api project, so I added some "DO NOT COMMIT" code there to prove
> the test can in fact detect the leak.
--
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-19239) jvm-dtests crash on java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-19239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17867508#comment-17867508 ] Michael Semb Wever commented on CASSANDRA-19239: I've disabled all trunk CI because of this ticket. You can see that trunk CI is just thrashing here: https://ci-cassandra.apache.org/job/Cassandra-trunk/buildTimeTrend I'll (or anyone can) re-enable it when this ticket is resolved. > jvm-dtests crash on java 17 > --- > > Key: CASSANDRA-19239 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19239 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-01-23-13-11-50-313.png, > image-2024-01-23-13-12-33-954.png, screenshot-1.png, screenshot-2.png > > > This is a similar problem to the one mentioned in > https://issues.apache.org/jira/browse/CASSANDRA-15981 > I'm filling it because I've noticed the same problem on JDK17, perhaps we > should also disable unloading classes with CMS for JDK17. > However, I'm in favour of moving tests to G1 instead. -- 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-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Fix Version/s: 3.0.31
3.11.18
4.0.14
4.1.6
(was: 3.0.x)
(was: 3.11.x)
(was: 4.0.x)
(was: 4.1.x)
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.31, 3.11.18, 4.0.14, 4.1.6
>
> Attachments: CASSANDRA-19650_50_84_ci_summary.html,
> CASSANDRA-19650_50_84_ci_summary.htmlresults_details.tar.xz,
> CASSANDRA-19650_trunk_85_ci_summary.html,
> CASSANDRA-19650_trunk_85_results_details.tar.xz
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
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-19637) LWT conditions behavior on collections is inconsistent
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19637:
---
Fix Version/s: 5.0
5.1
5.0-rc1
(was: 5.0.1)
> LWT conditions behavior on collections is inconsistent
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.14, 4.1.6, 5.0-rc1, 5.0, 5.1
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> LWT conditions behaviour on collections is inconsistent in several ways
> around null values:
> 1)+Conditions comparing a collection column with a {{null}} value to a
> non-null have a different behaviour for frozen and non-frozen collection+.
> {code}UPDATE myTable SET l = ? WHERE k = 0 IF l < [1, 2]{code}
> If {{l}} is null the previous query will return {{[false, null]}} for a
> frozen collection and {{[true]}} for a non-frozen collection.
> 2) +Conditions on non-frozen collection treat empty differently from null+
> Due to the way multi-cell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multi-cell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA = []{code} the returned
> results will be {code}{false, null}{code}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations is
> to consider empty multi-cell collection input as {{null}} and reject the
> {{null}} input for non {{=}} and {{!=}} operators.
>
--
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-18886) snappy-java-1.1.10.1 vulnerability: CVE-2023-43642
[ https://issues.apache.org/jira/browse/CASSANDRA-18886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18886: --- Fix Version/s: (was: 5.0.x) > snappy-java-1.1.10.1 vulnerability: CVE-2023-43642 > -- > > Key: CASSANDRA-18886 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18886 > Project: Cassandra > Issue Type: Bug > Components: Feature/Compression >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0, 5.x > > > https://nvd.nist.gov/vuln/detail/CVE-2023-43642 > Another DoS which is probably not a huge deal, but we can upgrade. -- 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-18910) Debian packaging broken by quilt?
[
https://issues.apache.org/jira/browse/CASSANDRA-18910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18910:
---
Fix Version/s: (was: 5.0.x)
> Debian packaging broken by quilt?
> -
>
> Key: CASSANDRA-18910
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18910
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0, 5.x
>
>
> Something has changed in the docker image that is breaking the debian
> packaging in all versions, similar to this:
> {quote}
> dpkg-buildpackage: info: source package cassandra
> dpkg-buildpackage: info: source version 4.1.4-20231004git486acc68f1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by build
> dpkg-buildpackage: info: host architecture amd64
> dpkg-source --tar-ignore=.git --before-build .
> fakeroot debian/rules clean
> QUILT_PATCHES=debian/patches \
> quilt --quiltrc /dev/null pop -a -R || test $? = 1
> No patch removed
> make: *** [/usr/share/quilt/quilt.make:23: unpatch] Error 1
> dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned
> exit status 2
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18287) Test Failure: InsertUpdateIfConditionTest.testMultiExistConditionOnSameRowClustering
[
https://issues.apache.org/jira/browse/CASSANDRA-18287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18287:
---
Fix Version/s: (was: 5.0.x)
> Test Failure:
> InsertUpdateIfConditionTest.testMultiExistConditionOnSameRowClustering
>
>
> Key: CASSANDRA-18287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18287
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0, 5.x
>
>
> from
> -
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1467/testReport/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/testMultiExistConditionOnSameRowClustering_0__clusterMinVersion_3_0__cdc_jdk11_2/
> -
> https://ci-cassandra.apache.org/job/Cassandra-trunk-test-cdc/1547/jdk=jdk_11_latest,label=cassandra,split=7/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/testMultiExistConditionOnSameRowClustering_0__clusterMinVersion_3_0__cdc_jdk11/
> Stacktrace
> {noformat}
> junit.framework.AssertionFailedError: 4.2.0-SNAPSHOT boolean:false
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.lambda$data$0(InsertUpdateIfConditionTest.java:66)
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.beforeSetup(InsertUpdateIfConditionTest.java:95)
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.before(InsertUpdateIfConditionTest.java:89)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> Standard Output
> {noformat}
> INFO [main] 2023-02-21 11:54:47,699 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2023-02-21 11:54:47,703 YamlConfigurationLoader.java:124 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> WARN [main] 2023-02-21 11:54:47,951 YamlConfigurationLoader.java:427 -
> [scripted_user_defined_functions_enabled] parameters have been deprecated.
> They have new names and/or value format; For more information, please refer
> to NEWS.txt
> INFO [main] 2023-02-21 11:54:48,028 Config.java:1200 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null;
> allow_extra_insecure_udfs=false; allow_filtering_enabled=true;
> allow_insecure_udfs=false; alter_table_enabled=true;
> audit_logging_options=AuditLogOptions{enabled=false,
> logger='BinAuditLogger{}', included_keyspaces='',
> excluded_keyspaces='system,system_schema,system_virtual_schema',
> included_categories='', excluded_categories='', included_users='',
> excluded_users='', audit_logs_dir='audit', archive_command='',
> roll_cycle='HOURLY', block=true, max_queue_weight=268435456,
> max_log_size=17179869184, max_archive_retries=10};
> auth_cache_warming_enabled=false; auth_read_consistency_level=LOCAL_QUORUM;
> auth_write_consistency_level=EACH_QUORUM; authenticator=null;
> authorizer=null; auto_bootstrap=true; auto_hints_cleanup_enabled=true;
> auto_optimise_full_repair_streams=false;
> auto_optimise_inc_repair_streams=false;
> auto_optimise_preview_repair_streams=false; auto_snapshot=true;
> auto_snapshot_ttl=null; autocompaction_on_startup_enabled=true;
> automatic_sstable_upgrade=false; available_processors=-1;
> back_pressure_enabled=false; back_pressure_strategy=null;
> batch_size_fail_threshold=50KiB; batch_size_warn_threshold=5KiB;
> batchlog_replay_throttle=1024KiB; block_for_peers_in_remote_dcs=false;
> block_for_peers_timeout_in_secs=10; broadcast_address=null;
> broadcast_rpc_address=null; buffer_pool_use_heap_if_exhausted=false;
> cache_load_timeout=30s; cas_contention_timeout=1800ms; cdc_block_writes=true;
> cdc_enabled=true; cdc_free_space_check_interval=250ms;
> cdc_on_repair_enabled=true; cdc_raw_directory=build/test/cassandra/cdc_raw;
> cdc_total_space=0MiB; check_for_duplicate_rows_during_compaction=true;
> check_for_duplicate_rows_during_reads=true;
> client_encryption_options=;
> client_error_reporting_exclusions=SubnetGroups{subnets=[]};
> client_request_size_metrics_enabled=true; cluster_name=Test Cluster;
> collection_size_fail_threshold=null; collection_size_warn_threshold=null;
> column_index_cache_size=2KiB; column_index_size=4KiB;
>
[jira] [Updated] (CASSANDRA-18425) Test failure: utest: org.apache.cassandra.db.RepairedDataTombstonesTest.readTestPartitionTombstones-.jdk11
[
https://issues.apache.org/jira/browse/CASSANDRA-18425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18425:
---
Fix Version/s: (was: 5.0.x)
> Test failure: utest:
> org.apache.cassandra.db.RepairedDataTombstonesTest.readTestPartitionTombstones-.jdk11
> --
>
> Key: CASSANDRA-18425
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18425
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0, 5.x
>
>
> {{Failed 1 times in the last 5 runs. Flakiness: 25%, Stability: 80%}}
> {code}
> Error Message
> val=5
> Stacktrace
> junit.framework.AssertionFailedError: val=5
> at
> org.apache.cassandra.db.RepairedDataTombstonesTest.readTestPartitionTombstones(RepairedDataTombstonesTest.java:189)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {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-17578) Test failure: org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17578:
---
Fix Version/s: (was: 5.0.x)
> Test failure:
> org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction
> -
>
> Key: CASSANDRA-17578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17578
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Marcus Eriksson
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0, 5.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1099/testReport/org.apache.cassandra.db/RangeTombstoneTest/testRangeTombstoneCompaction_compression_2/
> {code}
> junit.framework.AssertionFailedError: Expecting open marker, got Row: name=8
> | val=8
> at
> org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction(RangeTombstoneTest.java:561)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {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-17476) Test failure: org.apache.cassandra.db.ImportTest.testImportCorrupt
[
https://issues.apache.org/jira/browse/CASSANDRA-17476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17476:
---
Fix Version/s: (was: 5.0.x)
> Test failure: org.apache.cassandra.db.ImportTest.testImportCorrupt
> --
>
> Key: CASSANDRA-17476
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17476
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
>
> There are intermittent failures in
> {{org.apache.cassandra.db.ImportTest#testImportCorrupt}} in trunk. This has
> only be hit once in Jenkins, for {{testImportCorrupt-cdc}}:
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1029/testReport/org.apache.cassandra.db/ImportTest/testImportCorrupt_cdc_3/
> {code}
> Error Message
> Data dir should contain one file expected:<1> but was:<2>
> Stacktrace
> junit.framework.AssertionFailedError: Data dir should contain one file
> expected:<1> but was:<2>
> at
> org.apache.cassandra.db.ImportTest.testCorruptHelper(ImportTest.java:349)
> at
> org.apache.cassandra.db.ImportTest.testImportCorrupt(ImportTest.java:378)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-03-21 12:53:37,982 YamlConfigurationLoader.java:103 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2022-03-21 12:53:37,987 YamlConfigurationLoader.java:124 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> INFO [main] 2022-03-21 12:53:38,203 Config.java:1119 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null; allow_extra_insecure
> ...[truncated 2109130 chars]...
> G [main] 2022-03-21 12:54:10,127 DefaultSchemaUpdateHandler.java:237 - Schema
> updated: SchemaTransformationResult{1a9fb97a-05c5-3af1-846c-72e67e40e056 -->
> 2326e45e-6c53-3f40-99c2-af12b234dfcf, diff=KeyspacesDiff{created=[],
> dropped=[KeyspaceMetadata{name=cql_test_keyspace_alt, kind=REGULAR,
> params=KeyspaceParams{durable_writes=true,
> replication=ReplicationParams{class=org.apache.cassandra.locator.SimpleStrategy,
> replication_factor=1}}, tables=[], views=[], functions=[], types=[]}],
> altered=[]}}
> {code}
> However, it's possible to hit the failure on both {{testImportCorrupt}} and
> {{testImportCorruptWithoutValidationWithCopying}} with the test multiplexer,
> although with a very low flakiness:
> https://app.circleci.com/pipelines/github/adelapena/cassandra/1412/workflows/f2ca69cd-f1e3-450f-b444-a6f9fe6d1fd4/jobs/14186/tests
--
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-18151) Test failure: org.apache.cassandra.distributed.test.SchemaTest timeout
[ https://issues.apache.org/jira/browse/CASSANDRA-18151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18151: --- Fix Version/s: (was: 5.0.x) > Test failure: 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 >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0 > > > 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] [Updated] (CASSANDRA-18325) Test failure: dtest.bootstrap_test.TestBootstrap.test_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18325:
---
Fix Version/s: (was: 5.0.x)
> Test failure: dtest.bootstrap_test.TestBootstrap.test_cleanup
> -
>
> Key: CASSANDRA-18325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18325
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Maxwell Guo
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0, 5.x
>
>
>
> {code:java}
> assert not True
> + where True = 0x7f5b16fda070>>()
> + where 0x7f5b16fda070>> = .is_set
> Stacktrace
> self =
> def test_cleanup(self):
> """
> @jira_ticket CASSANDRA-11179
> Make sure we remove processed files during cleanup
> """
> cluster = self.cluster
> cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
> 'True')
> cluster.set_configuration_options(values=
> {'concurrent_compactors': 4}
> )
> cluster.populate(1)
> cluster.start()
> node1, = cluster.nodelist()
> for x in range(0, 5):
> node1.stress(['write', 'n=100k', 'no-warmup', '-schema',
> 'compaction(strategy=SizeTieredCompactionStrategy,enabled=false)',
> 'replication(factor=1)', '-rate', 'threads=10'])
> node1.flush()
> node2 = new_node(cluster)
> node2.start(wait_for_binary_proto=True)
> event = threading.Event()
> failed = threading.Event()
> jobs = 1
> thread = threading.Thread(target=self._monitor_datadir, args=(node1, event,
> len(node1.get_sstables("keyspace1", "standard1")), jobs, failed))
> thread.setDaemon(True)
> thread.start()
> node1.nodetool("cleanup -j {} keyspace1 standard1".format(jobs))
> event.set()
> thread.join()
> > assert not failed.is_set()
> E assert not True
> E + where True = 0x7f5b16fda070>>()
> E + where 0x7f5b16fda070>> = .is_set
> bootstrap_test.py:912: AssertionError
> {code}
>
> failed twice
--
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-18918) Test failure: secondary_indexes_test.TestPreJoinCallback.test_resume
[
https://issues.apache.org/jira/browse/CASSANDRA-18918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18918:
---
Fix Version/s: (was: 5.0.x)
> Test failure: secondary_indexes_test.TestPreJoinCallback.test_resume
>
>
> Key: CASSANDRA-18918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18918
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0, 5.x
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/60/testReport/dtest-novnode.secondary_indexes_test/TestPreJoinCallback/test_resume/
> {quote}
> failed on teardown with "Failed: Unexpected error found in node logs (see
> stdout for full details). Errors: [[node2] 'ERROR
> [Stream-Deserializer-/127.0.0.1:7000-ffd39504] 2023-10-09 16:12:59,153
> StreamSession.java:702 - [Stream #b69e6f80-66be-11ee-b813-3bca425f16a7]
> Socket closed before session completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:833)']"
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18325) Test failure: dtest.bootstrap_test.TestBootstrap.test_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18325:
---
Fix Version/s: 5.0
> Test failure: dtest.bootstrap_test.TestBootstrap.test_cleanup
> -
>
> Key: CASSANDRA-18325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18325
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Maxwell Guo
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0, 5.0.x, 5.x
>
>
>
> {code:java}
> assert not True
> + where True = 0x7f5b16fda070>>()
> + where 0x7f5b16fda070>> = .is_set
> Stacktrace
> self =
> def test_cleanup(self):
> """
> @jira_ticket CASSANDRA-11179
> Make sure we remove processed files during cleanup
> """
> cluster = self.cluster
> cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
> 'True')
> cluster.set_configuration_options(values=
> {'concurrent_compactors': 4}
> )
> cluster.populate(1)
> cluster.start()
> node1, = cluster.nodelist()
> for x in range(0, 5):
> node1.stress(['write', 'n=100k', 'no-warmup', '-schema',
> 'compaction(strategy=SizeTieredCompactionStrategy,enabled=false)',
> 'replication(factor=1)', '-rate', 'threads=10'])
> node1.flush()
> node2 = new_node(cluster)
> node2.start(wait_for_binary_proto=True)
> event = threading.Event()
> failed = threading.Event()
> jobs = 1
> thread = threading.Thread(target=self._monitor_datadir, args=(node1, event,
> len(node1.get_sstables("keyspace1", "standard1")), jobs, failed))
> thread.setDaemon(True)
> thread.start()
> node1.nodetool("cleanup -j {} keyspace1 standard1".format(jobs))
> event.set()
> thread.join()
> > assert not failed.is_set()
> E assert not True
> E + where True = 0x7f5b16fda070>>()
> E + where 0x7f5b16fda070>> = .is_set
> bootstrap_test.py:912: AssertionError
> {code}
>
> failed twice
--
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-18287) Test Failure: InsertUpdateIfConditionTest.testMultiExistConditionOnSameRowClustering
[
https://issues.apache.org/jira/browse/CASSANDRA-18287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18287:
---
Fix Version/s: 5.0
> Test Failure:
> InsertUpdateIfConditionTest.testMultiExistConditionOnSameRowClustering
>
>
> Key: CASSANDRA-18287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18287
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0, 5.0.x, 5.x
>
>
> from
> -
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1467/testReport/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/testMultiExistConditionOnSameRowClustering_0__clusterMinVersion_3_0__cdc_jdk11_2/
> -
> https://ci-cassandra.apache.org/job/Cassandra-trunk-test-cdc/1547/jdk=jdk_11_latest,label=cassandra,split=7/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/testMultiExistConditionOnSameRowClustering_0__clusterMinVersion_3_0__cdc_jdk11/
> Stacktrace
> {noformat}
> junit.framework.AssertionFailedError: 4.2.0-SNAPSHOT boolean:false
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.lambda$data$0(InsertUpdateIfConditionTest.java:66)
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.beforeSetup(InsertUpdateIfConditionTest.java:95)
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.before(InsertUpdateIfConditionTest.java:89)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> Standard Output
> {noformat}
> INFO [main] 2023-02-21 11:54:47,699 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> DEBUG [main] 2023-02-21 11:54:47,703 YamlConfigurationLoader.java:124 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml
> WARN [main] 2023-02-21 11:54:47,951 YamlConfigurationLoader.java:427 -
> [scripted_user_defined_functions_enabled] parameters have been deprecated.
> They have new names and/or value format; For more information, please refer
> to NEWS.txt
> INFO [main] 2023-02-21 11:54:48,028 Config.java:1200 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null;
> allow_extra_insecure_udfs=false; allow_filtering_enabled=true;
> allow_insecure_udfs=false; alter_table_enabled=true;
> audit_logging_options=AuditLogOptions{enabled=false,
> logger='BinAuditLogger{}', included_keyspaces='',
> excluded_keyspaces='system,system_schema,system_virtual_schema',
> included_categories='', excluded_categories='', included_users='',
> excluded_users='', audit_logs_dir='audit', archive_command='',
> roll_cycle='HOURLY', block=true, max_queue_weight=268435456,
> max_log_size=17179869184, max_archive_retries=10};
> auth_cache_warming_enabled=false; auth_read_consistency_level=LOCAL_QUORUM;
> auth_write_consistency_level=EACH_QUORUM; authenticator=null;
> authorizer=null; auto_bootstrap=true; auto_hints_cleanup_enabled=true;
> auto_optimise_full_repair_streams=false;
> auto_optimise_inc_repair_streams=false;
> auto_optimise_preview_repair_streams=false; auto_snapshot=true;
> auto_snapshot_ttl=null; autocompaction_on_startup_enabled=true;
> automatic_sstable_upgrade=false; available_processors=-1;
> back_pressure_enabled=false; back_pressure_strategy=null;
> batch_size_fail_threshold=50KiB; batch_size_warn_threshold=5KiB;
> batchlog_replay_throttle=1024KiB; block_for_peers_in_remote_dcs=false;
> block_for_peers_timeout_in_secs=10; broadcast_address=null;
> broadcast_rpc_address=null; buffer_pool_use_heap_if_exhausted=false;
> cache_load_timeout=30s; cas_contention_timeout=1800ms; cdc_block_writes=true;
> cdc_enabled=true; cdc_free_space_check_interval=250ms;
> cdc_on_repair_enabled=true; cdc_raw_directory=build/test/cassandra/cdc_raw;
> cdc_total_space=0MiB; check_for_duplicate_rows_during_compaction=true;
> check_for_duplicate_rows_during_reads=true;
> client_encryption_options=;
> client_error_reporting_exclusions=SubnetGroups{subnets=[]};
> client_request_size_metrics_enabled=true; cluster_name=Test Cluster;
> collection_size_fail_threshold=null; collection_size_warn_threshold=null;
> column_index_cache_size=2KiB; column_index_size=4KiB;
>
[jira] [Updated] (CASSANDRA-18918) Test failure: secondary_indexes_test.TestPreJoinCallback.test_resume
[
https://issues.apache.org/jira/browse/CASSANDRA-18918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18918:
---
Fix Version/s: 5.0
> Test failure: secondary_indexes_test.TestPreJoinCallback.test_resume
>
>
> Key: CASSANDRA-18918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18918
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0, 5.0.x, 5.x
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/60/testReport/dtest-novnode.secondary_indexes_test/TestPreJoinCallback/test_resume/
> {quote}
> failed on teardown with "Failed: Unexpected error found in node logs (see
> stdout for full details). Errors: [[node2] 'ERROR
> [Stream-Deserializer-/127.0.0.1:7000-ffd39504] 2023-10-09 16:12:59,153
> StreamSession.java:702 - [Stream #b69e6f80-66be-11ee-b813-3bca425f16a7]
> Socket closed before session completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:833)']"
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18425) Test failure: utest: org.apache.cassandra.db.RepairedDataTombstonesTest.readTestPartitionTombstones-.jdk11
[
https://issues.apache.org/jira/browse/CASSANDRA-18425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18425:
---
Fix Version/s: 5.0
> Test failure: utest:
> org.apache.cassandra.db.RepairedDataTombstonesTest.readTestPartitionTombstones-.jdk11
> --
>
> Key: CASSANDRA-18425
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18425
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0, 5.0.x, 5.x
>
>
> {{Failed 1 times in the last 5 runs. Flakiness: 25%, Stability: 80%}}
> {code}
> Error Message
> val=5
> Stacktrace
> junit.framework.AssertionFailedError: val=5
> at
> org.apache.cassandra.db.RepairedDataTombstonesTest.readTestPartitionTombstones(RepairedDataTombstonesTest.java:189)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {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-18886) snappy-java-1.1.10.1 vulnerability: CVE-2023-43642
[ https://issues.apache.org/jira/browse/CASSANDRA-18886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18886: --- Fix Version/s: 5.0 > snappy-java-1.1.10.1 vulnerability: CVE-2023-43642 > -- > > Key: CASSANDRA-18886 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18886 > Project: Cassandra > Issue Type: Bug > Components: Feature/Compression >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0, 5.0.x, 5.x > > > https://nvd.nist.gov/vuln/detail/CVE-2023-43642 > Another DoS which is probably not a huge deal, but we can upgrade. -- 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-18910) Debian packaging broken by quilt?
[
https://issues.apache.org/jira/browse/CASSANDRA-18910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18910:
---
Fix Version/s: 5.0
> Debian packaging broken by quilt?
> -
>
> Key: CASSANDRA-18910
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18910
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0, 5.0.x, 5.x
>
>
> Something has changed in the docker image that is breaking the debian
> packaging in all versions, similar to this:
> {quote}
> dpkg-buildpackage: info: source package cassandra
> dpkg-buildpackage: info: source version 4.1.4-20231004git486acc68f1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by build
> dpkg-buildpackage: info: host architecture amd64
> dpkg-source --tar-ignore=.git --before-build .
> fakeroot debian/rules clean
> QUILT_PATCHES=debian/patches \
> quilt --quiltrc /dev/null pop -a -R || test $? = 1
> No patch removed
> make: *** [/usr/share/quilt/quilt.make:23: unpatch] Error 1
> dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned
> exit status 2
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18702) Add jmh microbenchmarks to eclipse IDE
[ https://issues.apache.org/jira/browse/CASSANDRA-18702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18702: --- Fix Version/s: 5.0 5.0-alpha1 > Add jmh microbenchmarks to eclipse IDE > -- > > Key: CASSANDRA-18702 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18702 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0-alpha1, 5.0, 5.0.x > > > Currently jmh tests are not being picked up by the Eclipse IDE. -- 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-17578) Test failure: org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17578:
---
Fix Version/s: 5.0
> Test failure:
> org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction
> -
>
> Key: CASSANDRA-17578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17578
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Marcus Eriksson
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0, 5.0.x, 5.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1099/testReport/org.apache.cassandra.db/RangeTombstoneTest/testRangeTombstoneCompaction_compression_2/
> {code}
> junit.framework.AssertionFailedError: Expecting open marker, got Row: name=8
> | val=8
> at
> org.apache.cassandra.db.RangeTombstoneTest.testRangeTombstoneCompaction(RangeTombstoneTest.java:561)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {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-18393) Flaky test: org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.testConditionalUpdate[1: clusterMinVersion=3.11]-compression.jdk1.8 on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-18393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18393:
---
Fix Version/s: (was: 5.0.x)
> Flaky test:
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.testConditionalUpdate[1:
> clusterMinVersion=3.11]-compression.jdk1.8 on trunk
>
>
> Key: CASSANDRA-18393
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18393
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
>
> Failed 1 times in the last 1 runs. Flakiness: 0%, Stability: 0%
> {code}
> Error Message
> 5.0.0-SNAPSHOT boolean:false
> Stacktrace
> junit.framework.AssertionFailedError: 5.0.0-SNAPSHOT boolean:false
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.lambda$data$1(InsertUpdateIfConditionTest.java:70)
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.beforeSetup(InsertUpdateIfConditionTest.java:95)
> at
> org.apache.cassandra.cql3.validation.operations.InsertUpdateIfConditionTest.before(InsertUpdateIfConditionTest.java:89)
> {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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18853: --- Fix Version/s: 5.0-alpha1 > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0-alpha1, 5.0, 5.0.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI is expensive. It's easy to avoid by > making Idea mark them as errors -- 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-18786) Javadoc BigFormat
[ https://issues.apache.org/jira/browse/CASSANDRA-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18786: --- Fix Version/s: 5.0 5.0-alpha1 > Javadoc BigFormat > - > > Key: CASSANDRA-18786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18786 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Javadoc >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0-alpha1, 5.0, 5.0.x > > Attachments: screenshot-1.png > > > This ticket intends to go through the current sstables code and javadoc the > format at high-level. -- 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-18707) Test failure: junit.framework.TestSuite.org.apache.cassandra.distributed.test.CASMultiDCTest-.jdk11
[
https://issues.apache.org/jira/browse/CASSANDRA-18707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18707:
---
Fix Version/s: (was: 5.0.x)
> Test failure:
> junit.framework.TestSuite.org.apache.cassandra.distributed.test.CASMultiDCTest-.jdk11
>
>
>
> Key: CASSANDRA-18707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18707
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.12, 4.1.4, 5.0-alpha1, 5.0
>
> Attachments: TESTS-TestSuites.xml.xz
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1650/testReport/junit.framework/TestSuite/org_apache_cassandra_distributed_test_CASMultiDCTest__jdk11/]
> h3.
> {code:java}
> Error Message
> Schema agreement not reached. Schema versions of the instances:
> [ef1c8e05-a06d-388d-a46d-53cc22a94762, 6c386108-1805-3985-b48e-8016012a0207,
> 6c386108-1805-3985-b48e-8016012a0207, ef1c8e05-a06d-388d-a46d-53cc22a94762]
> Stacktrace
> java.lang.IllegalStateException: Schema agreement not reached. Schema
> versions of the instances: [ef1c8e05-a06d-388d-a46d-53cc22a94762,
> 6c386108-1805-3985-b48e-8016012a0207, 6c386108-1805-3985-b48e-8016012a0207,
> ef1c8e05-a06d-388d-a46d-53cc22a94762] at
> org.apache.cassandra.distributed.impl.AbstractCluster$ChangeMonitor.waitForCompletion(AbstractCluster.java:907)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.lambda$schemaChange$8(AbstractCluster.java:836)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) 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}
>
--
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-18765) Add CASSANDRA-14227 to 5.0 new features page
[ https://issues.apache.org/jira/browse/CASSANDRA-18765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18765: --- Fix Version/s: (was: 5.0.x) > Add CASSANDRA-14227 to 5.0 new features page > > > Key: CASSANDRA-18765 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18765 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > > The [page|https://cassandra.apache.org/doc/trunk/cassandra/new/index.html] > listing the 5.0 new features is not mentioning the extended TTL implemented > in CASSANDRA-14227 -- 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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18853: --- Fix Version/s: (was: 5.0.x) > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI is expensive. It's easy to avoid by > making Idea mark them as errors -- 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-18707) Test failure: junit.framework.TestSuite.org.apache.cassandra.distributed.test.CASMultiDCTest-.jdk11
[
https://issues.apache.org/jira/browse/CASSANDRA-18707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18707:
---
Fix Version/s: 5.0-alpha1
> Test failure:
> junit.framework.TestSuite.org.apache.cassandra.distributed.test.CASMultiDCTest-.jdk11
>
>
>
> Key: CASSANDRA-18707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18707
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.12, 4.1.4, 5.0-alpha1, 5.0, 5.0.x
>
> Attachments: TESTS-TestSuites.xml.xz
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1650/testReport/junit.framework/TestSuite/org_apache_cassandra_distributed_test_CASMultiDCTest__jdk11/]
> h3.
> {code:java}
> Error Message
> Schema agreement not reached. Schema versions of the instances:
> [ef1c8e05-a06d-388d-a46d-53cc22a94762, 6c386108-1805-3985-b48e-8016012a0207,
> 6c386108-1805-3985-b48e-8016012a0207, ef1c8e05-a06d-388d-a46d-53cc22a94762]
> Stacktrace
> java.lang.IllegalStateException: Schema agreement not reached. Schema
> versions of the instances: [ef1c8e05-a06d-388d-a46d-53cc22a94762,
> 6c386108-1805-3985-b48e-8016012a0207, 6c386108-1805-3985-b48e-8016012a0207,
> ef1c8e05-a06d-388d-a46d-53cc22a94762] at
> org.apache.cassandra.distributed.impl.AbstractCluster$ChangeMonitor.waitForCompletion(AbstractCluster.java:907)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.lambda$schemaChange$8(AbstractCluster.java:836)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) 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}
>
--
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-18929) CEP-15: (C*) Implement TopologySorter to prioritise hosts based on DynamicSnitch and/or topology layout
[ https://issues.apache.org/jira/browse/CASSANDRA-18929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18929: --- Fix Version/s: 5.0 5.0-alpha1 > CEP-15: (C*) Implement TopologySorter to prioritise hosts based on > DynamicSnitch and/or topology layout > --- > > Key: CASSANDRA-18929 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18929 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.0-alpha1, 5.0, 5.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > Implement TopologySorter to prioritise hosts based on DynamicSnitch and/or > topology layout -- 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-18786) Javadoc BigFormat
[ https://issues.apache.org/jira/browse/CASSANDRA-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18786: --- Fix Version/s: (was: 5.0.x) > Javadoc BigFormat > - > > Key: CASSANDRA-18786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18786 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Javadoc >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: screenshot-1.png > > > This ticket intends to go through the current sstables code and javadoc the > format at high-level. -- 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-18929) CEP-15: (C*) Implement TopologySorter to prioritise hosts based on DynamicSnitch and/or topology layout
[ https://issues.apache.org/jira/browse/CASSANDRA-18929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18929: --- Fix Version/s: (was: 5.0.x) > CEP-15: (C*) Implement TopologySorter to prioritise hosts based on > DynamicSnitch and/or topology layout > --- > > Key: CASSANDRA-18929 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18929 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Implement TopologySorter to prioritise hosts based on DynamicSnitch and/or > topology layout -- 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-18941) Support max SSTable size in sorted CQLSSTableWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-18941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18941: --- Fix Version/s: 5.0 5.0-alpha2 > Support max SSTable size in sorted CQLSSTableWriter > --- > > Key: CASSANDRA-18941 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18941 > Project: Cassandra > Issue Type: Improvement > Components: Tool/sstable >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0-alpha2, 5.0, 5.0.x, 5.x > > Attachments: ci_summary-CASSANDRA-18941-cassandra-4.0.html, > ci_summary-CASSANDRA-18941-cassandra-4.1.html, > ci_summary-CASSANDRA-18941-cassandra-5.0.html, > ci_summary-CASSANDRA-18941-trunk.html, > result_details-CASSANDRA-18941-cassandra-4.0.tar.gz, > result_details-CASSANDRA-18941-cassandra-4.1.tar.gz, > result_details-CASSANDRA-18941-cassandra-5.0.tar.gz, > result_details-CASSANDRA-18941-trunk.tar.gz > > Time Spent: 5.5h > Remaining Estimate: 0h > > The CQLSSTableWriter can produce a series of SSTables with a bounded size in > the unsorted mode. The functionality is missing in the sorted > CQLSSTableWriter. > It will be great to bringing the parity to the sorted mode, so that it is > able to produce a series of size-bounded SSTable, instead of a single but > giant one. > Unlike the unsorted CQLSSTableWriter, the max SSTable size in the sorted > writer does not require buffering. -- 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-18949) Test failure: org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18949:
---
Fix Version/s: (was: 5.0.x)
> Test failure:
> org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
> ---
>
> Key: CASSANDRA-18949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18949
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.0-alpha2, 5.0-beta1, 5.0, 5.x
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1747/testReport/org.apache.cassandra.tools.nodetool/ClearSnapshotTest/testClearSnapshot_RemoveByName__jdk11_arch_x86_64_python2_7/]
> h3.
> {code:java}
> Error Message
> [bin/nodetool, -p, 36753, -h, 127.0.0.1, snapshot, -t, some-name] exited with
> code 2 stderr: error: Unknown keyspace keyspace_04 -- StackTrace --
> java.lang.AssertionError: Unknown keyspace keyspace_04 at
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324) at
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162) at
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)
> at
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:162) at
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151) at
> com.google.common.collect.Iterators$6.transform(Iterators.java:828) at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:52)
> at
> org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4356)
> at
> org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4221)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at
> jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260) at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:809)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:827)
> at java.base/jdk.internal.reflect.GeneratedMethodAccessor16.invoke(Unknown
> Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200) at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197) at
> java.base/java.security.AccessController.doPrivileged(Native Method) at
> java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
> at
>
[jira] [Updated] (CASSANDRA-19111) Add j17|j11_dtests_repeat and j17|j11_dtests_vnode_repeat among circle jobs
[ https://issues.apache.org/jira/browse/CASSANDRA-19111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19111: --- Fix Version/s: (was: 5.0.x) > Add j17|j11_dtests_repeat and j17|j11_dtests_vnode_repeat among circle jobs > --- > > Key: CASSANDRA-19111 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19111 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0-alpha2, 5.0, 5.x > > > j17_dtests_repeat and j17_dtests_vnode_repeat do exist in circleci but they > are not referenced in workflows. I basically can not run multiplexer on > dtests in circle. > Same happens for their j11 counterparts. > Same applies for 3.0 where j8_dtests_repeat is, again, not referenced in > workflows. I guess it will be same for all branches we have. -- 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-18941) Support max SSTable size in sorted CQLSSTableWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-18941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18941: --- Fix Version/s: (was: 5.0.x) > Support max SSTable size in sorted CQLSSTableWriter > --- > > Key: CASSANDRA-18941 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18941 > Project: Cassandra > Issue Type: Improvement > Components: Tool/sstable >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0-alpha2, 5.0, 5.x > > Attachments: ci_summary-CASSANDRA-18941-cassandra-4.0.html, > ci_summary-CASSANDRA-18941-cassandra-4.1.html, > ci_summary-CASSANDRA-18941-cassandra-5.0.html, > ci_summary-CASSANDRA-18941-trunk.html, > result_details-CASSANDRA-18941-cassandra-4.0.tar.gz, > result_details-CASSANDRA-18941-cassandra-4.1.tar.gz, > result_details-CASSANDRA-18941-cassandra-5.0.tar.gz, > result_details-CASSANDRA-18941-trunk.tar.gz > > Time Spent: 5.5h > Remaining Estimate: 0h > > The CQLSSTableWriter can produce a series of SSTables with a bounded size in > the unsorted mode. The functionality is missing in the sorted > CQLSSTableWriter. > It will be great to bringing the parity to the sorted mode, so that it is > able to produce a series of size-bounded SSTable, instead of a single but > giant one. > Unlike the unsorted CQLSSTableWriter, the max SSTable size in the sorted > writer does not require buffering. -- 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-19111) Add j17|j11_dtests_repeat and j17|j11_dtests_vnode_repeat among circle jobs
[ https://issues.apache.org/jira/browse/CASSANDRA-19111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19111: --- Fix Version/s: 5.0 5.0-alpha2 > Add j17|j11_dtests_repeat and j17|j11_dtests_vnode_repeat among circle jobs > --- > > Key: CASSANDRA-19111 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19111 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0-alpha2, 5.0, 5.0.x, 5.x > > > j17_dtests_repeat and j17_dtests_vnode_repeat do exist in circleci but they > are not referenced in workflows. I basically can not run multiplexer on > dtests in circle. > Same happens for their j11 counterparts. > Same applies for 3.0 where j8_dtests_repeat is, again, not referenced in > workflows. I guess it will be same for all branches we have. -- 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-18949) Test failure: org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18949:
---
Fix Version/s: 5.0-alpha2
> Test failure:
> org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
> ---
>
> Key: CASSANDRA-18949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18949
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.0-alpha2, 5.0-beta1, 5.0, 5.0.x, 5.x
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1747/testReport/org.apache.cassandra.tools.nodetool/ClearSnapshotTest/testClearSnapshot_RemoveByName__jdk11_arch_x86_64_python2_7/]
> h3.
> {code:java}
> Error Message
> [bin/nodetool, -p, 36753, -h, 127.0.0.1, snapshot, -t, some-name] exited with
> code 2 stderr: error: Unknown keyspace keyspace_04 -- StackTrace --
> java.lang.AssertionError: Unknown keyspace keyspace_04 at
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324) at
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162) at
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)
> at
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:162) at
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151) at
> com.google.common.collect.Iterators$6.transform(Iterators.java:828) at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:52)
> at
> org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4356)
> at
> org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4221)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at
> jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260) at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:809)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:827)
> at java.base/jdk.internal.reflect.GeneratedMethodAccessor16.invoke(Unknown
> Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200) at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197) at
> java.base/java.security.AccessController.doPrivileged(Native Method) at
> java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
> at
>
[jira] [Updated] (CASSANDRA-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19009: --- Fix Version/s: (was: 5.0.x) > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0-rc1, 5.0 > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- 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-18288) Test Failure: TopPartitionsTest.basicRegularTombstonesTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18288:
---
Fix Version/s: (was: 5.0.x)
> Test Failure: TopPartitionsTest.basicRegularTombstonesTest
> --
>
> Key: CASSANDRA-18288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18288
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0-rc1, 5.0, 5.x
>
>
> from
> -
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1469/testReport/org.apache.cassandra.distributed.test/TopPartitionsTest/basicRegularTombstonesTest_Incremental___jdk11/
> -
> https://ci-cassandra.apache.org/job/Cassandra-trunk-jvm-dtest/1534/jdk=jdk_11_latest,label=cassandra,split=8/testReport/junit/org.apache.cassandra.distributed.test/TopPartitionsTest/basicRegularTombstonesTest_Incremental___jdk11/
> Stacktrace
> {noformat}
> java.lang.RuntimeException:
> at org.psjava.util.AssertStatus.assertTrue(AssertStatus.java:18)
> at org.psjava.util.AssertStatus.assertTrue(AssertStatus.java:5)
> at
> org.apache.cassandra.distributed.test.TopPartitionsTest.lambda$basicRegularTombstonesTest$e2f532b5$1(TopPartitionsTest.java:226)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> 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)
> {noformat}
> Standard Output
> {noformat}
> INFO [main] 2023-02-25 00:15:20,407 Reflections.java:219 -
> Reflections took 1661 ms to scan 9 urls, producing 1832 keys and 7268 values
> INFO [main] 2023-02-25 00:15:21,602 Reflections.java:219 -
> Reflections took 1131 ms to scan 9 urls, producing 1832 keys and 7268 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2023-02-25 00:15:22,419 InternalLoggerFactory.java:63 -
> Using SLF4J as the default logging framework
> DEBUG [main] node1 2023-02-25 00:15:22,426 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] node1 2023-02-25 00:15:22,427 PlatformDependent0.java:897 - Java
> version: 11
> DEBUG [main] node1 2023-02-25 00:15:22,428 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] node1 2023-02-25 00:15:22,429 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> DEBUG [main] node1 2023-02-25 00:15:22,430 PlatformDependent0.java:192 -
> java.nio.Buffer.address: available
> DEBUG [main] node1 2023-02-25 00:15:22,431 PlatformDependent0.java:257 -
> direct buffer constructor: available
> DEBUG [main] node1 2023-02-25 00:15:22,432 PlatformDependent0.java:331 -
> java.nio.Bits.unaligned: available, true
> DEBUG [main] node1 2023-02-25 00:15:22,434 PlatformDependent0.java:393 -
> jdk.internal.misc.Unsafe.allocateUninitializedArray(int): available
> DEBUG [main] node1 2023-02-25 00:15:22,435 PlatformDependent0.java:403 -
> java.nio.DirectByteBuffer.(long, int): available
> DEBUG [main] node1 2023-02-25 00:15:22,435 PlatformDependent.java:1079 -
> sun.misc.Unsafe: available
> DEBUG [main] node1 2023-02-25 00:15:22,448 PlatformDependent.java:1181 -
> maxDirectMemory: 1056309248 bytes (maybe)
> DEBUG [main] node1 2023-02-25 00:15:22,449 PlatformDependent.java:1200 -
> -Dio.netty.tmpdir: /home/cassandra/cassandra/tmp (java.io.tmpdir)
> DEBUG [main] node1 2023-02-25 00:15:22,449 PlatformDependent.java:1279 -
> -Dio.netty.bitMode: 64 (sun.arch.data.model)
> DEBUG [main] node1 2023-02-25 00:15:22,450 PlatformDependent.java:177 -
> -Dio.netty.maxDirectMemory: 1056309248 bytes
> DEBUG [main] node1 2023-02-25 00:15:22,451 PlatformDependent.java:184 -
> -Dio.netty.uninitializedArrayAllocationThreshold: 1024
> DEBUG [main] node1 2023-02-25 00:15:22,452 CleanerJava9.java:71 -
> java.nio.ByteBuffer.cleaner(): available
> DEBUG [main] node1 2023-02-25 00:15:22,453 PlatformDependent.java:204 -
> -Dio.netty.noPreferDirect: false
> DEBUG [main] node2 2023-02-25 00:15:23,126 InternalLoggerFactory.java:63 -
> Using SLF4J as the default logging framework
> DEBUG [main] node2 2023-02-25 00:15:23,133 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] node2 2023-02-25 00:15:23,134
[jira] [Updated] (CASSANDRA-19550) Test failure: org.apache.cassandra.cql3.validation.operations.DropRecreateAndRestoreTest.testCreateWithIdRestore
[
https://issues.apache.org/jira/browse/CASSANDRA-19550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19550:
---
Fix Version/s: (was: 5.0.x)
> Test failure:
> org.apache.cassandra.cql3.validation.operations.DropRecreateAndRestoreTest.testCreateWithIdRestore
>
>
> Key: CASSANDRA-19550
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19550
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc1, 5.0
>
>
> {noformat}
> junit.framework.AssertionFailedError: Got less rows than expected. Expected 2
> but got 1
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1256)
> at
> org.apache.cassandra.cql3.validation.operations.DropRecreateAndRestoreTest.testCreateWithIdRestore(DropRecreateAndRestoreTest.java:80)
> {noformat}
> As seen at
> https://app.circleci.com/pipelines/github/driftx/cassandra/1579/workflows/03c0b2f6-d84f-440d-baad-bf323810a292/jobs/84088
--
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-18222) Test failure: org.apache.cassandra.distributed.test.accord.AccordIntegrationTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18222: --- Fix Version/s: (was: 5.0.x) > Test failure: > org.apache.cassandra.distributed.test.accord.AccordIntegrationTest > > > Key: CASSANDRA-18222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18222 > Project: Cassandra > Issue Type: Bug > Components: Accord, CI >Reporter: David Capwell >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.0-rc1, 5.0, 5.x > > > The accord integration tests are currently flaky due to Preempt happening (we > convert that to a timeout). We need to address this to make sure the tests > are stable. > One solution may be make SimpleProgressLog’s frequency run different for > jvm-dtest (likely to depend on CASSANDRA-18221 ), this would be similar to > what we already do as timeouts maybe larger in jvm-dtest due to the extra > complexity running multiple processes in the same JVM. Another solution may > be to have the client coordinator “attach” to the new coordinator, this would > avoid the user being impacted by this preempt when the coordinator is > healthy. > Example: > https://app.circleci.com/pipelines/github/dcapwell/cassandra/1822/workflows/0d92898f-ad7d-4a7d-9198-3a7ce844ee93/jobs/16464 -- 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-19215) "Query start time" in native transport request threads should be the task enqueue time
[ https://issues.apache.org/jira/browse/CASSANDRA-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19215: --- Fix Version/s: (was: 5.0.x) > "Query start time" in native transport request threads should be the task > enqueue time > -- > > Key: CASSANDRA-19215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19215 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Runtian Liu >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0-rc1, 5.0, 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > > Recently, our Cassandra 4.0.6 cluster experienced an outage due to a surge in > expensive traffic from the application side. This surge involved a large > volume of costly read queries, which took a considerable amount of time to > process on the server side. The client had timeout settings; if a request > timed out, it might trigger the sending of new requests. Since the server > nodes were overloaded, numerous nodes had hundreds of thousands of tasks > queued in the Native-Transport-Request pending queue. I expected that once > the application ceased sending requests, the server node would quickly return > to normal, as most requests in the queue were over half an hour old and > should have timed out rapidly, clearing the queue. However, it actually took > an hour to clear the native transport's pending queue, even with native > transport disabled. Upon examining the code, I noticed that for read/write > requests, the > [queryStartNanoTime|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/transport/Dispatcher.java#L78], > which determines if a request has timed out, only begins when the task > starts processing. This means that no matter how long a request has been > pending, it doesn't contribute to the timeout. I believe this is incorrect. > The timer should start when the Cassandra server receives the request or when > it enqueues the task, not when the request/task begins processing. This way, > an overloaded node with many pending tasks can quickly discard timed-out > requests and recover from an outage once new requests stop. -- 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-18808) netty-handler vulnerability: CVE-2023-4586
[
https://issues.apache.org/jira/browse/CASSANDRA-18808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18808:
---
Fix Version/s: 5.0
5.0-rc1
> netty-handler vulnerability: CVE-2023-4586
> --
>
> Key: CASSANDRA-18808
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18808
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc1, 5.0, 5.0.x, 5.x
>
>
> This is failing OWASP:
> {noformat}
> Dependency-Check Failure:
> One or more dependencies were identified with vulnerabilities that have a
> CVSS score greater than or equal to '1.0':
> netty-handler-4.1.96.Final.jar: CVE-2023-4586
> {noformat}
--
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-19491) decommissioned nodes show as UNREACHABLE in describecluster afterward
[ https://issues.apache.org/jira/browse/CASSANDRA-19491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19491: --- Fix Version/s: (was: 5.0.x) > decommissioned nodes show as UNREACHABLE in describecluster afterward > - > > Key: CASSANDRA-19491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19491 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Membership >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0-rc1, 5.0 > > > [~urandom] noticed this happening in his cluster and I have been able to > reproduce with a modified dtest. -- 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-19529) Latency regression on 4.1 comparing to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19529: --- Fix Version/s: 5.0 5.0-rc1 > Latency regression on 4.1 comparing to 4.0 > -- > > Key: CASSANDRA-19529 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19529 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Nicolas Henneaux >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.1.x, 5.0-rc1, 5.0, 5.0.x, 5.x > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > When upgrading from Cassandra 4.0.10 to 4.1.3, I noticed an increase from > application point of view latency from ~8ms to ~15ms when upgrading to > Cassandra. The latency includes 3 simple queries (INSERT + SELECT (PK+CK) + > UPDATE) plus application overhead. > It has been investigated in CASSANDRA-18766 to realize it is not related. > I tested to downgrade to 4.1alpha1 and the latency regression is still there > with same value. > The version 4.1.4 has the same issue. > In a graph how it looks like > !screenshot-1.png! -- 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-19735) Cannot correctly create keyspace statement with replication during schemaChange
[
https://issues.apache.org/jira/browse/CASSANDRA-19735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19735:
---
Fix Version/s: 5.0
5.0-rc1
> Cannot correctly create keyspace statement with replication during
> schemaChange
> ---
>
> Key: CASSANDRA-19735
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19735
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: ConfX
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc1, 5.0, 5.0.x, 5.x
>
>
> h3. What happened
> A specific schema change for creating keyspace with replications failed
> during Cassandra upgrade testing, but can pass under Cassandra distributed
> testing (non-upgrade).
> h3. How to reproduce:
> Put the following test under
> {{{}cassandra/test/distributed/org/apache/cassandra/distributed/upgrade/{}}},
> and build dtest jars for any versions within [4.1.3, 5.0-alpha2].
> {code:java}
> package org.apache.cassandra.distributed.upgrade;
> public class demoUpgradeTest extends UpgradeTestBase
> @Test
> public void demoTest() throws Throwable {
> new TestCase()
> .nodes(1)
> .nodesToUpgrade(1)
> .withConfig(config -> config.with(NETWORK, GOSSIP,
> NATIVE_PROTOCOL))
> .upgradesToCurrentFrom(v41)
> .setup((cluster) -> {
> cluster.schemaChange(withKeyspace("CREATE KEYSPACE %s
> WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 2}"));
> }).runAfterNodeUpgrade((cluster, node) -> {
> // let's do nothing here.
> }).run();
> }
> } {code}
> Run the test with
> {code:java}
> $ ant test-jvm-dtest-some-Duse.jdk11=true
> -Dtest.name=org.apache.cassandra.distributed.upgrade.demoUpgradeTest {code}
> You will see the following failure:
> {code:java}
> [junit-timeout] Testcase:
> demoTest(org.apache.cassandra.distributed.upgrade.demoUpgradeTest)-_jdk11:
> Caused an ERROR
> [junit-timeout] Cannot add existing keyspace "distributed_test_keyspace"
> [junit-timeout] org.apache.cassandra.exceptions.AlreadyExistsException:
> Cannot add existing keyspace "distributed_test_keyspace"
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.CreateKeyspaceStatement.apply(CreateKeyspaceStatement.java:78)
> [junit-timeout] at
> org.apache.cassandra.schema.DefaultSchemaUpdateHandler.apply(DefaultSchemaUpdateHandler.java:230)
> [junit-timeout] at
> org.apache.cassandra.schema.Schema.transform(Schema.java:597)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:114)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:60)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> [junit-timeout] at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> [junit-timeout] at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> [junit-timeout] at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [junit-timeout] at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829) {code}
> I have tested version pairs 4.1.3_4.1.4, 4.1.4_4.1.5, 4.1.5_5.0-alpha1, and
> 5.0-alpha1_5.0-alpha2. All of them have the same issue.
> I wrote a very similar test with Cassandra distributed test framework
> (non-upgrade test) as below:
> {code:java}
> package org.apache.cassandra.distributed.test.streaming;public class
> LCSStreamingKeepLevelTest extends TestBaseImpl
> {
> @Test
> public void demoTest() throws IOException
> {
> try (Cluster cluster = builder().withNodes(1)
> .withConfig(config -> config.with(NETWORK, GOSSIP,
> NATIVE_PROTOCOL))
> .start())
> {
> cluster.schemaChange(withKeyspace("CREATE KEYSPACE %s WITH
> replication = {'class': 'SimpleStrategy', 'replication_factor': 2}"));
> }
> }
> } {code}
> This distributed test would pass successfully without any issues.
>
> The expected behavior
[jira] [Updated] (CASSANDRA-19361) fix node info NPE when ClusterMetadata is null
[
https://issues.apache.org/jira/browse/CASSANDRA-19361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19361:
---
Fix Version/s: (was: 5.0.x)
> fix node info NPE when ClusterMetadata is null
> --
>
> Key: CASSANDRA-19361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19361
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool, Transactional Cluster Metadata
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.0-rc1, 5.0
>
> Attachments: CASSANDRA-19361-stack-error.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. How
>
> I create an ensemble with 3 nodes(It works well), then I add the fourth node
> to join the party.
> when executing nodetool info, get the following exception:
> {code:java}
> ➜ bin ./nodetool info
> java.lang.NullPointerException at
> org.apache.cassandra.service.StorageService.operationMode(StorageService.java:3744)
> at
> org.apache.cassandra.service.StorageService.isBootstrapFailed(StorageService.java:3810)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> ➜ bin ./nodetool info
> WARN [InternalResponseStage:152] 2024-02-02 11:45:15,731
> RemoteProcessor.java:213 - Got error from /127.0.0.4:7000: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.4:7000], checkLive=true} error: null
> -- StackTrace -- java.lang.NullPointerException at
> org.apache.cassandra.service.StorageService.getLocalHostId(StorageService.java:1904)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at
> jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260){code}
> server 1 cannot execute node info and cql shell, server 2 and 3 can do it.
> Try to query the system prefix tables, I attach stack error log for the
> further debugging. Cannot find a way to recover. After deleting data(losing
> all data), restart and everything became OK
> {code:java}
> ➜ bin ./nodetool status
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
> Rack
> UN 127.0.0.2 ? 16 51.2%
> 6d194555-f6eb-41d0-c000-0002 rack1
> DN 127.0.0.4 ? 16 48.8%
> 6d194555-f6eb-41d0-c000-0001 rack1{code}
> h3. When
>
> It was introduced by the Patch: CEP-21. Anyway, the NPE check is needed to
> protect its propagation anywhere
> {code:java}
> Implementation of Transactional Cluster Metadata as described in CEP-21
> Hash: ae084237
>
> code diff:
>
> public String getLocalHostId()
> {
> - UUID id = getLocalHostUUID();
> - return id != null ? id.toString() : null;
> + return getLocalHostUUID().toString();
> }
>
> public UUID getLocalHostUUID()
> {
> - UUID id =
> getTokenMetadata().getHostId(FBUtilities.getBroadcastAddressAndPort());
> - if (id != null)
> - return id;
> - // this condition is to prevent accessing the tables when the node
> is not started yet, and in particular,
> - // when it is not going to be started at all (e.g. when running some
> unit tests or client tools).
> - else if ((DatabaseDescriptor.isDaemonInitialized() ||
> DatabaseDescriptor.isToolInitialized()) && CommitLog.instance.isStarted())
> - return SystemKeyspace.getLocalHostId();
> -
> - return null;
> + // Metadata collector requires using local host id, and flush of
> IndexInfo may race with
> + // creation and initialization of cluster metadata service. Metadata
> collector does accept
> + // null localhost ID values, it's just that
[jira] [Updated] (CASSANDRA-19215) "Query start time" in native transport request threads should be the task enqueue time
[ https://issues.apache.org/jira/browse/CASSANDRA-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19215: --- Fix Version/s: 5.0 5.0-rc1 > "Query start time" in native transport request threads should be the task > enqueue time > -- > > Key: CASSANDRA-19215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19215 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Runtian Liu >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0-rc1, 5.0, 5.0.x, 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > > Recently, our Cassandra 4.0.6 cluster experienced an outage due to a surge in > expensive traffic from the application side. This surge involved a large > volume of costly read queries, which took a considerable amount of time to > process on the server side. The client had timeout settings; if a request > timed out, it might trigger the sending of new requests. Since the server > nodes were overloaded, numerous nodes had hundreds of thousands of tasks > queued in the Native-Transport-Request pending queue. I expected that once > the application ceased sending requests, the server node would quickly return > to normal, as most requests in the queue were over half an hour old and > should have timed out rapidly, clearing the queue. However, it actually took > an hour to clear the native transport's pending queue, even with native > transport disabled. Upon examining the code, I noticed that for read/write > requests, the > [queryStartNanoTime|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/transport/Dispatcher.java#L78], > which determines if a request has timed out, only begins when the task > starts processing. This means that no matter how long a request has been > pending, it doesn't contribute to the timeout. I believe this is incorrect. > The timer should start when the Cassandra server receives the request or when > it enqueues the task, not when the request/task begins processing. This way, > an overloaded node with many pending tasks can quickly discard timed-out > requests and recover from an outage once new requests stop. -- 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-19009) CEP-15: (C*/Accord) Schema based fast path reconfiguration
[ https://issues.apache.org/jira/browse/CASSANDRA-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19009: --- Fix Version/s: 5.0 5.0-rc1 > CEP-15: (C*/Accord) Schema based fast path reconfiguration > --- > > Key: CASSANDRA-19009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19009 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 5.0-rc1, 5.0, 5.0.x > > > This adds availability aware accord fast path reconfiguration, as well as > user configurable fast path settings, which are set at the keyspace level and > (optionally) at the table level for increased granularity. > The major parts are: > *Add availability information to cluster metadata* > Accord topology in C* is not stored in cluster metadata, but is meant to > calculated deterministically from cluster metadata state at a given epoch. > This adds the availability data, as well as the failure detector / gossip > listener and state change deduplication to CMS. > *Move C* accord keys/topology from keyspace prefixes to tableid prefixes* > To support per-table fast path settings, topologies and keys need to include > the table id. Since accord topologies could begin to consume a lot of memory > in clusters with a lot of nodes and tables, topology generation has been > updated to reuse previously allocated shards / shard parts where possible, > which will only increase heap sizes when things actually change. > *Make fast path settings configurable via schema* > There are 2.5 strategies: Simple, Parameterized, and InheritKeyspaceSettings. > Simple will use as many available nodes as possible for the fast path > electorate, this is the default for the keyspace fast path strategy. > Parameterized allows you to set a target size, and preferred datacenters for > the FP electorate. InheritKeyspace tells topology generation to just use the > keyspace fast path settings, and is the default for the table fast path > strategy. -- 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-19550) Test failure: org.apache.cassandra.cql3.validation.operations.DropRecreateAndRestoreTest.testCreateWithIdRestore
[
https://issues.apache.org/jira/browse/CASSANDRA-19550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19550:
---
Fix Version/s: 5.0
5.0-rc1
> Test failure:
> org.apache.cassandra.cql3.validation.operations.DropRecreateAndRestoreTest.testCreateWithIdRestore
>
>
> Key: CASSANDRA-19550
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19550
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc1, 5.0, 5.0.x
>
>
> {noformat}
> junit.framework.AssertionFailedError: Got less rows than expected. Expected 2
> but got 1
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1256)
> at
> org.apache.cassandra.cql3.validation.operations.DropRecreateAndRestoreTest.testCreateWithIdRestore(DropRecreateAndRestoreTest.java:80)
> {noformat}
> As seen at
> https://app.circleci.com/pipelines/github/driftx/cassandra/1579/workflows/03c0b2f6-d84f-440d-baad-bf323810a292/jobs/84088
--
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-18288) Test Failure: TopPartitionsTest.basicRegularTombstonesTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18288:
---
Fix Version/s: 5.0
5.0-rc1
> Test Failure: TopPartitionsTest.basicRegularTombstonesTest
> --
>
> Key: CASSANDRA-18288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18288
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0-rc1, 5.0, 5.0.x, 5.x
>
>
> from
> -
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1469/testReport/org.apache.cassandra.distributed.test/TopPartitionsTest/basicRegularTombstonesTest_Incremental___jdk11/
> -
> https://ci-cassandra.apache.org/job/Cassandra-trunk-jvm-dtest/1534/jdk=jdk_11_latest,label=cassandra,split=8/testReport/junit/org.apache.cassandra.distributed.test/TopPartitionsTest/basicRegularTombstonesTest_Incremental___jdk11/
> Stacktrace
> {noformat}
> java.lang.RuntimeException:
> at org.psjava.util.AssertStatus.assertTrue(AssertStatus.java:18)
> at org.psjava.util.AssertStatus.assertTrue(AssertStatus.java:5)
> at
> org.apache.cassandra.distributed.test.TopPartitionsTest.lambda$basicRegularTombstonesTest$e2f532b5$1(TopPartitionsTest.java:226)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> 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)
> {noformat}
> Standard Output
> {noformat}
> INFO [main] 2023-02-25 00:15:20,407 Reflections.java:219 -
> Reflections took 1661 ms to scan 9 urls, producing 1832 keys and 7268 values
> INFO [main] 2023-02-25 00:15:21,602 Reflections.java:219 -
> Reflections took 1131 ms to scan 9 urls, producing 1832 keys and 7268 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2023-02-25 00:15:22,419 InternalLoggerFactory.java:63 -
> Using SLF4J as the default logging framework
> DEBUG [main] node1 2023-02-25 00:15:22,426 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] node1 2023-02-25 00:15:22,427 PlatformDependent0.java:897 - Java
> version: 11
> DEBUG [main] node1 2023-02-25 00:15:22,428 PlatformDependent0.java:130 -
> sun.misc.Unsafe.theUnsafe: available
> DEBUG [main] node1 2023-02-25 00:15:22,429 PlatformDependent0.java:154 -
> sun.misc.Unsafe.copyMemory: available
> DEBUG [main] node1 2023-02-25 00:15:22,430 PlatformDependent0.java:192 -
> java.nio.Buffer.address: available
> DEBUG [main] node1 2023-02-25 00:15:22,431 PlatformDependent0.java:257 -
> direct buffer constructor: available
> DEBUG [main] node1 2023-02-25 00:15:22,432 PlatformDependent0.java:331 -
> java.nio.Bits.unaligned: available, true
> DEBUG [main] node1 2023-02-25 00:15:22,434 PlatformDependent0.java:393 -
> jdk.internal.misc.Unsafe.allocateUninitializedArray(int): available
> DEBUG [main] node1 2023-02-25 00:15:22,435 PlatformDependent0.java:403 -
> java.nio.DirectByteBuffer.(long, int): available
> DEBUG [main] node1 2023-02-25 00:15:22,435 PlatformDependent.java:1079 -
> sun.misc.Unsafe: available
> DEBUG [main] node1 2023-02-25 00:15:22,448 PlatformDependent.java:1181 -
> maxDirectMemory: 1056309248 bytes (maybe)
> DEBUG [main] node1 2023-02-25 00:15:22,449 PlatformDependent.java:1200 -
> -Dio.netty.tmpdir: /home/cassandra/cassandra/tmp (java.io.tmpdir)
> DEBUG [main] node1 2023-02-25 00:15:22,449 PlatformDependent.java:1279 -
> -Dio.netty.bitMode: 64 (sun.arch.data.model)
> DEBUG [main] node1 2023-02-25 00:15:22,450 PlatformDependent.java:177 -
> -Dio.netty.maxDirectMemory: 1056309248 bytes
> DEBUG [main] node1 2023-02-25 00:15:22,451 PlatformDependent.java:184 -
> -Dio.netty.uninitializedArrayAllocationThreshold: 1024
> DEBUG [main] node1 2023-02-25 00:15:22,452 CleanerJava9.java:71 -
> java.nio.ByteBuffer.cleaner(): available
> DEBUG [main] node1 2023-02-25 00:15:22,453 PlatformDependent.java:204 -
> -Dio.netty.noPreferDirect: false
> DEBUG [main] node2 2023-02-25 00:15:23,126 InternalLoggerFactory.java:63 -
> Using SLF4J as the default logging framework
> DEBUG [main] node2 2023-02-25 00:15:23,133 PlatformDependent0.java:417 -
> -Dio.netty.noUnsafe: false
> DEBUG [main] node2 2023-02-25
[jira] [Updated] (CASSANDRA-18922) cassandra-driver-core-3.11.5 vulnerability: CVE-2023-4586
[ https://issues.apache.org/jira/browse/CASSANDRA-18922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18922: --- Fix Version/s: 5.0 5.0-rc1 > cassandra-driver-core-3.11.5 vulnerability: CVE-2023-4586 > - > > Key: CASSANDRA-18922 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18922 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-rc1, 5.0, 5.0.x, 5.x > > > This is failing OWASP: https://nvd.nist.gov/vuln/detail/CVE-2023-4586 > but appears to be a false positive. -- 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-18808) netty-handler vulnerability: CVE-2023-4586
[
https://issues.apache.org/jira/browse/CASSANDRA-18808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18808:
---
Fix Version/s: (was: 5.0.x)
> netty-handler vulnerability: CVE-2023-4586
> --
>
> Key: CASSANDRA-18808
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18808
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc1, 5.0, 5.x
>
>
> This is failing OWASP:
> {noformat}
> Dependency-Check Failure:
> One or more dependencies were identified with vulnerabilities that have a
> CVSS score greater than or equal to '1.0':
> netty-handler-4.1.96.Final.jar: CVE-2023-4586
> {noformat}
--
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-19735) Cannot correctly create keyspace statement with replication during schemaChange
[
https://issues.apache.org/jira/browse/CASSANDRA-19735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19735:
---
Fix Version/s: (was: 5.0.x)
> Cannot correctly create keyspace statement with replication during
> schemaChange
> ---
>
> Key: CASSANDRA-19735
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19735
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: ConfX
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc1, 5.0, 5.x
>
>
> h3. What happened
> A specific schema change for creating keyspace with replications failed
> during Cassandra upgrade testing, but can pass under Cassandra distributed
> testing (non-upgrade).
> h3. How to reproduce:
> Put the following test under
> {{{}cassandra/test/distributed/org/apache/cassandra/distributed/upgrade/{}}},
> and build dtest jars for any versions within [4.1.3, 5.0-alpha2].
> {code:java}
> package org.apache.cassandra.distributed.upgrade;
> public class demoUpgradeTest extends UpgradeTestBase
> @Test
> public void demoTest() throws Throwable {
> new TestCase()
> .nodes(1)
> .nodesToUpgrade(1)
> .withConfig(config -> config.with(NETWORK, GOSSIP,
> NATIVE_PROTOCOL))
> .upgradesToCurrentFrom(v41)
> .setup((cluster) -> {
> cluster.schemaChange(withKeyspace("CREATE KEYSPACE %s
> WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 2}"));
> }).runAfterNodeUpgrade((cluster, node) -> {
> // let's do nothing here.
> }).run();
> }
> } {code}
> Run the test with
> {code:java}
> $ ant test-jvm-dtest-some-Duse.jdk11=true
> -Dtest.name=org.apache.cassandra.distributed.upgrade.demoUpgradeTest {code}
> You will see the following failure:
> {code:java}
> [junit-timeout] Testcase:
> demoTest(org.apache.cassandra.distributed.upgrade.demoUpgradeTest)-_jdk11:
> Caused an ERROR
> [junit-timeout] Cannot add existing keyspace "distributed_test_keyspace"
> [junit-timeout] org.apache.cassandra.exceptions.AlreadyExistsException:
> Cannot add existing keyspace "distributed_test_keyspace"
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.CreateKeyspaceStatement.apply(CreateKeyspaceStatement.java:78)
> [junit-timeout] at
> org.apache.cassandra.schema.DefaultSchemaUpdateHandler.apply(DefaultSchemaUpdateHandler.java:230)
> [junit-timeout] at
> org.apache.cassandra.schema.Schema.transform(Schema.java:597)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:114)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:60)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> [junit-timeout] at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> [junit-timeout] at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> [junit-timeout] at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> [junit-timeout] at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [junit-timeout] at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [junit-timeout] at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829) {code}
> I have tested version pairs 4.1.3_4.1.4, 4.1.4_4.1.5, 4.1.5_5.0-alpha1, and
> 5.0-alpha1_5.0-alpha2. All of them have the same issue.
> I wrote a very similar test with Cassandra distributed test framework
> (non-upgrade test) as below:
> {code:java}
> package org.apache.cassandra.distributed.test.streaming;public class
> LCSStreamingKeepLevelTest extends TestBaseImpl
> {
> @Test
> public void demoTest() throws IOException
> {
> try (Cluster cluster = builder().withNodes(1)
> .withConfig(config -> config.with(NETWORK, GOSSIP,
> NATIVE_PROTOCOL))
> .start())
> {
> cluster.schemaChange(withKeyspace("CREATE KEYSPACE %s WITH
> replication = {'class': 'SimpleStrategy', 'replication_factor': 2}"));
> }
> }
> } {code}
> This distributed test would pass successfully without any issues.
>
> The expected behavior should be that the
[jira] [Updated] (CASSANDRA-19529) Latency regression on 4.1 comparing to 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19529: --- Fix Version/s: (was: 5.0.x) > Latency regression on 4.1 comparing to 4.0 > -- > > Key: CASSANDRA-19529 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19529 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Nicolas Henneaux >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.1.x, 5.0-rc1, 5.0, 5.x > > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > When upgrading from Cassandra 4.0.10 to 4.1.3, I noticed an increase from > application point of view latency from ~8ms to ~15ms when upgrading to > Cassandra. The latency includes 3 simple queries (INSERT + SELECT (PK+CK) + > UPDATE) plus application overhead. > It has been investigated in CASSANDRA-18766 to realize it is not related. > I tested to downgrade to 4.1alpha1 and the latency regression is still there > with same value. > The version 4.1.4 has the same issue. > In a graph how it looks like > !screenshot-1.png! -- 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-19327) Test Failure: org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest[Small partition restricted high high]-system_keyspace_directory_jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-19327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19327:
---
Fix Version/s: (was: 5.0.x)
> Test Failure:
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest[Small
> partition restricted high high]-system_keyspace_directory_jdk17
>
>
> Key: CASSANDRA-19327
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19327
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc1, 5.0, 5.1
>
>
> Seen here:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2629/workflows/75f57272-f299-40e1-8e4f-fdb75bca2f7c/jobs/53821/tests]
> The tests were run with _memtable_allocation_type: heap_buffers_ (By default
> we run them now with offheap_objects, to be changed in CASSANDRA-19326)
> {code:java}
> junit.framework.AssertionFailedError: Got less rows than expected. Expected
> 16 but got 0 at
> org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1880) at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.lambda$runRestrictedQueries$3(RandomIntersectionTest.java:118)
> at
> org.apache.cassandra.cql3.CQLTester.beforeAndAfterFlush(CQLTester.java:2269)
> at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.runRestrictedQueries(RandomIntersectionTest.java:104)
> at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest(RandomIntersectionTest.java:95)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36){code}
> CC [~maedhroz]
--
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-19491) decommissioned nodes show as UNREACHABLE in describecluster afterward
[ https://issues.apache.org/jira/browse/CASSANDRA-19491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19491: --- Fix Version/s: 5.0 5.0-rc1 > decommissioned nodes show as UNREACHABLE in describecluster afterward > - > > Key: CASSANDRA-19491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19491 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Membership >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0-rc1, 5.0, 5.0.x > > > [~urandom] noticed this happening in his cluster and I have been able to > reproduce with a modified dtest. -- 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-19536) Honour previous parameter defaults between builds in Jenkinsfile
[ https://issues.apache.org/jira/browse/CASSANDRA-19536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19536: --- Fix Version/s: 5.0 5.0-rc1 > Honour previous parameter defaults between builds in Jenkinsfile > > > Key: CASSANDRA-19536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19536 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 5.0-rc1, 5.0, 5.0.x, 5.x > > > When the Jenkinsfile is being used in a job that was created by dsl and > intended to be triggered by scm polling, e.g. post-commit, that dsl will want > to set alternative defaults for the Jenkinsfile parameters. > > By default each build of the Jenkinsfile will restore the job's default > parameters (i.e. changing the defaults for the next build). > > This is described in more detail here > [https://www.linkedin.com/pulse/build-jenkins-job-default-parameters-using-bipin-kumar-chaurasia/] > > and summarised in a quick answer here > [https://stackoverflow.com/questions/57745451/how-can-i-override-a-jenkinsfiles-default-parameters] > > Patch for this is here: > [https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters] > > I'm waiting on INFRA-25694 to see if there are any other problems/changes in > the Jenkinsfile when it's running in ci-cassandra.a.o -- 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-18222) Test failure: org.apache.cassandra.distributed.test.accord.AccordIntegrationTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18222: --- Fix Version/s: 5.0 5.0-rc1 > Test failure: > org.apache.cassandra.distributed.test.accord.AccordIntegrationTest > > > Key: CASSANDRA-18222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18222 > Project: Cassandra > Issue Type: Bug > Components: Accord, CI >Reporter: David Capwell >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.0-rc1, 5.0, 5.0.x, 5.x > > > The accord integration tests are currently flaky due to Preempt happening (we > convert that to a timeout). We need to address this to make sure the tests > are stable. > One solution may be make SimpleProgressLog’s frequency run different for > jvm-dtest (likely to depend on CASSANDRA-18221 ), this would be similar to > what we already do as timeouts maybe larger in jvm-dtest due to the extra > complexity running multiple processes in the same JVM. Another solution may > be to have the client coordinator “attach” to the new coordinator, this would > avoid the user being impacted by this preempt when the coordinator is > healthy. > Example: > https://app.circleci.com/pipelines/github/dcapwell/cassandra/1822/workflows/0d92898f-ad7d-4a7d-9198-3a7ce844ee93/jobs/16464 -- 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-18922) cassandra-driver-core-3.11.5 vulnerability: CVE-2023-4586
[ https://issues.apache.org/jira/browse/CASSANDRA-18922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18922: --- Fix Version/s: (was: 5.0.x) > cassandra-driver-core-3.11.5 vulnerability: CVE-2023-4586 > - > > Key: CASSANDRA-18922 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18922 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-rc1, 5.0, 5.x > > > This is failing OWASP: https://nvd.nist.gov/vuln/detail/CVE-2023-4586 > but appears to be a false positive. -- 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-19536) Honour previous parameter defaults between builds in Jenkinsfile
[ https://issues.apache.org/jira/browse/CASSANDRA-19536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19536: --- Fix Version/s: (was: 5.0.x) > Honour previous parameter defaults between builds in Jenkinsfile > > > Key: CASSANDRA-19536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19536 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 5.0-rc1, 5.0, 5.x > > > When the Jenkinsfile is being used in a job that was created by dsl and > intended to be triggered by scm polling, e.g. post-commit, that dsl will want > to set alternative defaults for the Jenkinsfile parameters. > > By default each build of the Jenkinsfile will restore the job's default > parameters (i.e. changing the defaults for the next build). > > This is described in more detail here > [https://www.linkedin.com/pulse/build-jenkins-job-default-parameters-using-bipin-kumar-chaurasia/] > > and summarised in a quick answer here > [https://stackoverflow.com/questions/57745451/how-can-i-override-a-jenkinsfiles-default-parameters] > > Patch for this is here: > [https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/jenkinsfile-persist-parameters] > > I'm waiting on INFRA-25694 to see if there are any other problems/changes in > the Jenkinsfile when it's running in ci-cassandra.a.o -- 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-19361) fix node info NPE when ClusterMetadata is null
[
https://issues.apache.org/jira/browse/CASSANDRA-19361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19361:
---
Fix Version/s: 5.0
5.0-rc1
> fix node info NPE when ClusterMetadata is null
> --
>
> Key: CASSANDRA-19361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19361
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool, Transactional Cluster Metadata
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.0-rc1, 5.0, 5.0.x
>
> Attachments: CASSANDRA-19361-stack-error.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. How
>
> I create an ensemble with 3 nodes(It works well), then I add the fourth node
> to join the party.
> when executing nodetool info, get the following exception:
> {code:java}
> ➜ bin ./nodetool info
> java.lang.NullPointerException at
> org.apache.cassandra.service.StorageService.operationMode(StorageService.java:3744)
> at
> org.apache.cassandra.service.StorageService.isBootstrapFailed(StorageService.java:3810)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> ➜ bin ./nodetool info
> WARN [InternalResponseStage:152] 2024-02-02 11:45:15,731
> RemoteProcessor.java:213 - Got error from /127.0.0.4:7000: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.4:7000], checkLive=true} error: null
> -- StackTrace -- java.lang.NullPointerException at
> org.apache.cassandra.service.StorageService.getLocalHostId(StorageService.java:1904)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at
> jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260){code}
> server 1 cannot execute node info and cql shell, server 2 and 3 can do it.
> Try to query the system prefix tables, I attach stack error log for the
> further debugging. Cannot find a way to recover. After deleting data(losing
> all data), restart and everything became OK
> {code:java}
> ➜ bin ./nodetool status
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
> Rack
> UN 127.0.0.2 ? 16 51.2%
> 6d194555-f6eb-41d0-c000-0002 rack1
> DN 127.0.0.4 ? 16 48.8%
> 6d194555-f6eb-41d0-c000-0001 rack1{code}
> h3. When
>
> It was introduced by the Patch: CEP-21. Anyway, the NPE check is needed to
> protect its propagation anywhere
> {code:java}
> Implementation of Transactional Cluster Metadata as described in CEP-21
> Hash: ae084237
>
> code diff:
>
> public String getLocalHostId()
> {
> - UUID id = getLocalHostUUID();
> - return id != null ? id.toString() : null;
> + return getLocalHostUUID().toString();
> }
>
> public UUID getLocalHostUUID()
> {
> - UUID id =
> getTokenMetadata().getHostId(FBUtilities.getBroadcastAddressAndPort());
> - if (id != null)
> - return id;
> - // this condition is to prevent accessing the tables when the node
> is not started yet, and in particular,
> - // when it is not going to be started at all (e.g. when running some
> unit tests or client tools).
> - else if ((DatabaseDescriptor.isDaemonInitialized() ||
> DatabaseDescriptor.isToolInitialized()) && CommitLog.instance.isStarted())
> - return SystemKeyspace.getLocalHostId();
> -
> - return null;
> + // Metadata collector requires using local host id, and flush of
> IndexInfo may race with
> + // creation and initialization of cluster metadata service. Metadata
> collector does accept
> + // null localhost ID
[jira] [Updated] (CASSANDRA-19102) Test Failure: org.apache.cassandra.distributed.test.ReadRepairTest#readRepairRTRangeMovementTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19102:
---
Fix Version/s: 5.1
> Test Failure:
> org.apache.cassandra.distributed.test.ReadRepairTest#readRepairRTRangeMovementTest
>
>
> Key: CASSANDRA-19102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19102
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1-beta, 5.1
>
>
> {noformat}
> java.lang.AssertionError: Expected a different error message, but got
> Operation failed - received 2 responses and 1 failures: INVALID_ROUTING from
> /127.0.0.2:7012
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.cassandra.distributed.test.ReadRepairTest.readRepairRTRangeMovementTest(ReadRepairTest.java:424)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
> at
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:232)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:55)
> {noformat}
> Manual testing in IntelliJ / trunk. Detected during investigation of test
> failures of CASSANDRA-18464
--
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-19127) Test Failure: org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19127:
---
Fix Version/s: (was: 5.1-beta)
> Test Failure:
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
> -
>
> Key: CASSANDRA-19127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19127
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.1
>
>
> The test is not flaky on 5.0 -
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2590/workflows/47dedf52-87fd-4178-bc89-d179e58b6562
> But it is significantly flaky on trunk -
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2591/workflows/1150aab2-4961-4fe3-a126-b96356fdb939/jobs/49867/tests
> {code:java}
> org.apache.cassandra.simulator.SimulationException: Failed on seed
> 0xf2b8eff98afd45dd
> Suppressed: java.lang.RuntimeException:
> java.util.concurrent.TimeoutException
> at
> org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:537)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
> at
> org.apache.cassandra.simulator.ClusterSimulation.close(ClusterSimulation.java:854)
> at
> org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:361)
> at
> org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:346)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulationRunner$Run.run(PaxosSimulationRunner.java:34)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulationRunner.main(PaxosSimulationRunner.java:148)
> at
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest(ShortPaxosSimulationTest.java:101)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.util.concurrent.TimeoutException
> at
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:529)
> Suppressed: java.util.concurrent.TimeoutException
> Suppressed: java.util.concurrent.TimeoutException
> Suppressed: java.util.concurrent.TimeoutException
> Suppressed: java.util.concurrent.TimeoutException
> Suppressed: java.util.concurrent.TimeoutException
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.simulator.cluster.KeyspaceActions.scheduleAndUpdateTopologyOnCompletion(KeyspaceActions.java:352)
> at
> org.apache.cassandra.simulator.cluster.KeyspaceActions.next(KeyspaceActions.java:291)
> at org.apache.cassandra.simulator.Actions.next(Actions.java:147)
> at
> org.apache.cassandra.simulator.Actions.lambda$streamNextSupplier$3(Actions.java:156)
> at
> org.apache.cassandra.simulator.Actions$LambdaAction.performSimple(Actions.java:63)
> at
> org.apache.cassandra.simulator.Action.performAndRegister(Action.java:468)
> at org.apache.cassandra.simulator.Action.perform(Action.java:486)
> at
> org.apache.cassandra.simulator.ActionSchedule.next(ActionSchedule.java:379)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulation$2.next(PaxosSimulation.java:217)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.run(PaxosSimulation.java:189)
> at
> org.apache.cassandra.simulator.paxos.PairOfSequencesPaxosSimulation.run(PairOfSequencesPaxosSimulation.java:351)
> at
> org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:365)
> at
> org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:346)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulationRunner$Run.run(PaxosSimulationRunner.java:34)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulationRunner.main(PaxosSimulationRunner.java:148)
> at
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest(ShortPaxosSimulationTest.java:101)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
[jira] [Updated] (CASSANDRA-19163) Test Failure: org.apache.cassandra.db.DiskBoundaryManagerTest.alterKeyspaceTest-cdc_jdk17_x86_64
[
https://issues.apache.org/jira/browse/CASSANDRA-19163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19163:
---
Fix Version/s: (was: 5.1-beta)
> Test Failure:
> org.apache.cassandra.db.DiskBoundaryManagerTest.alterKeyspaceTest-cdc_jdk17_x86_64
>
> -
>
> Key: CASSANDRA-19163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19163
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.1
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1801/testReport/org.apache.cassandra.db/DiskBoundaryManagerTest/alterKeyspaceTest_cdc_jdk17_x86_64/]
> {code:java}
> Error Message
> expected not same
> Stacktrace
> junit.framework.AssertionFailedError: expected not same at
> org.apache.cassandra.db.DiskBoundaryManagerTest.alterKeyspaceTest(DiskBoundaryManagerTest.java:140)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
--
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-19102) Test Failure: org.apache.cassandra.distributed.test.ReadRepairTest#readRepairRTRangeMovementTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19102:
---
Fix Version/s: (was: 5.1-beta)
> Test Failure:
> org.apache.cassandra.distributed.test.ReadRepairTest#readRepairRTRangeMovementTest
>
>
> Key: CASSANDRA-19102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19102
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1
>
>
> {noformat}
> java.lang.AssertionError: Expected a different error message, but got
> Operation failed - received 2 responses and 1 failures: INVALID_ROUTING from
> /127.0.0.2:7012
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.cassandra.distributed.test.ReadRepairTest.readRepairRTRangeMovementTest(ReadRepairTest.java:424)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
> at
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:232)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:55)
> {noformat}
> Manual testing in IntelliJ / trunk. Detected during investigation of test
> failures of CASSANDRA-18464
--
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-19171) Test Failure: org.apache.cassandra.locator.PropertyFileSnitchTest.configContainsRemoteConfig-cdc_jdk17_x86_64
[
https://issues.apache.org/jira/browse/CASSANDRA-19171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19171:
---
Fix Version/s: 5.1
> Test Failure:
> org.apache.cassandra.locator.PropertyFileSnitchTest.configContainsRemoteConfig-cdc_jdk17_x86_64
> -
>
> Key: CASSANDRA-19171
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19171
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1-beta, 5.1
>
>
> h3.
> {code:java}
> Error Message
> Multiple entries with same key: 127.0.0.1:7012=OTHER_DC1:OTHER_RAC1 and
> 127.0.0.1:7012=DC1:RAC1
> Stacktrace
> java.lang.IllegalArgumentException: Multiple entries with same key:
> 127.0.0.1:7012=OTHER_DC1:OTHER_RAC1 and 127.0.0.1:7012=DC1:RAC1 at
> com.google.common.collect.ImmutableMap.conflictException(ImmutableMap.java:378)
> at
> com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:372)
> at
> com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:246)
> at
> com.google.common.collect.RegularImmutableMap.fromEntryArrayCheckingBucketOverflow(RegularImmutableMap.java:133)
> at
> com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:95)
> at
> com.google.common.collect.RegularImmutableMap.fromEntries(RegularImmutableMap.java:78)
> at com.google.common.collect.ImmutableMap.of(ImmutableMap.java:139) at
> org.apache.cassandra.locator.PropertyFileSnitchTest.configContainsRemoteConfig(PropertyFileSnitchTest.java:121)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
--
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-19171) Test Failure: org.apache.cassandra.locator.PropertyFileSnitchTest.configContainsRemoteConfig-cdc_jdk17_x86_64
[
https://issues.apache.org/jira/browse/CASSANDRA-19171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19171:
---
Fix Version/s: (was: 5.1-beta)
> Test Failure:
> org.apache.cassandra.locator.PropertyFileSnitchTest.configContainsRemoteConfig-cdc_jdk17_x86_64
> -
>
> Key: CASSANDRA-19171
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19171
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1
>
>
> h3.
> {code:java}
> Error Message
> Multiple entries with same key: 127.0.0.1:7012=OTHER_DC1:OTHER_RAC1 and
> 127.0.0.1:7012=DC1:RAC1
> Stacktrace
> java.lang.IllegalArgumentException: Multiple entries with same key:
> 127.0.0.1:7012=OTHER_DC1:OTHER_RAC1 and 127.0.0.1:7012=DC1:RAC1 at
> com.google.common.collect.ImmutableMap.conflictException(ImmutableMap.java:378)
> at
> com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:372)
> at
> com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:246)
> at
> com.google.common.collect.RegularImmutableMap.fromEntryArrayCheckingBucketOverflow(RegularImmutableMap.java:133)
> at
> com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:95)
> at
> com.google.common.collect.RegularImmutableMap.fromEntries(RegularImmutableMap.java:78)
> at com.google.common.collect.ImmutableMap.of(ImmutableMap.java:139) at
> org.apache.cassandra.locator.PropertyFileSnitchTest.configContainsRemoteConfig(PropertyFileSnitchTest.java:121)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
--
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-19163) Test Failure: org.apache.cassandra.db.DiskBoundaryManagerTest.alterKeyspaceTest-cdc_jdk17_x86_64
[
https://issues.apache.org/jira/browse/CASSANDRA-19163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19163:
---
Fix Version/s: 5.1
> Test Failure:
> org.apache.cassandra.db.DiskBoundaryManagerTest.alterKeyspaceTest-cdc_jdk17_x86_64
>
> -
>
> Key: CASSANDRA-19163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19163
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.1-beta, 5.1
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1801/testReport/org.apache.cassandra.db/DiskBoundaryManagerTest/alterKeyspaceTest_cdc_jdk17_x86_64/]
> {code:java}
> Error Message
> expected not same
> Stacktrace
> junit.framework.AssertionFailedError: expected not same at
> org.apache.cassandra.db.DiskBoundaryManagerTest.alterKeyspaceTest(DiskBoundaryManagerTest.java:140)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
--
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-19127) Test Failure: org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19127:
---
Fix Version/s: 5.1
> Test Failure:
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
> -
>
> Key: CASSANDRA-19127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19127
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.1-beta, 5.1
>
>
> The test is not flaky on 5.0 -
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2590/workflows/47dedf52-87fd-4178-bc89-d179e58b6562
> But it is significantly flaky on trunk -
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2591/workflows/1150aab2-4961-4fe3-a126-b96356fdb939/jobs/49867/tests
> {code:java}
> org.apache.cassandra.simulator.SimulationException: Failed on seed
> 0xf2b8eff98afd45dd
> Suppressed: java.lang.RuntimeException:
> java.util.concurrent.TimeoutException
> at
> org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:537)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
> at
> org.apache.cassandra.simulator.ClusterSimulation.close(ClusterSimulation.java:854)
> at
> org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:361)
> at
> org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:346)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulationRunner$Run.run(PaxosSimulationRunner.java:34)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulationRunner.main(PaxosSimulationRunner.java:148)
> at
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest(ShortPaxosSimulationTest.java:101)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.util.concurrent.TimeoutException
> at
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:529)
> Suppressed: java.util.concurrent.TimeoutException
> Suppressed: java.util.concurrent.TimeoutException
> Suppressed: java.util.concurrent.TimeoutException
> Suppressed: java.util.concurrent.TimeoutException
> Suppressed: java.util.concurrent.TimeoutException
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.simulator.cluster.KeyspaceActions.scheduleAndUpdateTopologyOnCompletion(KeyspaceActions.java:352)
> at
> org.apache.cassandra.simulator.cluster.KeyspaceActions.next(KeyspaceActions.java:291)
> at org.apache.cassandra.simulator.Actions.next(Actions.java:147)
> at
> org.apache.cassandra.simulator.Actions.lambda$streamNextSupplier$3(Actions.java:156)
> at
> org.apache.cassandra.simulator.Actions$LambdaAction.performSimple(Actions.java:63)
> at
> org.apache.cassandra.simulator.Action.performAndRegister(Action.java:468)
> at org.apache.cassandra.simulator.Action.perform(Action.java:486)
> at
> org.apache.cassandra.simulator.ActionSchedule.next(ActionSchedule.java:379)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulation$2.next(PaxosSimulation.java:217)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.run(PaxosSimulation.java:189)
> at
> org.apache.cassandra.simulator.paxos.PairOfSequencesPaxosSimulation.run(PairOfSequencesPaxosSimulation.java:351)
> at
> org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:365)
> at
> org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:346)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulationRunner$Run.run(PaxosSimulationRunner.java:34)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulationRunner.main(PaxosSimulationRunner.java:148)
> at
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest(ShortPaxosSimulationTest.java:101)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Updated] (CASSANDRA-19097) Test Failure: bootstrap_test.TestBootstrap.*
[
https://issues.apache.org/jira/browse/CASSANDRA-19097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19097:
---
Fix Version/s: 5.1
(was: 5.1-rc)
> Test Failure: bootstrap_test.TestBootstrap.*
>
>
> Key: CASSANDRA-19097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19097
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Michael Semb Wever
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.12, 4.1.4, 5.0-rc1, 5.0, 5.1
>
> Attachments: jenkinslogs.zip
>
>
> test_killed_wiped_node_cannot_join
> test_read_from_bootstrapped_node
> test_shutdown_wiped_node_cannot_join
> Seen in dtests_offheap in CASSANDRA-19034
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/258/workflows/cea7d697-ca33-40bb-8914-fb9fc662820a/jobs/21162/parallel-runs/38
> {noformat}
> self =
> def test_killed_wiped_node_cannot_join(self):
> > self._wiped_node_cannot_join_test(gently=False)
> bootstrap_test.py:608:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = , gently = False
> def _wiped_node_cannot_join_test(self, gently):
> """
> @jira_ticket CASSANDRA-9765
> Test that if we stop a node and wipe its data then the node cannot
> join
> when it is not a seed. Test both a nice shutdown or a forced
> shutdown, via
> the gently parameter.
> """
> cluster = self.cluster
>
> cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
> 'True')
> cluster.populate(3)
> cluster.start()
>
> stress_table = 'keyspace1.standard1'
>
> # write some data
> node1 = cluster.nodelist()[0]
> node1.stress(['write', 'n=10K', 'no-warmup', '-rate', 'threads=8'])
>
> session = self.patient_cql_connection(node1)
> original_rows = list(session.execute("SELECT * FROM
> {}".format(stress_table,)))
>
> # Add a new node, bootstrap=True ensures that it is not a seed
> node4 = new_node(cluster, bootstrap=True)
> node4.start(wait_for_binary_proto=True)
>
> session = self.patient_cql_connection(node4)
> > assert original_rows == list(session.execute("SELECT * FROM
> > {}".format(stress_table,)))
> E assert [Row(key=b'PP...e9\xbb'), ...] == [Row(key=b'PP...e9\xbb'),
> ...]
> E At index 587 diff: Row(key=b'OP2656L630',
> C0=b"E02\xd2\x8clBv\tr\n\xe3\x01\xdd\xf2\x8a\x91\x7f-\x9dm'\xa5\xe7PH\xef\xc1xlO\xab+d",
>
> C1=b"\xb2\xc0j\xff\xcb'\xe3\xcc\x0b\x93?\x18@\xc4\xc7tV\xb7q\xeeF\x82\xa4\xd3\xdcFl\xd9\x87
> \x9a\xde\xdc\xa3",
> C2=b'\xed\xf8\x8d%\xa4\xa6LPs;\x98f\xdb\xca\x913\xba{M\x8d6XW\x01\xea-\xb5
> C3=b'\x9ec\xcf\xc7\xec\xa5\x85Z]\xa6\x19\xeb\xc4W\x1d%lyZj\xb9\x94I\x90\xebZ\xdba\xdd\xdc\x9e\x82\x95\x1c',
>
> C4=b'\xab\x9e\x13\x8b\xc6\x15D\x9b\xccl\xdcX\xb23\xd0\x8b\xa3\xba7\xc1c\xf7F\x1d\xf8e\xbd\x89\xcb\xd8\xd1)f\xdd')
> != Row(key=b'4LN78NONP0',
> C0=b"\xdf\x90\xb3/u\xc9/C\xcdOYG3\x070@#\xc3k\xaa$M'\x19\xfb\xab\xc0\x10]\xa6\xac\x1d\x81\xad",
>
> C1=b'\x8a\xb7j\x95\xf9\xbd?&\x11\xaaH\xcd\x87\xaa\xd2\x85\x08X\xea9\x94\xae8U\x92\xad\xb0\x1b9\xff\x87Z\xe81',
>
> C2=b'6\x1d\xa1-\xf77\xc7\xde+`\xb7\x89\xaa\xcd\xb5_\xe5\xb3\x04\xc7\xb1\x95e\x81s\t1\x8b\x16sc\x0eMm',
>
> C3=b'\xfbi\x08;\xc9\x94\x15}r\xfe\x1b\xae5\xf6v\x83\xae\xff\x82\x9b`J\xc2D\xa6k+\xf3\xd3\xff{C\xd0;',
>
> C4=b'\x8f\x87\x18\x0f\xfa\xadK"\x9e\x96\x87:tiu\xa5\x99\xe1_Ax\xa3\x12\xb4Z\xc9v\xa5\xad\xb8{\xc0\xa3\x93')
> E Left contains 2830 more items, first extra item:
> Row(key=b'5N7N172K30',
> C0=b'Y\x81\xa6\x02\x89\xa0hyp\x00O\xe9kFp$\x86u\xea\n\x7fK\x99\xe1\xf6G\xf77\xf7\xd7\xe1\xc7L\x...0\x87a\x03\xee',
>
> C4=b'\xe8\xd8\x17\xf3\x14\x16Q\x9d\\jb\xde=\x81\xc1B\x9c;T\xb1\xa2O-\x87zF=\x04`\x04\xbd\xc9\x95\xad')
> E Full diff:
> E [
> …
> {noformat}
--
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-18321) distutils Version classes are deprecated. Use packaging.version instead.
[
https://issues.apache.org/jira/browse/CASSANDRA-18321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17867016#comment-17867016
]
Michael Semb Wever commented on CASSANDRA-18321:
Try running a dtest like this:
{code}
cassandra_dtest_dir="path-to-your-cassandra-dtest" .build/docker/run-tests.sh
dtest auditlog_test.py::TestAuditlog::test_archiving 11
{code}
For me, using this patch, I'm getting the failure (regardless of which dtest i
specify):
{noformat}
Traceback (most recent call last):
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/_pytest/main.py",
line 268, in wrap_session
session.exitstatus = doit(config, session) or 0
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/_pytest/main.py",
line 322, in _main
config.hook.pytest_runtestloop(session=session)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/pluggy/_hooks.py",
line 265, in __call__
return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/pluggy/_manager.py",
line 80, in _hookexec
return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/pluggy/_callers.py",
line 60, in _multicall
return outcome.get_result()
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/pluggy/_result.py",
line 60, in get_result
raise ex[1].with_traceback(ex[2])
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/pluggy/_callers.py",
line 39, in _multicall
res = hook_impl.function(*args)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/_pytest/main.py",
line 347, in pytest_runtestloop
item.config.hook.pytest_runtest_protocol(item=item, nextitem=nextitem)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/pluggy/_hooks.py",
line 265, in __call__
return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/pluggy/_manager.py",
line 80, in _hookexec
return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/pluggy/_callers.py",
line 60, in _multicall
return outcome.get_result()
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/pluggy/_result.py",
line 60, in get_result
raise ex[1].with_traceback(ex[2])
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/pluggy/_callers.py",
line 39, in _multicall
res = hook_impl.function(*args)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/flaky/flaky_pytest_plugin.py",
line 89, in pytest_runtest_protocol
self.runner.pytest_runtest_protocol(item, nextitem)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/_pytest/runner.py",
line 113, in pytest_runtest_protocol
runtestprotocol(item, nextitem=nextitem)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/_pytest/runner.py",
line 126, in runtestprotocol
rep = call_and_report(item, "setup", log)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/flaky/flaky_pytest_plugin.py",
line 161, in call_and_report
if self._will_handle_test_error_or_failure(item, name, err):
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/flaky/_flaky_plugin.py",
line 147, in _will_handle_test_error_or_failure
return self._should_handle_test_error_or_failure(test) and
self._should_rerun_test(test, name, err)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/flaky/_flaky_plugin.py",
line 222, in _should_rerun_test
return rerun_filter(err, name, test, self)
File
"/home/cassandra/cassandra/build/venv/lib/python3.8/site-packages/flaky/defaults.py",
line 22, in __call__
return self._filter(*args, **kwargs)
File "/home/cassandra/cassandra-dtest/dtest.py", line 226, in
test_failure_due_to_timeout
if issubclass(err[0], OperationTimedOut) or issubclass(err[0], ToolError)
or issubclass(err[0], TimeoutError):
NameError: name 'ToolError' is not defined
{noformat}
> distutils Version classes are deprecated. Use packaging.version instead.
>
>
> Key: CASSANDRA-18321
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18321
> Project: Cassandra
> Issue Type: Improvement
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Dhanush Ananthkar
>Priority: Low
> Fix For: 5.x
>
>
> Lately I see a lot in Python DTests the below warning:
> {code:java}
>
[jira] [Comment Edited] (CASSANDRA-19763) Reentrant locks should always be locked outside of a try block
[
https://issues.apache.org/jira/browse/CASSANDRA-19763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17866834#comment-17866834
]
Michael Semb Wever edited comment on CASSANDRA-19763 at 7/17/24 7:15 PM:
-
What happens if the lock() acquires the lock but still throws some unchecked
exception/error, like OOM …? Are we left with a stalelock and a non-functioning
system ? Are there situations where we might intentionally choose to deal with
catching a lock() exception as well as catching the unlock() exception for the
guarantee of leaving the system correct ? Would this risk a failed lock()
attempt then unlocking someone else's lock potentially leading to unsafe
concurrent access …?
e.g. see the usage of CompactionManager.CompactionPauser
was (Author: michaelsembwever):
What happens if the lock() acquires the lock but still throws some other
exception, like OOM …? Are we left with a stalelock and a non-functioning
system ? Are there situations where we might intentionally choose to deal with
catching a lock() exception as well as catching the unlock() exception for the
guarantee of leaving the system correct ? Would this risk a failed lock()
attempt then unlocking someone else's lock potentially leading to unsafe
concurrent access …?
e.g. see the usage of CompactionManager.CompactionPauser
> Reentrant locks should always be locked outside of a try block
> --
>
> Key: CASSANDRA-19763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19763
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Low
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {color:#172b4d}Acquiring the lock should always be done before the try block
> so that the finally clause to unlock will never execute unless the lock is
> acquired. More info:{color}
>
> {code:java}
> https://stackoverflow.com/questions/31058681/java-locking-structure-best-pattern
> https://issues.apache.org/jira/browse/AMQ-9202
> {code}
>
> Unfortunately, there are no ready-made rules in Checkstyle, FindBugs, or
> SpotBugs for this type of violation checking. I use "IDEA inspection" to
> identify all such violations.
> {code:java}
> IDEA Code -> Analyze Code -> Run Inspection by Name(Lock acquired but not
> safely unlocked) ---> Whole project{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-19763) Reentrant locks should always be locked outside of a try block
[
https://issues.apache.org/jira/browse/CASSANDRA-19763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17866834#comment-17866834
]
Michael Semb Wever edited comment on CASSANDRA-19763 at 7/17/24 7:14 PM:
-
What happens if the lock() acquires the lock but still throws some other
exception, like OOM …? Are we left with a stalelock and a non-functioning
system ? Are there situations where we might intentionally choose to deal with
catching a lock() exception as well as catching the unlock() exception for the
guarantee of leaving the system correct ? Would this risk a failed lock()
attempt then unlocking someone else's lock potentially leading to unsafe
concurrent access …?
e.g. see the usage of CompactionManager.CompactionPauser
was (Author: michaelsembwever):
What happens if the lock() acquires the lock but still throws some other
exception, like OOM …? Are we left with a stalelock and a non-functioning
system ? Are there situations where we might intentionally choose to deal with
catching a lock() exception as well as catching the unlock() exception for the
guarantee of leaving the system correct ? Would this risk a failed lock()
attempt then unlocking someone else's lock potentially leading to unsafe
concurrent access …?
> Reentrant locks should always be locked outside of a try block
> --
>
> Key: CASSANDRA-19763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19763
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Low
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {color:#172b4d}Acquiring the lock should always be done before the try block
> so that the finally clause to unlock will never execute unless the lock is
> acquired. More info:{color}
>
> {code:java}
> https://stackoverflow.com/questions/31058681/java-locking-structure-best-pattern
> https://issues.apache.org/jira/browse/AMQ-9202
> {code}
>
> Unfortunately, there are no ready-made rules in Checkstyle, FindBugs, or
> SpotBugs for this type of violation checking. I use "IDEA inspection" to
> identify all such violations.
> {code:java}
> IDEA Code -> Analyze Code -> Run Inspection by Name(Lock acquired but not
> safely unlocked) ---> Whole project{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-19763) Reentrant locks should always be locked outside of a try block
[
https://issues.apache.org/jira/browse/CASSANDRA-19763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17866834#comment-17866834
]
Michael Semb Wever commented on CASSANDRA-19763:
What happens if the lock() acquires the lock but still throws some other
exception, like OOM …? Are we left with a stalelock and a non-functioning
system ? Are there situations where we might intentionally choose to deal with
catching a lock() exception as well as catching the unlock() exception for the
guarantee of leaving the system correct ? Would this risk a failed lock()
attempt then unlocking someone else's lock potentially leading to unsafe
concurrent access …?
> Reentrant locks should always be locked outside of a try block
> --
>
> Key: CASSANDRA-19763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19763
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Low
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {color:#172b4d}Acquiring the lock should always be done before the try block
> so that the finally clause to unlock will never execute unless the lock is
> acquired. More info:{color}
>
> {code:java}
> https://stackoverflow.com/questions/31058681/java-locking-structure-best-pattern
> https://issues.apache.org/jira/browse/AMQ-9202
> {code}
>
> Unfortunately, there are no ready-made rules in Checkstyle, FindBugs, or
> SpotBugs for this type of violation checking. I use "IDEA inspection" to
> identify all such violations.
> {code:java}
> IDEA Code -> Analyze Code -> Run Inspection by Name(Lock acquired but not
> safely unlocked) ---> Whole project{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-18942) Repeatable java test runs on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18942: --- Attachment: CASSANDRA-18942_118_ci_summary.html CASSANDRA-18942_118_results_details.tar.xz > Repeatable java test runs on jenkins > > > Key: CASSANDRA-18942 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18942 > Project: Cassandra > Issue Type: New Feature > Components: Build, CI >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CASSANDRA-18942_118_ci_summary.html, > CASSANDRA-18942_118_results_details.tar.xz, jenkins_job.xml, testJava.txt, > testJavaDocker.txt, testJavaSplits.txt > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is our policy to loop new introduced tests to avoid introducing flakies. > We also want to add the possibility to repeat a test N number of times to > test robustness, debug flakies, etc. -- 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-18942) Repeatable java test runs on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18942: --- Fix Version/s: 5.x (was: 5.0) > Repeatable java test runs on jenkins > > > Key: CASSANDRA-18942 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18942 > Project: Cassandra > Issue Type: New Feature > Components: Build, CI >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: jenkins_job.xml, testJava.txt, testJavaDocker.txt, > testJavaSplits.txt > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is our policy to loop new introduced tests to avoid introducing flakies. > We also want to add the possibility to repeat a test N number of times to > test robustness, debug flakies, etc. -- 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-18942) Repeatable java test runs on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17864794#comment-17864794 ] Michael Semb Wever commented on CASSANDRA-18942: CI - post-commit profile: [^CASSANDRA-18942_118_ci_summary.html] and [^CASSANDRA-18942_118_results_details.tar.xz] Two failures, unrelated. > Repeatable java test runs on jenkins > > > Key: CASSANDRA-18942 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18942 > Project: Cassandra > Issue Type: New Feature > Components: Build, CI >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0, 5.0.x > > Attachments: jenkins_job.xml, testJava.txt, testJavaDocker.txt, > testJavaSplits.txt > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is our policy to loop new introduced tests to avoid introducing flakies. > We also want to add the possibility to repeat a test N number of times to > test robustness, debug flakies, etc. -- 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-18120) Single slow node dramatically reduces cluster logged batch write throughput regardless of CL
[ https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18120: --- Authors: Shayne Hunsaker (was: Maxim Chanturiay) Test and Documentation Plan: CI Status: Patch Available (was: Open) > Single slow node dramatically reduces cluster logged batch write throughput > regardless of CL > > > Key: CASSANDRA-18120 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination >Reporter: Dan Sarisky >Assignee: Maxim Chanturiay >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, > QUORUM, or LOCAL_QUORUM) > > On clusters of any size - a single extremely slow node causes a ~90% loss of > cluster-wide throughput using batched writes. We can replicate this in the > lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. > > It appears the mechanism in play is: > Those logged batches are immediately written to two replica nodes and the > actual mutations aren't processed until those two nodes acknowledge the batch > statements. Those replica nodes are selected randomly from all nodes in the > local data center currently up in gossip. If a single node is slow, but > still thought to be up in gossip, this eventually causes every other node to > have all of its MutationStages to be waiting while the slow replica accepts > batch writes. > > The code in play appears to be: > See > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. > In the method filterBatchlogEndpoints() there is a > Collections.shuffle() to order the endpoints and a > FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. > > This behavior causes Cassandra to move from a multi-node fault tolerant > system toa collection of single points of failure. > > We try to take administrator actions to kill off the extremely slow nodes, > but it would be great to have some notion of "what node is a bad choice" when > writing log batches to replica nodes. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19751) IllegalStateException when query on table having static columns during the Cassandra cluster upgrade from 3.11.4 to 4.0.11
[
https://issues.apache.org/jira/browse/CASSANDRA-19751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19751:
---
Resolution: Duplicate
Status: Resolved (was: Open)
> IllegalStateException when query on table having static columns during the
> Cassandra cluster upgrade from 3.11.4 to 4.0.11
> --
>
> Key: CASSANDRA-19751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19751
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: Full-error-stack.txt
>
>
> We are upgrading Cassandra cluster from 3.11.4 to 4.0.11. This cluster has
> SSL enabled.
> While performing upgrade on 1st DC, we observed below WARN/ERROR messages on
> C* 3 and C* 4 nodes.
> +C*3 nodes:+
> {noformat}
> WARN [ReadStage-1] 2024-06-11 08:04:09,088
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-1,5,main]: {}
> java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is
> not a subset of [price_metadata]
> WARN [ReadStage-1] 2024-06-19 05:10:31,226
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-1,5,main]: {}
> java.lang.IllegalStateException: [default_price_json, last_metadata_updt_ts,
> price_metadata] is not a subset of [price_metadata]
> {noformat}
> +C*4 nodes:+
> {noformat}
> ERROR [ReadStage-1] 2024-06-19 05:48:47,388
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[ReadStage-1,5,main]
> java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is
> not a subset of [price_metadata]
> {noformat}
> Table definition for which above columns are associated is as below:
> {noformat}
> CREATE TABLE omni_price_ks_v2.location_price_mstr (
> tcin text,
> location_id bigint,
> price_change_id text,
> default_price_json text static,
> end_ts bigint,
> last_metadata_updt_ts bigint static,
> last_update_ts bigint,
> price_json text,
> price_metadata text static,
> price_type text,
> start_ts bigint,
> status text,
> version text,
> PRIMARY KEY (tcin, location_id, price_change_id)
> ) WITH CLUSTERING ORDER BY (location_id ASC, price_change_id ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = {'keys': 'ALL', 'rows_per_partition': '100'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {noformat}
> App team also observed below error in their application logs when try to read
> from this table.
> {noformat}
> { "code": "ERR_GETPRICE_0034", "message": "Cassandra failure during read
> query at consistency LOCAL_QUORUM (2 responses were required but only 1
> replica responded, 1 failed)" }
> {noformat}
> Because of this error, the application is getting impacted during the upgrade.
> Once the upgrade on all DCs is completed, this error stops.
> I found below bug which matches our case.
> https://issues.apache.org/jira/browse/CASSANDRA-17601
> It seems like we are hitting some bug and hence raising this Jira.
> Can you please have a look if this is still a bug and what would be the fix?
> Let me know if you need any more details.
--
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-19751) IllegalStateException when query on table having static columns during the Cassandra cluster upgrade from 3.11.4 to 4.0.11
[
https://issues.apache.org/jira/browse/CASSANDRA-19751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19751:
---
Resolution: (was: Fixed)
Status: Open (was: Resolved)
> IllegalStateException when query on table having static columns during the
> Cassandra cluster upgrade from 3.11.4 to 4.0.11
> --
>
> Key: CASSANDRA-19751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19751
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: Full-error-stack.txt
>
>
> We are upgrading Cassandra cluster from 3.11.4 to 4.0.11. This cluster has
> SSL enabled.
> While performing upgrade on 1st DC, we observed below WARN/ERROR messages on
> C* 3 and C* 4 nodes.
> +C*3 nodes:+
> {noformat}
> WARN [ReadStage-1] 2024-06-11 08:04:09,088
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-1,5,main]: {}
> java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is
> not a subset of [price_metadata]
> WARN [ReadStage-1] 2024-06-19 05:10:31,226
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-1,5,main]: {}
> java.lang.IllegalStateException: [default_price_json, last_metadata_updt_ts,
> price_metadata] is not a subset of [price_metadata]
> {noformat}
> +C*4 nodes:+
> {noformat}
> ERROR [ReadStage-1] 2024-06-19 05:48:47,388
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[ReadStage-1,5,main]
> java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is
> not a subset of [price_metadata]
> {noformat}
> Table definition for which above columns are associated is as below:
> {noformat}
> CREATE TABLE omni_price_ks_v2.location_price_mstr (
> tcin text,
> location_id bigint,
> price_change_id text,
> default_price_json text static,
> end_ts bigint,
> last_metadata_updt_ts bigint static,
> last_update_ts bigint,
> price_json text,
> price_metadata text static,
> price_type text,
> start_ts bigint,
> status text,
> version text,
> PRIMARY KEY (tcin, location_id, price_change_id)
> ) WITH CLUSTERING ORDER BY (location_id ASC, price_change_id ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = {'keys': 'ALL', 'rows_per_partition': '100'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {noformat}
> App team also observed below error in their application logs when try to read
> from this table.
> {noformat}
> { "code": "ERR_GETPRICE_0034", "message": "Cassandra failure during read
> query at consistency LOCAL_QUORUM (2 responses were required but only 1
> replica responded, 1 failed)" }
> {noformat}
> Because of this error, the application is getting impacted during the upgrade.
> Once the upgrade on all DCs is completed, this error stops.
> I found below bug which matches our case.
> https://issues.apache.org/jira/browse/CASSANDRA-17601
> It seems like we are hitting some bug and hence raising this Jira.
> Can you please have a look if this is still a bug and what would be the fix?
> Let me know if you need any more details.
--
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-19751) IllegalStateException when query on table having static columns during the Cassandra cluster upgrade from 3.11.4 to 4.0.11
[
https://issues.apache.org/jira/browse/CASSANDRA-19751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19751:
---
Resolution: Fixed
Status: Resolved (was: Triage Needed)
> IllegalStateException when query on table having static columns during the
> Cassandra cluster upgrade from 3.11.4 to 4.0.11
> --
>
> Key: CASSANDRA-19751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19751
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: Full-error-stack.txt
>
>
> We are upgrading Cassandra cluster from 3.11.4 to 4.0.11. This cluster has
> SSL enabled.
> While performing upgrade on 1st DC, we observed below WARN/ERROR messages on
> C* 3 and C* 4 nodes.
> +C*3 nodes:+
> {noformat}
> WARN [ReadStage-1] 2024-06-11 08:04:09,088
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-1,5,main]: {}
> java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is
> not a subset of [price_metadata]
> WARN [ReadStage-1] 2024-06-19 05:10:31,226
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-1,5,main]: {}
> java.lang.IllegalStateException: [default_price_json, last_metadata_updt_ts,
> price_metadata] is not a subset of [price_metadata]
> {noformat}
> +C*4 nodes:+
> {noformat}
> ERROR [ReadStage-1] 2024-06-19 05:48:47,388
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[ReadStage-1,5,main]
> java.lang.IllegalStateException: [last_metadata_updt_ts, price_metadata] is
> not a subset of [price_metadata]
> {noformat}
> Table definition for which above columns are associated is as below:
> {noformat}
> CREATE TABLE omni_price_ks_v2.location_price_mstr (
> tcin text,
> location_id bigint,
> price_change_id text,
> default_price_json text static,
> end_ts bigint,
> last_metadata_updt_ts bigint static,
> last_update_ts bigint,
> price_json text,
> price_metadata text static,
> price_type text,
> start_ts bigint,
> status text,
> version text,
> PRIMARY KEY (tcin, location_id, price_change_id)
> ) WITH CLUSTERING ORDER BY (location_id ASC, price_change_id ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = {'keys': 'ALL', 'rows_per_partition': '100'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {noformat}
> App team also observed below error in their application logs when try to read
> from this table.
> {noformat}
> { "code": "ERR_GETPRICE_0034", "message": "Cassandra failure during read
> query at consistency LOCAL_QUORUM (2 responses were required but only 1
> replica responded, 1 failed)" }
> {noformat}
> Because of this error, the application is getting impacted during the upgrade.
> Once the upgrade on all DCs is completed, this error stops.
> I found below bug which matches our case.
> https://issues.apache.org/jira/browse/CASSANDRA-17601
> It seems like we are hitting some bug and hence raising this Jira.
> Can you please have a look if this is still a bug and what would be the fix?
> Let me know if you need any more details.
--
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-19545) Null pointer when running Upgrade Tests
[
https://issues.apache.org/jira/browse/CASSANDRA-19545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17864386#comment-17864386
]
Michael Semb Wever commented on CASSANDRA-19545:
This problem can easily be avoided by using the in-tree scripts instead.
For example:
{code}
.build/run-tests.sh jvm-dtest-upgrade CompactStorageColumnDeleteTest
{code}
(or its docker version: {{`.build/run-tests.sh jvm-dtest-upgrade
CompactStorageColumnDeleteTest 11`}})
I'm still inclined to enforce that all jar files for all expected versions are
in place. i.e. provide an informative fail-fast message.
> Null pointer when running Upgrade Tests
> ---
>
> Key: CASSANDRA-19545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19545
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: ConfX
>Priority: Normal
>
> h2. What happened
> The `UpgradeTestBase.java` may throw null pointer exception when creating the
> version upgrade pairs in `upgradesTo()` method.
> The problem happens in the for loop shown below. The `upgradesTo()` calls
> `versions.getLatest(Semver version)` method to create the `Version` class.
> {code:java}
> for (Semver start : vertices.subSet(lowerBound, true, to, false))
> {
> // only include pairs that are allowed, and start or end on CURRENT
> if (SUPPORTED_UPGRADE_PATHS.hasEdge(start, to) &&
> edgeTouchesTarget(start, to, CURRENT))
> upgrade.add(new TestVersions(versions.getLatest(start),
> Collections.singletonList(versions.getLatest(to;
> } {code}
> However, in the `Version.java`, `getLatest()` function never checks whether
> the `first(version)` is in the `versions` map or not. When the version is not
> there, a null pointer exception will be thrown and crash all the upgrade
> tests.
> {code:java}
> public Version getLatest(Semver version)
> {
> return versions.get(first(version)) // <--- Here might cause NPE
> .stream()
> .findFirst()
> .orElseThrow(() -> new RuntimeException("No " +
> version + " versions found"));
> }
> {code}
> h2. How to reproduce
> To reproduce this bug, I'm running Cassandra with commit SHA
> `310d790ce4734727f943225eb951ab0d889c0a5b`; and dtest API with
> `dtest-api-0.0.16.jar`.
> The versions I put under `build/` directory are:
> dtest-4.0.9.jar, dtest-4.0.13.jar, dtest-4.1.4.jar, and dtest-5.1.jar.
> The command I'm running is:
> {code:java}
> $ ant test-jvm-dtest-some -Duse.jdk11=true
> -Dtest.name=org.apache.cassandra.distributed.upgrade.UpgradeTest {code}
> The error message I got was:
> {code:java}
> [junit-timeout] INFO [main] 2024-04-08 17:34:23,936 Versions.java:136
> - Looking for dtest jars in /Users/xxx/Documents/xxx/cassandra/build
> [junit-timeout] Found 4.0.13, 4.0.9
> [junit-timeout] Found 4.1.4
> [junit-timeout] Found 5.1
> [junit-timeout] - ---
> [junit-timeout] Testcase:
> simpleUpgradeWithNetworkAndGossipTest(org.apache.cassandra.distributed.upgrade.UpgradeTest)-_jdk11:
> Caused an ERROR
> [junit-timeout] null
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.distributed.shared.Versions.getLatest(Versions.java:127)
> [junit-timeout] at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.upgradesTo(UpgradeTestBase.java:218)
> [junit-timeout] at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.upgradesToCurrentFrom(UpgradeTestBase.java:203)
> [junit-timeout] at
> org.apache.cassandra.distributed.upgrade.UpgradeTest.simpleUpgradeWithNetworkAndGossipTest(UpgradeTest.java:37)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.distributed.upgrade.UpgradeTest
> FAILED
> {code}
> With some debugging, the version causing the null pointer is `5.0-alpha1`,
> but this version is not shown in `build/` directory and should not be tested
> if I understand correctly.
> h2. How to fix.
> There are two ways to fix this problem. One is to add a null pointer checker
> in `UpgradeTestBase#upgradesTo()`, and the other approach is to add the null
> pointer in `Versions#getLatest()`.
> I would love to provide a PR to fix this issue if you can tell me which fix
> looks better to you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CASSANDRA-19734) Rate limiting per-node on failed log-in attempts
[ https://issues.apache.org/jira/browse/CASSANDRA-19734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17864360#comment-17864360 ] Michael Semb Wever commented on CASSANDRA-19734: bq. Should the database operator/administrator be able to reset the time window as well? I'm thinking about the legitimate user being locked out (typing the password wrong happens... ) and contacting the administrator to reset the window (or the password for that matter). Yes, having a nodetool command (jmx and vtable) to list locked roles, their time, and being able to manually unlock them would be useful. > Rate limiting per-node on failed log-in attempts > > > Key: CASSANDRA-19734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19734 > Project: Cassandra > Issue Type: New Feature > Components: CQL/Syntax, Feature/Authorization >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > If there is a malicious attacker who is brute-forcing passwords / usernames, > we should just ban such user for some time. On the other hand, we should > enable logging in for genuine users who just happened to provide invalid > passwords for multiple times, we do not want to ban these completely. > A rate limit might be something like "5 times per a minute". > This should be based on IP address of a client to identify the attacker. If > we based this on invalid passwords only, an attacker might just change the > usernames to bypass 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] [Comment Edited] (CASSANDRA-18942) Repeatable java test runs on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863349#comment-17863349 ] Michael Semb Wever edited comment on CASSANDRA-18942 at 7/6/24 2:10 PM: Rebased patch on latest 5.0 https://github.com/apache/cassandra/compare/cassandra-5.0...thelastpickle:cassandra:mck/18942/5.0 Small changes: - no additional "-enhanced.sh" scripts. update existing scripts, add in legacy parameter handling - treat "-repeat" as a reserved target type suffix, instead of handling it case-by-case inside the switch statement - simplify readme to just what's not deprecated - replace head with sed (crashing on SIGPIPE) - simplify some logic/conditional - added pre-conditions / assertions was (Author: michaelsembwever): Rebased patch on latest 5.0 https://github.com/apache/cassandra/compare/cassandra-5.0...thelastpickle:cassandra:mck/18942/5.0 Small changes: - no additional "-enhanced.sh" scripts. update existing scripts, add in legacy parameter handling - treat "-repeat" as a reserved target type suffix, instead of handling it case-by-case inside the switch statement > Repeatable java test runs on jenkins > > > Key: CASSANDRA-18942 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18942 > Project: Cassandra > Issue Type: New Feature > Components: Build, CI >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0, 5.0.x > > Attachments: jenkins_job.xml, testJava.txt, testJavaDocker.txt, > testJavaSplits.txt > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is our policy to loop new introduced tests to avoid introducing flakies. > We also want to add the possibility to repeat a test N number of times to > test robustness, debug flakies, etc. -- 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-19708) Remove sid from bullseye docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-19708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19708: --- Fix Version/s: 3.0.31 3.11.18 4.0.14 4.1.6 5.0-beta2 5.0 5.1 (was: 3.11.x) (was: 4.0.x) (was: 4.1.x) Since Version: NA Source Control Link: https://github.com/apache/cassandra/commit/461b8c42d24b6906332949fa6f1bf110d08b7f06 https://github.com/apache/cassandra-builds/commit/f78b888f20127f85bd4dd0eb900d9598d0a43833 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as https://github.com/apache/cassandra/commit/461b8c42d24b6906332949fa6f1bf110d08b7f06 > Remove sid from bullseye docker images > -- > > Key: CASSANDRA-19708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 3.0.x, 3.0.31, 3.11.18, 4.0.14, 4.1.6, 5.0-beta2, 5.0, > 5.1 > > Attachments: CASSANDRA-19708_50_105_ci_summary.html, > CASSANDRA-19708_50_105_results_details.tar.xz > > > sid is flakey, often broken and takes days for correct packages to be > uploaded. > ref: > https://ci-cassandra.apache.org/job/Cassandra-4.1-artifacts/jdk=jdk_1.8_latest,label=cassandra/611/ > > sid is only used for jdk8 > looks like replacing it with temurin might be a safer/stable choice. -- 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
