[cassandra-website] branch asf-site updated (f3141df -> 04242f3)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard f3141df hack in plausible tracking with `find content -name
"*.html" -exec sed -i '' 's;^;https://plausible.cassandra.apache.org/js/plausible.js";>;'
{} \;`
discard c39e738 generate docs for 3c22fbe3
add c24f2cb CASSANDRA-16549 Placed a World Party button on the homepage
add 9400010 CASSANDRA-16574 Updated World Party pages with registration
link
add 4fcf72e generate docs for 9400010a
new 04242f3 hack in plausible tracking with `find
content -name "*.html" -exec sed -i '' 's;^;https://plausible.cassandra.apache.org/js/plausible.js";>;'
{} \;`
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (f3141df)
\
N -- N -- N refs/heads/asf-site (04242f3)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
content/blog/2021/03/25/world_party.html | 6 +-
content/doc/3.11.11/index.html | 89 -
content/doc/4.0-rc1/index.html | 89 -
content/doc/4.0-rc1/tools/nodetool/bootstrap.html | 6 +-
content/doc/4.0-rc1/tools/nodetool/import.html | 6 +-
content/doc/4.0-rc1/tools/nodetool/nodetool.html | 6 +-
.../doc/4.0-rc1/tools/nodetool/repair_admin.html | 59 +++---
content/doc/latest/index.html | 89 -
content/doc/latest/tools/nodetool/bootstrap.html | 6 +-
content/doc/latest/tools/nodetool/import.html | 6 +-
content/doc/latest/tools/nodetool/nodetool.html| 6 +-
.../doc/latest/tools/nodetool/repair_admin.html| 59 +++---
content/doc/stable/index.html | 89 -
content/feed.xml | 8 +-
content/img/1x1.png| Bin 0 -> 95 bytes
content/index.html | 7 ++
content/worldparty/index.html | 9 ++-
src/_includes/nav.html | 7 ++
src/_posts/2021-03-25-world_party.markdown | 6 +-
src/doc/3.11.11/index.html | 89 +++--
.../_sources/tools/nodetool/nodetool.rst.txt | 6 +-
src/doc/4.0-rc1/index.html | 89 -
src/doc/4.0-rc1/tools/nodetool/bootstrap.html | 6 +-
src/doc/4.0-rc1/tools/nodetool/import.html | 6 +-
src/doc/4.0-rc1/tools/nodetool/nodetool.html | 6 +-
src/doc/4.0-rc1/tools/nodetool/repair_admin.html | 59 +++---
src/img/1x1.png| Bin 0 -> 95 bytes
src/world_party-2021.md| 10 +--
28 files changed, 602 insertions(+), 222 deletions(-)
create mode 100755 content/img/1x1.png
create mode 100755 src/img/1x1.png
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] 03/03: hack in plausible tracking with `find content -name "*.html" -exec sed -i '' 's; ;
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
commit 0f51058b2c632da7f3e1ab6f3f18129e349699ca
Author: mck
AuthorDate: Tue Apr 6 11:54:32 2021 +0200
hack in plausible tracking with
`find content -name "*.html" -exec sed -i '' 's;;https://plausible.cassandra.apache.org/js/plausible.js";>;'
{} \;`
---
content/blog/Apache-Cassandra-Changelog-1-October-2020.html | 2 +-
content/blog/Apache-Cassandra-Changelog-2-December-2020.html| 2 +-
content/blog/Apache-Cassandra-Changelog-3-January-2021.html | 2 +-
content/blog/Apache-Cassandra-Changelog-4-February-2021.html| 2 +-
content/blog/Apache-Cassandra-Usage-Report-2020.html| 2 +-
content/blog/Audit-Logging-in-Apache-Cassandra-4.html | 2 +-
content/blog/Cassandra-and-Kubernetes-SIG-Update-and-Survey.html| 2 +-
...en-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4 .html | 2 +-
...nding-Bugs-in-Cassandra's-Internals-with-Property-based-Testing.html | 2 +-
.../blog/Hardware-bound-Zero-Copy-Streaming-in-Apache-Cassandra-4.html | 2 +-
.../blog/Improving-Apache-Cassandras-Front-Door-and-Backpressure.html | 2 +-
.../Introducing-Apache-Cassandra-4-Beta-Battle-Tested-From-Day-One.html | 2 +-
content/blog/Introducing-Transient-Replication.html | 2 +-
content/blog/Testing-Apache-Cassandra-4.html| 2 +-
content/blog/cass-changelog_2.html | 2 +-
content/blog/cass-changelog_3.html | 2 +-
content/blog/index.html | 2 +-
content/blog/template.html | 2 +-
content/case-studies/index.html | 2 +-
content/cassandra-basics/index.html | 2 +-
content/community/index.html| 2 +-
content/download/index.html | 2 +-
content/ecosystem/index.html| 2 +-
content/index.html | 2 +-
content/quickstart/index.html | 2 +-
content/resources/index.html| 2 +-
26 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/content/blog/Apache-Cassandra-Changelog-1-October-2020.html
b/content/blog/Apache-Cassandra-Changelog-1-October-2020.html
index 48cd465..4126d92 100644
--- a/content/blog/Apache-Cassandra-Changelog-1-October-2020.html
+++ b/content/blog/Apache-Cassandra-Changelog-1-October-2020.html
@@ -12,7 +12,7 @@
-
+ https://plausible.cassandra.apache.org/js/plausible.js";>
diff --git a/content/blog/Apache-Cassandra-Changelog-2-December-2020.html
b/content/blog/Apache-Cassandra-Changelog-2-December-2020.html
index b31b618..f8d7646 100644
--- a/content/blog/Apache-Cassandra-Changelog-2-December-2020.html
+++ b/content/blog/Apache-Cassandra-Changelog-2-December-2020.html
@@ -12,7 +12,7 @@
-
+ https://plausible.cassandra.apache.org/js/plausible.js";>
diff --git a/content/blog/Apache-Cassandra-Changelog-3-January-2021.html
b/content/blog/Apache-Cassandra-Changelog-3-January-2021.html
index 39caa53..e11729c 100644
--- a/content/blog/Apache-Cassandra-Changelog-3-January-2021.html
+++ b/content/blog/Apache-Cassandra-Changelog-3-January-2021.html
@@ -12,7 +12,7 @@
-
+ https://plausible.cassandra.apache.org/js/plausible.js";>
diff --git a/content/blog/Apache-Cassandra-Changelog-4-February-2021.html
b/content/blog/Apache-Cassandra-Changelog-4-February-2021.html
index e1cd37e..5c665b6 100644
--- a/content/blog/Apache-Cassandra-Changelog-4-February-2021.html
+++ b/content/blog/Apache-Cassandra-Changelog-4-February-2021.html
@@ -12,7 +12,7 @@
-
+ https://plausible.cassandra.apache.org/js/plausible.js";>
diff --git a/content/blog/Apache-Cassandra-Usage-Report-2020.html
b/content/blog/Apache-Cassandra-Usage-Report-2020.html
index f33055e..d075030 100644
--- a/content/blog/Apache-Cassandra-Usage-Report-2020.html
+++ b/content/blog/Apache-Cassandra-Usage-Report-2020.html
@@ -12,7 +12,7 @@
-
+ https://plausible.cassandra.apache.org/js/plausible.js";>
[jira] [Updated] (CASSANDRA-16549) WEBSITE - Place a World Party button on the homepage
[ https://issues.apache.org/jira/browse/CASSANDRA-16549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16549: -- Status: Review In Progress (was: Patch Available) > WEBSITE - Place a World Party button on the homepage > > > Key: CASSANDRA-16549 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16549 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-beta4 > > Attachments: website-cassandra-16549.png > > > Place a World Party button on the [homepage|https://cassandra.apache.org/] to > promote the event in April 2021. > +ninja: Remove title from [World > Party|https://cassandra.apache.org/worldparty/] landing page for cosmetic > reasons. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16549) WEBSITE - Place a World Party button on the homepage
[ https://issues.apache.org/jira/browse/CASSANDRA-16549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16549: -- Status: Ready to Commit (was: Review In Progress) > WEBSITE - Place a World Party button on the homepage > > > Key: CASSANDRA-16549 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16549 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-beta4 > > Attachments: website-cassandra-16549.png > > > Place a World Party button on the [homepage|https://cassandra.apache.org/] to > promote the event in April 2021. > +ninja: Remove title from [World > Party|https://cassandra.apache.org/worldparty/] landing page for cosmetic > reasons. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15561) Extract Javadoc into a separate package
[
https://issues.apache.org/jira/browse/CASSANDRA-15561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15561:
---
Test and Documentation Plan: manual
Status: Patch Available (was: Open)
> Extract Javadoc into a separate package
> ---
>
> Key: CASSANDRA-15561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15561
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Alex Ott
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Right now, the {{javadoc}} directory occupies 99Mb out of the 149Mb of
> Cassandra 4.0-alpha3 installation. It would be useful to extract Javadocs
> into a separate package for package installations (RPM/DEB), and maybe create
> a separate artifact for tarball (or include them into {{src}}?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15561) Extract Javadoc into a separate package
[
https://issues.apache.org/jira/browse/CASSANDRA-15561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15561:
---
Change Category: Quality Assurance
Complexity: Normal
Fix Version/s: (was: 3.11.x)
(was: 3.0.x)
(was: 2.2.x)
4.0.x
Assignee: Michael Semb Wever
Priority: Low (was: Normal)
Status: Open (was: Triage Needed)
patch at
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/15561/trunk
> Extract Javadoc into a separate package
> ---
>
> Key: CASSANDRA-15561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15561
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Alex Ott
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Right now, the {{javadoc}} directory occupies 99Mb out of the 149Mb of
> Cassandra 4.0-alpha3 installation. It would be useful to extract Javadocs
> into a separate package for package installations (RPM/DEB), and maybe create
> a separate artifact for tarball (or include them into {{src}}?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16549) WEBSITE - Place a World Party button on the homepage
[ https://issues.apache.org/jira/browse/CASSANDRA-16549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16549: -- Source Control Link: https://github.com/apache/cassandra-website/commit/c24f2cb2999efa9753fbd53836b2a9226f2c82f2 Resolution: Fixed Status: Resolved (was: Ready to Commit) > WEBSITE - Place a World Party button on the homepage > > > Key: CASSANDRA-16549 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16549 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-beta4 > > Attachments: website-cassandra-16549.png > > > Place a World Party button on the [homepage|https://cassandra.apache.org/] to > promote the event in April 2021. > +ninja: Remove title from [World > Party|https://cassandra.apache.org/worldparty/] landing page for cosmetic > reasons. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16574) WEBSITE - Update World Party blog + landing page with registration link
[ https://issues.apache.org/jira/browse/CASSANDRA-16574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16574: -- Source Control Link: https://github.com/apache/cassandra-website/commit/9400010a0b3499e69221e41e5f4ceb2d236e3ca2 Resolution: Fixed Status: Resolved (was: Ready to Commit) > WEBSITE - Update World Party blog + landing page with registration link > --- > > Key: CASSANDRA-16574 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16574 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-beta4 > > Attachments: CASSANDRA-16574-blog_post.png, > CASSANDRA-16574-landing_page.png > > > There is now a registration link for the World Party – > [https://hopin.com/events/apache-cassandra-4-0-world-party.] > Need to update the following pages: > * Landing page - [https://cassandra.apache.org/worldparty/] > * Blog post - [https://cassandra.apache.org/blog/2021/03/25/world_party.html] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16574) WEBSITE - Update World Party blog + landing page with registration link
[ https://issues.apache.org/jira/browse/CASSANDRA-16574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16574: -- Status: Ready to Commit (was: Review In Progress) > WEBSITE - Update World Party blog + landing page with registration link > --- > > Key: CASSANDRA-16574 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16574 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-beta4 > > Attachments: CASSANDRA-16574-blog_post.png, > CASSANDRA-16574-landing_page.png > > > There is now a registration link for the World Party – > [https://hopin.com/events/apache-cassandra-4-0-world-party.] > Need to update the following pages: > * Landing page - [https://cassandra.apache.org/worldparty/] > * Blog post - [https://cassandra.apache.org/blog/2021/03/25/world_party.html] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16574) WEBSITE - Update World Party blog + landing page with registration link
[ https://issues.apache.org/jira/browse/CASSANDRA-16574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16574: -- Status: Review In Progress (was: Patch Available) > WEBSITE - Update World Party blog + landing page with registration link > --- > > Key: CASSANDRA-16574 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16574 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 4.0-beta4 > > Attachments: CASSANDRA-16574-blog_post.png, > CASSANDRA-16574-landing_page.png > > > There is now a registration link for the World Party – > [https://hopin.com/events/apache-cassandra-4-0-world-party.] > Need to update the following pages: > * Landing page - [https://cassandra.apache.org/worldparty/] > * Blog post - [https://cassandra.apache.org/blog/2021/03/25/world_party.html] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317739#comment-17317739
]
Jacek Lewandowski commented on CASSANDRA-16497:
---
I know what is broken in this test and I can fix it
There were two problems in this test. First is that what is called 'timeout'
has a 'deadline'
semantics which means that it is a point in time rather than a duration.
However in one place
it was used as a timeout, thus everything got confused at some point and the
actual deadlines
turned out to be negative.
The other problem was that with some probability we choose a deadline as
Long.MAX_VALUE.
After that, we call Future.get with the corresponding timeout - the timeout is
calculated by
subtracting System.nanotime from our deadline (which is Long.MAX_VALUE).
However, Future.get
internally adds back System.nanotime to the timeout and passed that to some
internal method
await. The problem is that, between subtracting System.nanotime and adding it
back, some
time elapses and the second call to System.nanotime returns a larger value,
thus the deadline
calculated internally in Future.get overflows the long domain.
I can fix it if you like
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc1, 4.0
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16569) Flaky StorageServiceServerTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16569: Test and Documentation Plan: See PR Status: Patch Available (was: In Progress) > Flaky StorageServiceServerTest > -- > > Key: CASSANDRA-16569 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16569 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > Failing on > [ci-cass|https://ci-cassandra.apache.org/job/Cassandra-trunk/411/testReport/junit/org.apache.cassandra.service/StorageServiceServerTest/testLocalPrimaryRangeForEndpointWithNetworkTopologyStrategy_compression/] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16569) Flaky StorageServiceServerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317764#comment-17317764
]
Berenguer Blasi commented on CASSANDRA-16569:
-
I haven't managed to repro neither find a thread I could start pulling from. I
am leaving here steps to run the test under a docker container such as in
jenkins for completion:
{noformat}
To run the test under the sh jenkins uses run this line. 6/8 tells it what
split to run which you'll have to find by trial and error
./cassandra-builds/build-scripts/cassandra-test.sh test-compression 6/8
To run the test under a docker container so it is exactly as in jenkins:
./cassandra-builds/build-scripts/cassandra-test-docker.sh apache trunk
https://github.com/apache/cassandra-builds.git trunk
apache/cassandra-testing-ubuntu2004-java11 test 6/8
{noformat}
Despite running it under the jenkins/docker script on a severely downgraded
machine where execution went from 3m to 2h it would still not repro. So I am
attaching a PR with verbose asserts I am proposing to merge and next time it
fails see if it provides something to go on from.
> Flaky StorageServiceServerTest
> --
>
> Key: CASSANDRA-16569
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16569
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failing on
> [ci-cass|https://ci-cassandra.apache.org/job/Cassandra-trunk/411/testReport/junit/org.apache.cassandra.service/StorageServiceServerTest/testLocalPrimaryRangeForEndpointWithNetworkTopologyStrategy_compression/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317778#comment-17317778
]
Benjamin Lerer commented on CASSANDRA-16497:
[~jlewandowski] I do not recall exactly all the problems I found when I looked
at the test. I definetly fixed the second one. Not sure for the first problem.
I found also that in my environment there was a reordering occuring depending
on the way task were scheduled on the threads. Overall, I managed to improve
the number of runs that I was able to do but I never managed to make it pass in
my environment. Some people had the test failing constantly in their
environment other not.
Feel free to have a go at it. You might be more successfull than me :-)
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc1, 4.0
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16190) Add tests for streaming metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317781#comment-17317781 ] Benjamin Lerer commented on CASSANDRA-16190: [~e.dimitrova] I pushed a fix for your suggestions 3 days ago and thought you might want to look at them before I committed. I will commit. > Add tests for streaming metrics > --- > > Key: CASSANDRA-16190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16190 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.0-rc > > > We currently have no tests to checks the streaming metrics -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15871) Cassandra driver first connection get the user's own schema information
[ https://issues.apache.org/jira/browse/CASSANDRA-15871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-15871: -- Assignee: Benjamin Lerer > Cassandra driver first connection get the user's own schema information > > > Key: CASSANDRA-15871 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15871 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema, Messaging/Client >Reporter: maxwellguo >Assignee: Benjamin Lerer >Priority: Normal > Attachments: 1.jpg > > > We know that cassandra driver making a conenction with the coordinator node > first time , the driver may select all the keyspaces/tables/columns/types > from the server and cache the data locally. > For different users they may have different tables and types ，so It is not > suitable to get all the meta data cached , It is fine to just cache the > user's own schema information not all. > And doing this is safe and save first time connection resourse. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[ https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16581: Reviewers: Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe) Sam Tunnicliffe, Sam Tunnicliffe Status: Review In Progress (was: Patch Available) > Failure to execute queries should emit a KPI other than read > timeout/unavailable so it can be alerted/tracked > - > > Key: CASSANDRA-16581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16581 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-rc > > > When we are unable to parse a message we do not have a way to detect this > from a monitoring point of view so can get into situations where we believe > the database is fine but the clients are on-fire. This case popped up in the > 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16575) "compression" configuration in unit tests is incorrect and actually redundant
[
https://issues.apache.org/jira/browse/CASSANDRA-16575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317806#comment-17317806
]
Jacek Lewandowski commented on CASSANDRA-16575:
---
I was wrong, the compression tests are aimed to test sstable compression which
is explicitly disabled when running just {{unit}} tests. SchemaLoader forces no
compression for each table that is created through that utility in tests; Also
when compression is enabled, it forces snappy compressor to be used for those
tables. All other tables are created with the default LZ4.
Therefore it seems like the compression configuration has nothing to do with
commit log compression and the only thing we should consider to use the current
default compressor LZ4 instead of Snappy and remove the misleading fragment of
the build.
I'm still thinking that we should allow for passing test configuration without
the need to modify the build.
> "compression" configuration in unit tests is incorrect and actually redundant
> -
>
> Key: CASSANDRA-16575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16575
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> When running unit tests with "compression" configuration, we actually not use
> compression at all we run just unit tests without compression (which is
> redundant when running on CI).
> The reason is that for the compression configuration we (try to) do the
> following:
> {code}
>value="${build.test.dir}/cassandra.compressed.yaml"/>
>
>
>
>
> {code}
> however, {{cassandra.compressed.yaml}} has been replaced in CASSANDRA-14482
> by two files {{commitlog_compression_LZ4.yaml}} and
> {{commitlog_compression_Zstd.yaml}} without changing build configuration.
> All in all we could fix that but I doubt it makes any sense since {{cdc}}
> configuration already uses compressed commit log anyway so it feels redundant
> to test compression alone for each CI run.
> I vote for removing compression configuration and actually allow to manually
> specify yaml file to be used for testing as a test property, as well as allow
> to manually specify extra system properties to be passed to the test. That
> would make the build more flexible and remove a bit of redundant code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317810#comment-17317810
]
Jacek Lewandowski commented on CASSANDRA-16497:
---
[~blerer] my patch is here: https://github.com/apache/cassandra/pull/956
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc1, 4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
[
https://issues.apache.org/jira/browse/CASSANDRA-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317813#comment-17317813
]
Jacek Lewandowski commented on CASSANDRA-16497:
---
The first problem is in
https://github.com/apache/cassandra/pull/956/files?diff=unified&w=1#diff-0fae2f0ba0b0832a5608edbff166a3b81d35dbb795ddef6e7a92ec0f086f61f2L151
> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc1, 4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16575) "compression" configuration in unit tests is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-16575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-16575:
--
Summary: "compression" configuration in unit tests is incorrect (was:
"compression" configuration in unit tests is incorrect and actually redundant)
> "compression" configuration in unit tests is incorrect
> --
>
> Key: CASSANDRA-16575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16575
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> When running unit tests with "compression" configuration, we actually not use
> compression at all we run just unit tests without compression (which is
> redundant when running on CI).
> The reason is that for the compression configuration we (try to) do the
> following:
> {code}
>value="${build.test.dir}/cassandra.compressed.yaml"/>
>
>
>
>
> {code}
> however, {{cassandra.compressed.yaml}} has been replaced in CASSANDRA-14482
> by two files {{commitlog_compression_LZ4.yaml}} and
> {{commitlog_compression_Zstd.yaml}} without changing build configuration.
> All in all we could fix that but I doubt it makes any sense since {{cdc}}
> configuration already uses compressed commit log anyway so it feels redundant
> to test compression alone for each CI run.
> I vote for removing compression configuration and actually allow to manually
> specify yaml file to be used for testing as a test property, as well as allow
> to manually specify extra system properties to be passed to the test. That
> would make the build more flexible and remove a bit of redundant code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16575) "compression" configuration in unit tests is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-16575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-16575:
--
Description:
When running unit tests with "compression" configuration, we use non-default
Snappy compressor.
There is a misleading fragment of {{build.xml}}:
{code}
{code}
{{cassandra.compressed.yaml}} has been replaced in CASSANDRA-14482 by two files
{{commitlog_compression_LZ4.yaml}} and {{commitlog_compression_Zstd.yaml}}
without changing build configuration.
All in all we could fix that but I doubt it makes any sense since {{cdc}}
configuration already uses compressed commit log anyway so it feels redundant
to test compression alone for each CI run.
was:
When running unit tests with "compression" configuration, we actually not use
compression at all we run just unit tests without compression (which is
redundant when running on CI).
The reason is that for the compression configuration we (try to) do the
following:
{code}
{code}
however, {{cassandra.compressed.yaml}} has been replaced in CASSANDRA-14482 by
two files {{commitlog_compression_LZ4.yaml}} and
{{commitlog_compression_Zstd.yaml}} without changing build configuration.
All in all we could fix that but I doubt it makes any sense since {{cdc}}
configuration already uses compressed commit log anyway so it feels redundant
to test compression alone for each CI run.
I vote for removing compression configuration and actually allow to manually
specify yaml file to be used for testing as a test property, as well as allow
to manually specify extra system properties to be passed to the test. That
would make the build more flexible and remove a bit of redundant code.
> "compression" configuration in unit tests is incorrect
> --
>
> Key: CASSANDRA-16575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16575
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> When running unit tests with "compression" configuration, we use non-default
> Snappy compressor.
> There is a misleading fragment of {{build.xml}}:
> {code}
>value="${build.test.dir}/cassandra.compressed.yaml"/>
>
>
>
>
> {code}
> {{cassandra.compressed.yaml}} has been replaced in CASSANDRA-14482 by two
> files {{commitlog_compression_LZ4.yaml}} and
> {{commitlog_compression_Zstd.yaml}} without changing build configuration.
> All in all we could fix that but I doubt it makes any sense since {{cdc}}
> configuration already uses compressed commit log anyway so it feels redundant
> to test compression alone for each CI run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16577:
--
Reviewers: Andres de la Peña
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16577:
--
Reviewers: Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16583) Dont fork jvms in the build
[
https://issues.apache.org/jira/browse/CASSANDRA-16583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16583:
---
Fix Version/s: 4.0.x
> Dont fork jvms in the build
> ---
>
> Key: CASSANDRA-16583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16583
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x
>
>
> Most developer and build machines have more than 1GB RAM now-a-days. The need
> to fork to specify {{`-Xmx512m`}} is redundant.
> Removing the fork flags removes >25% of the build time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16583) Dont fork jvms in the build
Michael Semb Wever created CASSANDRA-16583:
--
Summary: Dont fork jvms in the build
Key: CASSANDRA-16583
URL: https://issues.apache.org/jira/browse/CASSANDRA-16583
Project: Cassandra
Issue Type: Task
Components: Build
Reporter: Michael Semb Wever
Assignee: Michael Semb Wever
Most developer and build machines have more than 1GB RAM now-a-days. The need
to fork to specify {{`-Xmx512m`}} is redundant.
Removing the fork flags removes >25% of the build time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16583) Dont fork jvms in the build
[
https://issues.apache.org/jira/browse/CASSANDRA-16583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16583:
---
Test and Documentation Plan: CI
Status: Patch Available (was: Open)
> Dont fork jvms in the build
> ---
>
> Key: CASSANDRA-16583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16583
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Most developer and build machines have more than 1GB RAM now-a-days. The need
> to fork to specify {{`-Xmx512m`}} is redundant.
> Removing the fork flags removes >25% of the build time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16583) Dont fork jvms in the build
[
https://issues.apache.org/jira/browse/CASSANDRA-16583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16583:
---
Change Category: Performance
Complexity: Low Hanging Fruit
Priority: Low (was: Normal)
Status: Open (was: Triage Needed)
patch at
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16583/trunk
> Dont fork jvms in the build
> ---
>
> Key: CASSANDRA-16583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16583
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Most developer and build machines have more than 1GB RAM now-a-days. The need
> to fork to specify {{`-Xmx512m`}} is redundant.
> Removing the fork flags removes >25% of the build time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317944#comment-17317944
]
Jan Karlsson commented on CASSANDRA-16577:
--
Tried to reproduce with your patch. It worked both on 4.0-rc1-SNAPSHOT and
3.11.11-SNAPSHOT.
As for the code, LGTM. One nit would be to include the ignore log message into
the exception instead of the warning.
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16575) "compression" configuration in unit tests is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-16575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317947#comment-17317947
]
Jacek Lewandowski commented on CASSANDRA-16575:
---
This is my proposal: https://github.com/apache/cassandra/pull/957
> "compression" configuration in unit tests is incorrect
> --
>
> Key: CASSANDRA-16575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16575
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jacek Lewandowski
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When running unit tests with "compression" configuration, we use non-default
> Snappy compressor.
> There is a misleading fragment of {{build.xml}}:
> {code}
>value="${build.test.dir}/cassandra.compressed.yaml"/>
>
>
>
>
> {code}
> {{cassandra.compressed.yaml}} has been replaced in CASSANDRA-14482 by two
> files {{commitlog_compression_LZ4.yaml}} and
> {{commitlog_compression_Zstd.yaml}} without changing build configuration.
> All in all we could fix that but I doubt it makes any sense since {{cdc}}
> configuration already uses compressed commit log anyway so it feels redundant
> to test compression alone for each CI run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16583) Dont fork jvms in the build
[
https://issues.apache.org/jira/browse/CASSANDRA-16583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317958#comment-17317958
]
Brandon Williams commented on CASSANDRA-16583:
--
+1
> Dont fork jvms in the build
> ---
>
> Key: CASSANDRA-16583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16583
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Most developer and build machines have more than 1GB RAM now-a-days. The need
> to fork to specify {{`-Xmx512m`}} is redundant.
> Removing the fork flags removes >25% of the build time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16577:
-
Status: Patch Available (was: Review In Progress)
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16577:
-
Status: Open (was: Patch Available)
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317959#comment-17317959
]
Brandon Williams commented on CASSANDRA-16577:
--
This broke some dtests, will post a new revision soon, and fix your nit.
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15561) Extract Javadoc into a separate package
[
https://issues.apache.org/jira/browse/CASSANDRA-15561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317965#comment-17317965
]
Brandon Williams commented on CASSANDRA-15561:
--
+1. Should we add a doc package (deb/rpm) in another ticket?
> Extract Javadoc into a separate package
> ---
>
> Key: CASSANDRA-15561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15561
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Alex Ott
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Right now, the {{javadoc}} directory occupies 99Mb out of the 149Mb of
> Cassandra 4.0-alpha3 installation. It would be useful to extract Javadocs
> into a separate package for package installations (RPM/DEB), and maybe create
> a separate artifact for tarball (or include them into {{src}}?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16582:
-
Component/s: Messaging/Internode
Discovered By: User Report
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
Perhaps we should have padded this enum out, the way we do in ApplicationState
to avoid these kinds of errors in mixed versions.
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannel
[jira] [Commented] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317980#comment-17317980
]
Andres de la Peña commented on CASSANDRA-16577:
---
Confirmed that the dtest nicely reproduces the failure for trunk, but I think
that for 3.0 and 3.11 it fails earlier than expected due to the usage of
{{--force}} in the call to {{nodetool decomission}}. This option doesn't exist
in those branches, since it was added only for 4.0 by CASSANDRA-12510. Also, we
could add a {{@jira_ticket}} reference to this ticket in the docstring for the
new dtest. I'm still looking at the fix itself and the affected dtests.
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317992#comment-17317992
]
Brandon Williams commented on CASSANDRA-16577:
--
Updated [detst|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-16577]
and [patch|https://github.com/driftx/cassandra/tree/CASSANDRA-16577].
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317992#comment-17317992
]
Brandon Williams edited comment on CASSANDRA-16577 at 4/9/21, 1:42 PM:
---
Updated [detst|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-16577]
and [patch|https://github.com/driftx/cassandra/tree/CASSANDRA-16577].
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/599/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/599/pipeline]
was (Author: brandon.williams):
Updated [detst|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-16577]
and [patch|https://github.com/driftx/cassandra/tree/CASSANDRA-16577].
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16582:
-
Since Version: 4.0-alpha1 (was: 4.0-beta3)
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792)
> at
> io.netty.channel.epoll.AbstractEpollChannel$A
[cassandra] branch trunk updated: Fix Streaming Repair metrics
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new c4e4e93 Fix Streaming Repair metrics
c4e4e93 is described below
commit c4e4e9388b229a0db92c16029fd647909cec5737
Author: Benjamin Lerer
AuthorDate: Wed Mar 24 17:23:51 2021 +0100
Fix Streaming Repair metrics
patch by Benjamin Lerer; reviewed by Ekaterina Dimitrova for
CASSANDRA-16190
---
CHANGES.txt| 1 +
.../apache/cassandra/streaming/StreamSession.java | 17 +-
.../test/metrics/StreamingMetricsTest.java | 402 +
3 files changed, 349 insertions(+), 71 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 99c8c97..590a4a4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-rc1
+ * Fix Streaming Repair metrics (CASSANDRA-16190)
* Scheduled (delayed) schema pull tasks should not run after MIGRATION stage
shutdown during decommission (CASSANDRA-16495)
* When behind a firewall trunk is not buildable, need to allow overriding
URLs (CASSANDRA-16563)
* Make sure sstables with moved starts are removed correctly in
LeveledGenerations (CASSANDRA-16552)
diff --git a/src/java/org/apache/cassandra/streaming/StreamSession.java
b/src/java/org/apache/cassandra/streaming/StreamSession.java
index a3ffef1..3a32834 100644
--- a/src/java/org/apache/cassandra/streaming/StreamSession.java
+++ b/src/java/org/apache/cassandra/streaming/StreamSession.java
@@ -615,21 +615,11 @@ public class StreamSession implements
IEndpointStateChangeSubscriber
state(State.PREPARING);
PrepareSynMessage prepare = new PrepareSynMessage();
prepare.requests.addAll(requests);
-long totalBytesToStream = 0;
-long totalSSTablesStreamed = 0;
for (StreamTransferTask task : transfers.values())
{
-totalBytesToStream += task.getTotalSize();
-totalSSTablesStreamed += task.getTotalNumberOfFiles();
prepare.summaries.add(task.getSummary());
}
-if(StreamOperation.REPAIR == getStreamOperation())
-{
-StreamingMetrics.totalOutgoingRepairBytes.inc(totalBytesToStream);
-
StreamingMetrics.totalOutgoingRepairSSTables.inc(totalSSTablesStreamed);
-}
-
messageSender.sendMessage(prepare);
}
@@ -767,6 +757,13 @@ public class StreamSession implements
IEndpointStateChangeSubscriber
long headerSize = message.stream.getEstimatedSize();
StreamingMetrics.totalOutgoingBytes.inc(headerSize);
metrics.outgoingBytes.inc(headerSize);
+
+if(StreamOperation.REPAIR == getStreamOperation())
+{
+StreamingMetrics.totalOutgoingRepairBytes.inc(headerSize);
+
StreamingMetrics.totalOutgoingRepairSSTables.inc(message.stream.getNumFiles());
+}
+
// schedule timeout for receiving ACK
StreamTransferTask task = transfers.get(message.header.tableId);
if (task != null)
diff --git
a/test/distributed/org/apache/cassandra/distributed/test/metrics/StreamingMetricsTest.java
b/test/distributed/org/apache/cassandra/distributed/test/metrics/StreamingMetricsTest.java
index 22449e8..a4e4adc 100644
---
a/test/distributed/org/apache/cassandra/distributed/test/metrics/StreamingMetricsTest.java
+++
b/test/distributed/org/apache/cassandra/distributed/test/metrics/StreamingMetricsTest.java
@@ -18,105 +18,385 @@
package org.apache.cassandra.distributed.test.metrics;
-import java.io.IOException;
import java.net.InetSocketAddress;
-import java.util.concurrent.atomic.AtomicLong;
+import java.util.concurrent.TimeUnit;
-import org.junit.AfterClass;
-import org.junit.BeforeClass;
import org.junit.Test;
import org.apache.cassandra.distributed.Cluster;
+import org.apache.cassandra.distributed.api.ConsistencyLevel;
import org.apache.cassandra.distributed.test.TestBaseImpl;
import org.apache.cassandra.locator.InetAddressAndPort;
import org.apache.cassandra.metrics.StreamingMetrics;
-import static org.apache.cassandra.distributed.api.Feature.NETWORK;
import static org.assertj.core.api.Assertions.assertThat;
+import static org.apache.cassandra.distributed.api.Feature.NETWORK;
public class StreamingMetricsTest extends TestBaseImpl
{
-private static Cluster cluster;
-@BeforeClass
-public static void setupCluster() throws IOException
-{
-cluster = Cluster.build().withNodes(2)
- .withDataDirCount(1)
- .withConfig(config -> config.with(NETWORK)
-
.set("stream_entire_sstables", false))
- .start();
-cluster.schemaChange("CREATE KEYSPACE " + KEYSPACE + " WITH
replication = {'class': 'SimpleStrategy', 'replication_factor':
[jira] [Commented] (CASSANDRA-15561) Extract Javadoc into a separate package
[
https://issues.apache.org/jira/browse/CASSANDRA-15561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318032#comment-17318032
]
Michael Semb Wever commented on CASSANDRA-15561:
bq. Should we add a doc package (deb/rpm) in another ticket?
yeah, this patch doesn't change deb or rpm packages (they do not, nor have
ever, contained docs AFAIK)
> Extract Javadoc into a separate package
> ---
>
> Key: CASSANDRA-15561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15561
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Alex Ott
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Right now, the {{javadoc}} directory occupies 99Mb out of the 149Mb of
> Cassandra 4.0-alpha3 installation. It would be useful to extract Javadocs
> into a separate package for package installations (RPM/DEB), and maybe create
> a separate artifact for tarball (or include them into {{src}}?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15561) Extract Javadoc into a separate package
[
https://issues.apache.org/jira/browse/CASSANDRA-15561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318034#comment-17318034
]
Michael Semb Wever commented on CASSANDRA-15561:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/595/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/595/pipeline]
> Extract Javadoc into a separate package
> ---
>
> Key: CASSANDRA-15561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15561
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Alex Ott
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Right now, the {{javadoc}} directory occupies 99Mb out of the 149Mb of
> Cassandra 4.0-alpha3 installation. It would be useful to extract Javadocs
> into a separate package for package installations (RPM/DEB), and maybe create
> a separate artifact for tarball (or include them into {{src}}?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16583) Dont fork jvms in the build
[
https://issues.apache.org/jira/browse/CASSANDRA-16583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318035#comment-17318035
]
Michael Semb Wever commented on CASSANDRA-16583:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/598/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/598/pipeline]
> Dont fork jvms in the build
> ---
>
> Key: CASSANDRA-16583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16583
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Most developer and build machines have more than 1GB RAM now-a-days. The need
> to fork to specify {{`-Xmx512m`}} is redundant.
> Removing the fork flags removes >25% of the build time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16190) Add tests for streaming metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16190: --- Status: Ready to Commit (was: Review In Progress) > Add tests for streaming metrics > --- > > Key: CASSANDRA-16190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16190 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.0-rc > > > We currently have no tests to checks the streaming metrics -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16190) Add tests for streaming metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16190: --- Fix Version/s: (was: 4.0-rc) 4.0 4.0-rc1 Source Control Link: https://github.com/apache/cassandra/commit/c4e4e9388b229a0db92c16029fd647909cec5737 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed into trunk at c4e4e9388b229a0db92c16029fd647909cec5737 > Add tests for streaming metrics > --- > > Key: CASSANDRA-16190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16190 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.0-rc1, 4.0 > > > We currently have no tests to checks the streaming metrics -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-16582:
--
Assignee: Benjamin Lerer
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-beta
>
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792)
> at
> io.netty.channel.epoll.
[jira] [Commented] (CASSANDRA-16190) Add tests for streaming metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318048#comment-17318048 ] Ekaterina Dimitrova commented on CASSANDRA-16190: - Apologize, I have my GitHub notifications on but it seems I didn't get anything for that commit. I don't know why, I will check my GitHub settings Thank you > Add tests for streaming metrics > --- > > Key: CASSANDRA-16190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16190 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.0-rc1, 4.0 > > > We currently have no tests to checks the streaming metrics -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Don't fork jvms in the build
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 6cc730d Don't fork jvms in the build
6cc730d is described below
commit 6cc730d689a7625554054e558238042bea502c46
Author: Mick Semb Wever
AuthorDate: Fri Apr 9 13:03:36 2021 +0200
Don't fork jvms in the build
On build machines with less than 1GB ram, use ANT_OPTS="-Xmx512m"
patch by Mick Semb Wever; reviewed by Brandon Williams for CASSANDRA-16583
---
build.xml | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/build.xml b/build.xml
index 7550f3a..192abc1 100644
--- a/build.xml
+++ b/build.xml
@@ -398,9 +398,7 @@
Building Grammar ${build.src.antlr}/Cql.g ...
-
@@ -873,10 +871,9 @@
-
+ destdir="${build.classes.main}" includeantruntime="false"
source="${source.version}" target="${target.version}">
@@ -1282,7 +1279,6 @@
[jira] [Updated] (CASSANDRA-16583) Dont fork jvms in the build
[
https://issues.apache.org/jira/browse/CASSANDRA-16583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16583:
---
Status: Ready to Commit (was: Review In Progress)
> Dont fork jvms in the build
> ---
>
> Key: CASSANDRA-16583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16583
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Most developer and build machines have more than 1GB RAM now-a-days. The need
> to fork to specify {{`-Xmx512m`}} is redundant.
> Removing the fork flags removes >25% of the build time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16583) Dont fork jvms in the build
[
https://issues.apache.org/jira/browse/CASSANDRA-16583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16583:
---
Reviewers: Brandon Williams
Status: Review In Progress (was: Patch Available)
> Dont fork jvms in the build
> ---
>
> Key: CASSANDRA-16583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16583
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Most developer and build machines have more than 1GB RAM now-a-days. The need
> to fork to specify {{`-Xmx512m`}} is redundant.
> Removing the fork flags removes >25% of the build time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16583) Dont fork jvms in the build
[
https://issues.apache.org/jira/browse/CASSANDRA-16583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16583:
---
Fix Version/s: (was: 4.0.x)
4.0
4.0-rc1
Source Control Link:
https://github.com/apache/cassandra/commit/6cc730d689a7625554054e558238042bea502c46
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[6cc730d689a7625554054e558238042bea502c46|https://github.com/apache/cassandra/commit/6cc730d689a7625554054e558238042bea502c46].
> Dont fork jvms in the build
> ---
>
> Key: CASSANDRA-16583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16583
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0-rc1, 4.0
>
>
> Most developer and build machines have more than 1GB RAM now-a-days. The need
> to fork to specify {{`-Xmx512m`}} is redundant.
> Removing the fork flags removes >25% of the build time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Don't put apidocs (javadoc) into the binary artifact
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new b80dd92 Don't put apidocs (javadoc) into the binary artifact b80dd92 is described below commit b80dd9225122a3eb7a411d9b7df2e6c1351aa854 Author: Mick Semb Wever AuthorDate: Fri Apr 9 09:17:17 2021 +0200 Don't put apidocs (javadoc) into the binary artifact patch by Mick Semb Wever; reviewed by Brandon Williams for CASSANDRA-15561 --- CHANGES.txt | 1 + build.xml | 9 +++-- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 590a4a4..60c8d33 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0-rc1 + * Binary releases no longer bundle the apidocs (javadoc) (CASSANDRA-15561) * Fix Streaming Repair metrics (CASSANDRA-16190) * Scheduled (delayed) schema pull tasks should not run after MIGRATION stage shutdown during decommission (CASSANDRA-16495) * When behind a firewall trunk is not buildable, need to allow overriding URLs (CASSANDRA-16563) diff --git a/build.xml b/build.xml index 192abc1..b7c4c4e 100644 --- a/build.xml +++ b/build.xml @@ -1055,7 +1055,7 @@ - + @@ -1076,7 +1076,7 @@ - + @@ -1088,9 +1088,6 @@ - - - @@ -1135,7 +1132,7 @@ - - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15561) Extract Javadoc into a separate package
[
https://issues.apache.org/jira/browse/CASSANDRA-15561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15561:
---
Reviewers: Brandon Williams
Status: Review In Progress (was: Patch Available)
> Extract Javadoc into a separate package
> ---
>
> Key: CASSANDRA-15561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15561
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Alex Ott
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Right now, the {{javadoc}} directory occupies 99Mb out of the 149Mb of
> Cassandra 4.0-alpha3 installation. It would be useful to extract Javadocs
> into a separate package for package installations (RPM/DEB), and maybe create
> a separate artifact for tarball (or include them into {{src}}?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15561) Extract Javadoc into a separate package
[
https://issues.apache.org/jira/browse/CASSANDRA-15561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15561:
---
Status: Ready to Commit (was: Review In Progress)
> Extract Javadoc into a separate package
> ---
>
> Key: CASSANDRA-15561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15561
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Alex Ott
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0.x
>
>
> Right now, the {{javadoc}} directory occupies 99Mb out of the 149Mb of
> Cassandra 4.0-alpha3 installation. It would be useful to extract Javadocs
> into a separate package for package installations (RPM/DEB), and maybe create
> a separate artifact for tarball (or include them into {{src}}?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15561) Extract Javadoc into a separate package
[
https://issues.apache.org/jira/browse/CASSANDRA-15561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15561:
---
Fix Version/s: (was: 4.0.x)
4.0
4.0-rc1
Source Control Link:
https://github.com/apache/cassandra/commit/b80dd9225122a3eb7a411d9b7df2e6c1351aa854
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[b80dd9225122a3eb7a411d9b7df2e6c1351aa854|https://github.com/apache/cassandra/commit/b80dd9225122a3eb7a411d9b7df2e6c1351aa854].
> Extract Javadoc into a separate package
> ---
>
> Key: CASSANDRA-15561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15561
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Alex Ott
>Assignee: Michael Semb Wever
>Priority: Low
> Fix For: 4.0-rc1, 4.0
>
>
> Right now, the {{javadoc}} directory occupies 99Mb out of the 149Mb of
> Cassandra 4.0-alpha3 installation. It would be useful to extract Javadocs
> into a separate package for package installations (RPM/DEB), and maybe create
> a separate artifact for tarball (or include them into {{src}}?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318121#comment-17318121
]
Andres de la Peña commented on CASSANDRA-16577:
---
Looks good to me assuming CI looks good, +1.
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318136#comment-17318136
]
Blake Eggleston commented on CASSANDRA-16577:
-
Fix looks good, although it would be good to add a test to
{{MigrationCoordinatorTest}} exercising {{removeVersionInfoForEndpoint}}. I
think you could just add a variant of {{versionsAreSignaledWhenDeleted}}:
{code}
/**
* If an endpoint is removed and no other endpoints are reporting its
* schema version, the version should be removed and, we should signal
* anyone waiting on that version
*/
@Test
public void versionsAreSignaledWhenEndpointsRemoved()
{
InstrumentedCoordinator coordinator = new InstrumentedCoordinator();
coordinator.reportEndpointVersion(EP1, V1);
WaitQueue.Signal signal =
coordinator.getVersionInfoUnsafe(V1).register();
Assert.assertFalse(signal.isSignalled());
coordinator.removeVersionInfoForEndpoint(EP1);
Assert.assertNull(coordinator.getVersionInfoUnsafe(V1));
Assert.assertTrue(signal.isSignalled());
}
{code}
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownH
[jira] [Commented] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318139#comment-17318139
]
Brandon Williams commented on CASSANDRA-16577:
--
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/601/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/601/pipeline]
Nits addressed, Blake's test added. Will commit if this run is good.
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[ https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318159#comment-17318159 ] David Capwell commented on CASSANDRA-16581: --- Spoke with Sam and we need to review a few things first: 1) ProtocolException doesn't distinguish between a simple user error (bad CL), and corrupt message (the test added has frame version v84... which doesn't exist). Reconnects are not free, so this lack of clarity on the exception can be problematic when closing the socket; this problem exists cross 3.x and 4.x lines 2) v5 protocol can have multiple streams on the same frame, and client might not be able to map stream to frame, so a frame level issue (such as checkpointing) can become a problem; this problem is localized to 4.x > Failure to execute queries should emit a KPI other than read > timeout/unavailable so it can be alerted/tracked > - > > Key: CASSANDRA-16581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16581 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-rc > > > When we are unable to parse a message we do not have a way to detect this > from a monitoring point of view so can get into situations where we believe > the database is fine but the clients are on-fire. This case popped up in the > 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317992#comment-17317992
]
Brandon Williams edited comment on CASSANDRA-16577 at 4/9/21, 5:38 PM:
---
Updated [dtest|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-16577]
and [patch|https://github.com/driftx/cassandra/tree/CASSANDRA-16577].
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/599/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/599/pipeline]
was (Author: brandon.williams):
Updated [detst|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-16577]
and [patch|https://github.com/driftx/cassandra/tree/CASSANDRA-16577].
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/599/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/599/pipeline]
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---
[jira] [Assigned] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16582:
-
Assignee: (was: Benjamin Lerer)
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792)
> at
>
[jira] [Assigned] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16582:
-
Assignee: Adam Holmberg
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.
[jira] [Commented] (CASSANDRA-16350) Improve compaction param "provide_overlapping_tombstones" handling
[
https://issues.apache.org/jira/browse/CASSANDRA-16350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318318#comment-17318318
]
Brian Houser commented on CASSANDRA-16350:
--
Approval and paperwork completed on my end.
Having done a bit of a check, the fix version isn't set, but the first of the
branches that I can find
provide_overlapping_tombstones
Is in 3.11, so I will set that version, and setup my PR against that.
> Improve compaction param "provide_overlapping_tombstones" handling
> --
>
> Key: CASSANDRA-16350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16350
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Brian Houser
>Priority: Normal
>
> We currently have no cqlsh autocompletion for
> {{provide_overlapping_tombstones}}. We should also improve the validation for
> the parameter given as it is currently quite unhelpful:
> {code}
> cqlsh:x> create table z (id int primary key, x int) with compaction =
> {'class': 'SizeTieredCompactionStrategy',
> 'provide_overlapping_tombstones':'xyz'};
> NoHostAvailable:
> {code}
> and an exception in the logs;
> {code}
> ERROR [Native-Transport-Requests-1] 2020-12-14 13:25:46,575
> QueryMessage.java:121 - Unexpected error during query
> java.lang.IllegalArgumentException: No enum constant
> org.apache.cassandra.schema.CompactionParams.TombstoneOption.XYZ
> at java.lang.Enum.valueOf(Enum.java:238)
> at
> org.apache.cassandra.schema.CompactionParams$TombstoneOption.valueOf(CompactionParams.java:59)
> at
> org.apache.cassandra.schema.CompactionParams.create(CompactionParams.java:98)
> at
> org.apache.cassandra.schema.CompactionParams.fromMap(CompactionParams.java:255)
> at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:98)
> at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> at
> org.apache.cassandra.cql3.statements.schema.CreateTableStatement.builder(CreateTableStatement.java:145)
> at
> org.apache.cassandra.cql3.statements.schema.CreateTableStatement.apply(CreateTableStatement.java:104)
> at org.apache.cassandra.schema.Schema.transform(Schema.java:587)
> at
> org.apache.cassandra.schema.MigrationManager.lambda$announce$2(MigrationManager.java:221)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16350) Improve compaction param "provide_overlapping_tombstones" handling
[
https://issues.apache.org/jira/browse/CASSANDRA-16350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Houser updated CASSANDRA-16350:
-
Fix Version/s: 3.11.x
> Improve compaction param "provide_overlapping_tombstones" handling
> --
>
> Key: CASSANDRA-16350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16350
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Brian Houser
>Priority: Normal
> Fix For: 3.11.x
>
>
> We currently have no cqlsh autocompletion for
> {{provide_overlapping_tombstones}}. We should also improve the validation for
> the parameter given as it is currently quite unhelpful:
> {code}
> cqlsh:x> create table z (id int primary key, x int) with compaction =
> {'class': 'SizeTieredCompactionStrategy',
> 'provide_overlapping_tombstones':'xyz'};
> NoHostAvailable:
> {code}
> and an exception in the logs;
> {code}
> ERROR [Native-Transport-Requests-1] 2020-12-14 13:25:46,575
> QueryMessage.java:121 - Unexpected error during query
> java.lang.IllegalArgumentException: No enum constant
> org.apache.cassandra.schema.CompactionParams.TombstoneOption.XYZ
> at java.lang.Enum.valueOf(Enum.java:238)
> at
> org.apache.cassandra.schema.CompactionParams$TombstoneOption.valueOf(CompactionParams.java:59)
> at
> org.apache.cassandra.schema.CompactionParams.create(CompactionParams.java:98)
> at
> org.apache.cassandra.schema.CompactionParams.fromMap(CompactionParams.java:255)
> at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:98)
> at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> at
> org.apache.cassandra.cql3.statements.schema.CreateTableStatement.builder(CreateTableStatement.java:145)
> at
> org.apache.cassandra.cql3.statements.schema.CreateTableStatement.apply(CreateTableStatement.java:104)
> at org.apache.cassandra.schema.Schema.transform(Schema.java:587)
> at
> org.apache.cassandra.schema.MigrationManager.lambda$announce$2(MigrationManager.java:221)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16582:
--
Test and Documentation Plan: New jvm upgrade test is added.
Status: Patch Available (was: In Progress)
Benjamin was working on this and had to end the week in the middle of working
through some test issues. I took the branch and updated the test here:
[patch|https://github.com/aholmberg/cassandra/pull/53]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16582]
(started)
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.in
[jira] [Created] (CASSANDRA-16584) Allow sstableloader to specify keyspace/table without relying on path
Brendan Cicchi created CASSANDRA-16584: -- Summary: Allow sstableloader to specify keyspace/table without relying on path Key: CASSANDRA-16584 URL: https://issues.apache.org/jira/browse/CASSANDRA-16584 Project: Cassandra Issue Type: Improvement Components: Legacy/Tools Reporter: Brendan Cicchi This is a followup to CASSANDRA-13884. It would be nice to be able to able to specify both the keyspace and table name for BulkLoader as commandline arguments and not rely on the path to the sstables, i.e. //*.db. It looks like this may have already been completed in the patch in CASSANDRA-4763 which ended up closed because of the overlap with CASSANDRA-13884: https://issues.apache.org/jira/browse/CASSANDRA-4763?focusedCommentId=16133937&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16133937 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16577:
--
Status: Patch Available (was: Open)
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16577:
--
Reviewers: Andres de la Peña, Adam Holmberg (was: Adam Holmberg, Andres de
la Peña)
Andres de la Peña, Adam Holmberg (was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318324#comment-17318324
]
Brandon Williams commented on CASSANDRA-16582:
--
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/602/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/602/pipeline]
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>
[jira] [Updated] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16582:
--
Authors: Adam Holmberg, Benjamin Lerer (was: Adam Holmberg)
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInRea
[jira] [Updated] (CASSANDRA-16584) Allow sstableloader to specify keyspace/table without relying on path
[ https://issues.apache.org/jira/browse/CASSANDRA-16584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16584: - Change Category: Operability Complexity: Low Hanging Fruit Fix Version/s: 4.0.x Status: Open (was: Triage Needed) > Allow sstableloader to specify keyspace/table without relying on path > - > > Key: CASSANDRA-16584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16584 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Brendan Cicchi >Priority: Normal > Fix For: 4.0.x > > > This is a followup to CASSANDRA-13884. It would be nice to be able to able to > specify both the keyspace and table name for BulkLoader as commandline > arguments and not rely on the path to the sstables, i.e. > //*.db. > It looks like this may have already been completed in the patch in > CASSANDRA-4763 which ended up closed because of the overlap with > CASSANDRA-13884: > https://issues.apache.org/jira/browse/CASSANDRA-4763?focusedCommentId=16133937&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16133937 > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch trunk updated: make docker prune calls opportunistic (it is ok to skip if another prune command is running)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/trunk by this push:
new b0df176 make docker prune calls opportunistic (it is ok to skip if
another prune command is running)
b0df176 is described below
commit b0df1768deefe48508e01dd2bba53ea6b38b1ce7
Author: Mick Semb Wever
AuthorDate: Fri Apr 9 23:13:55 2021 +0200
make docker prune calls opportunistic (it is ok to skip if another prune
command is running)
---
build-scripts/cassandra-deb-packaging.sh | 2 +-
build-scripts/cassandra-rpm-packaging.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/build-scripts/cassandra-deb-packaging.sh
b/build-scripts/cassandra-deb-packaging.sh
index c62d6fa..90f1bbd 100755
--- a/build-scripts/cassandra-deb-packaging.sh
+++ b/build-scripts/cassandra-deb-packaging.sh
@@ -30,7 +30,7 @@ command -v docker >/dev/null 2>&1 || { echo >&2 "docker needs
to be installed";
[ -f "${cassandra_builds_dir}/docker/build-debs.sh" ] || { echo >&2
"docker/build-debs.sh must exist"; exit 1; }
# remove any previous older built images
-docker image prune --all --force --filter label=org.cassandra.buildenv=buster
--filter "until=4h"
+docker image prune --all --force --filter label=org.cassandra.buildenv=buster
--filter "until=4h" || true
pushd $cassandra_builds_dir
diff --git a/build-scripts/cassandra-rpm-packaging.sh
b/build-scripts/cassandra-rpm-packaging.sh
index 27499dd..bcfd67b 100755
--- a/build-scripts/cassandra-rpm-packaging.sh
+++ b/build-scripts/cassandra-rpm-packaging.sh
@@ -30,7 +30,7 @@ command -v docker >/dev/null 2>&1 || { echo >&2 "docker needs
to be installed";
[ -f "${cassandra_builds_dir}/docker/build-rpms.sh" ] || { echo >&2
"docker/build-rpms.sh must exist"; exit 1; }
# remove any previous older built images
-docker image prune --all --force --filter label=org.cassandra.buildenv=centos
--filter "until=4h"
+docker image prune --all --force --filter label=org.cassandra.buildenv=centos
--filter "until=4h" || true
pushd $cassandra_builds_dir
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16577) Node waits for schema agreement on removed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318333#comment-17318333
]
Brandon Williams commented on CASSANDRA-16577:
--
Same [patch|https://github.com/driftx/cassandra/tree/CASSANDRA-16577-3.0] but
slightly different location for 3.0/3.11.
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/603/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/603/pipeline]
> Node waits for schema agreement on removed nodes
>
>
> Key: CASSANDRA-16577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16577
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Bootstrap and Decommission
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x, 4.0-beta
>
>
> CASSANDRA-15158 might have introduced a bug where bootstrapping nodes wait
> for schema agreement from nodes that have been removed if token allocation
> for keyspace is enabled.
>
> It is fairly easy to reproduce with the following steps:
> {noformat}
> // Create 3 node cluster
> ccm create test --vnodes -n 3 -s -v 3.11.10
> // Remove two nodes
> ccm node2 decommission
> ccm node3 decommission
> ccm node2 remove
> ccm node3 remove
> // Create keyspace to change the schema. It works if the schema never changes.
> ccm node1 cqlsh -x "CREATE KEYSPACE k WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};"
> // Add allocate parameter
> ccm updateconf 'allocate_tokens_for_keyspace: k'
> // Add node2 again to cluster
> ccm add node2 -i 127.0.0.2 -j 7200 -r 2200
> ccm node2 start{noformat}
>
> This will cause node2 to throw exception on startup:
> {noformat}
> WARN [main] 2021-04-08 14:10:53,272 StorageService.java:941 - There are
> nodes in the cluster with a different schema version than us we did not
> merged schemas from, our version : (a5da47ec-ffe3-3111-b2f3-325f771f1539),
> outstanding versions -> endpoints :
> {8e9ec79e-5ed2-3949-8ac8-794abfee3837=[/127.0.0.3]}
> ERROR [main] 2021-04-08 14:10:53,274 CassandraDaemon.java:803 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:947)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:177)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1073)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,279
> HintsService.java:209 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2021-04-08 14:10:53,280 Gossiper.java:1670
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,280
> MessagingService.java:985 - Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.2] 2021-04-08 14:10:53,281 MessagingService.java:1346
> - MessagingService has terminated the accept() thread
> INFO [StorageServiceShutdownHook] 2021-04-08 14:10:53,416
> HintsService.java:209 - Paused hints dispatch{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16585) Periodic failures in *RepairCoordinator*Test
David Capwell created CASSANDRA-16585:
-
Summary: Periodic failures in *RepairCoordinator*Test
Key: CASSANDRA-16585
URL: https://issues.apache.org/jira/browse/CASSANDRA-16585
Project: Cassandra
Issue Type: Bug
Components: CI, Consistency/Repair, Test/dtest/java
Reporter: David Capwell
Assignee: David Capwell
Periodic failures in *RepairCoordinator*Test cause errors such as
FullRepairCoordinatorNeighbourDownTest#validationParticipentCrashesAndComesBack[DATACENTER_AWARE/true]
{code}
nodetool command [repair, distributed_test_keyspace,
validationparticipentcrashesandcomesback_full_datacenter_aware_true,
--dc-parallel, --full] Error message 'Some repair failed' does not contain any
of [/127.0.0.2:7012 died]
stdout:
[2021-04-07 22:45:24,887] Starting repair command #10
(f129cb60-97f2-11eb-9316-794aa6ab8411), repairing keyspace
distributed_test_keyspace with repair options (parallelism: dc_parallel,
primary range: false, incremental: false, job threads: 1, ColumnFamilies:
[validationparticipentcrashesandcomesback_full_datacenter_aware_true],
dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 2, pull repair:
false, force repair: false, optimise streams: false, ignore unreplicated
keyspaces: false)
[2021-04-07 22:45:32,864] Repair command #10 failed with error Repair session
f1342ba0-97f2-11eb-9316-794aa6ab8411 for range [(-1,9223372036854775805],
(9223372036854775805,-1]] failed with error Endpoint /127.0.0.2:7012 died
[2021-04-07 22:45:32,887] After waiting for poll interval of 1 seconds queried
for parent session status and discovered repair failed.
[2021-04-07 22:45:32,887] Repair command #10 finished with error
[2021-04-07 22:45:32,887] Some repair failed
[2021-04-07 22:45:32,888] Repair command #10 finished with error
stderr:
error: Some repair failed
-- StackTrace --
java.io.IOException: Some repair failed
at
org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:431)
at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
at
org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:358)
at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:343)
at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:246)
at
org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:836)
at
org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$38(Instance.java:746)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
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:834)
Notifications:
Notification{type=START, src=repair:10, message=Starting repair command #10
(f129cb60-97f2-11eb-9316-794aa6ab8411), repairing keyspace
distributed_test_keyspace with repair options (parallelism: dc_parallel,
primary range: false, incremental: false, job threads: 1, ColumnFamilies:
[validationparticipentcrashesandcomesback_full_datacenter_aware_true],
dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 2, pull repair:
false, force repair: false, optimise streams: false, ignore unreplicated
keyspaces: false)}
Notification{type=ERROR, src=repair:10, message=Repair command #10 failed with
error Repair session f1342ba0-97f2-11eb-9316-794aa6ab8411 for range
[(-1,9223372036854775805], (9223372036854775805,-1]] failed with error Endpoint
/127.0.0.2:7012 died}
Notification{type=COMPLETE, src=repair:10, message=Repair command #10 finished
with error}
Error:
java.io.IOException: Some repair failed
at
org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:431)
at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
at
org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:358)
at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:343)
at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:246)
at
org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:836)
at
org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$38(Instance.java:746)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.ru
[jira] [Updated] (CASSANDRA-16585) Periodic failures in *RepairCoordinator*Test
[
https://issues.apache.org/jira/browse/CASSANDRA-16585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16585:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Transient
Incorrect Response(12987)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.0-rc
Severity: Normal
Status: Open (was: Triage Needed)
> Periodic failures in *RepairCoordinator*Test
>
>
> Key: CASSANDRA-16585
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16585
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Consistency/Repair, Test/dtest/java
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Periodic failures in *RepairCoordinator*Test cause errors such as
> FullRepairCoordinatorNeighbourDownTest#validationParticipentCrashesAndComesBack[DATACENTER_AWARE/true]
>
> {code}
> nodetool command [repair, distributed_test_keyspace,
> validationparticipentcrashesandcomesback_full_datacenter_aware_true,
> --dc-parallel, --full] Error message 'Some repair failed' does not contain
> any of [/127.0.0.2:7012 died]
> stdout:
> [2021-04-07 22:45:24,887] Starting repair command #10
> (f129cb60-97f2-11eb-9316-794aa6ab8411), repairing keyspace
> distributed_test_keyspace with repair options (parallelism: dc_parallel,
> primary range: false, incremental: false, job threads: 1, ColumnFamilies:
> [validationparticipentcrashesandcomesback_full_datacenter_aware_true],
> dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 2, pull repair:
> false, force repair: false, optimise streams: false, ignore unreplicated
> keyspaces: false)
> [2021-04-07 22:45:32,864] Repair command #10 failed with error Repair session
> f1342ba0-97f2-11eb-9316-794aa6ab8411 for range [(-1,9223372036854775805],
> (9223372036854775805,-1]] failed with error Endpoint /127.0.0.2:7012 died
> [2021-04-07 22:45:32,887] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-04-07 22:45:32,887] Repair command #10 finished with error
> [2021-04-07 22:45:32,887] Some repair failed
> [2021-04-07 22:45:32,888] Repair command #10 finished with error
> stderr:
> error: Some repair failed
> -- StackTrace --
> java.io.IOException: Some repair failed
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:431)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:358)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:343)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:246)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:836)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$38(Instance.java:746)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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:834)
> Notifications:
> Notification{type=START, src=repair:10, message=Starting repair command #10
> (f129cb60-97f2-11eb-9316-794aa6ab8411), repairing keyspace
> distributed_test_keyspace with repair options (parallelism: dc_parallel,
> primary range: false, incremental: false, job threads: 1, ColumnFamilies:
> [validationparticipentcrashesandcomesback_full_datacenter_aware_true],
> dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 2, pull repair:
> false, force repair: false, optimise streams: false, ignore unreplicated
> keyspaces: false)}
> Notification{type=ERROR, src=repair:10, message=Repair command #10 failed
> with error Repair session f1342ba0-97f2-11eb-9316-794aa6ab8411 for range
> [(-1,9223372036854775805], (9223372036854775805,-1]] failed with error
> Endpoint /127.0.0.2:7012 died}
> Notification{type=COMPLETE, src=repair:10, message=Repair command #10
> finished with error}
> Error:
> java.io.IOException: Some repair failed
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:431)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org
[jira] [Updated] (CASSANDRA-16585) Periodic failures in *RepairCoordinator*Test caused by race condition with nodetool repair
[
https://issues.apache.org/jira/browse/CASSANDRA-16585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16585:
--
Summary: Periodic failures in *RepairCoordinator*Test caused by race
condition with nodetool repair (was: Periodic failures in
*RepairCoordinator*Test)
> Periodic failures in *RepairCoordinator*Test caused by race condition with
> nodetool repair
> --
>
> Key: CASSANDRA-16585
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16585
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Consistency/Repair, Test/dtest/java
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Periodic failures in *RepairCoordinator*Test cause errors such as
> FullRepairCoordinatorNeighbourDownTest#validationParticipentCrashesAndComesBack[DATACENTER_AWARE/true]
>
> {code}
> nodetool command [repair, distributed_test_keyspace,
> validationparticipentcrashesandcomesback_full_datacenter_aware_true,
> --dc-parallel, --full] Error message 'Some repair failed' does not contain
> any of [/127.0.0.2:7012 died]
> stdout:
> [2021-04-07 22:45:24,887] Starting repair command #10
> (f129cb60-97f2-11eb-9316-794aa6ab8411), repairing keyspace
> distributed_test_keyspace with repair options (parallelism: dc_parallel,
> primary range: false, incremental: false, job threads: 1, ColumnFamilies:
> [validationparticipentcrashesandcomesback_full_datacenter_aware_true],
> dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 2, pull repair:
> false, force repair: false, optimise streams: false, ignore unreplicated
> keyspaces: false)
> [2021-04-07 22:45:32,864] Repair command #10 failed with error Repair session
> f1342ba0-97f2-11eb-9316-794aa6ab8411 for range [(-1,9223372036854775805],
> (9223372036854775805,-1]] failed with error Endpoint /127.0.0.2:7012 died
> [2021-04-07 22:45:32,887] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-04-07 22:45:32,887] Repair command #10 finished with error
> [2021-04-07 22:45:32,887] Some repair failed
> [2021-04-07 22:45:32,888] Repair command #10 finished with error
> stderr:
> error: Some repair failed
> -- StackTrace --
> java.io.IOException: Some repair failed
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:431)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:358)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:343)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:246)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:836)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$38(Instance.java:746)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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:834)
> Notifications:
> Notification{type=START, src=repair:10, message=Starting repair command #10
> (f129cb60-97f2-11eb-9316-794aa6ab8411), repairing keyspace
> distributed_test_keyspace with repair options (parallelism: dc_parallel,
> primary range: false, incremental: false, job threads: 1, ColumnFamilies:
> [validationparticipentcrashesandcomesback_full_datacenter_aware_true],
> dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 2, pull repair:
> false, force repair: false, optimise streams: false, ignore unreplicated
> keyspaces: false)}
> Notification{type=ERROR, src=repair:10, message=Repair command #10 failed
> with error Repair session f1342ba0-97f2-11eb-9316-794aa6ab8411 for range
> [(-1,9223372036854775805], (9223372036854775805,-1]] failed with error
> Endpoint /127.0.0.2:7012 died}
> Notification{type=COMPLETE, src=repair:10, message=Repair command #10
> finished with error}
> Error:
> java.io.IOException: Some repair failed
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:431)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apa
[jira] [Updated] (CASSANDRA-16585) Periodic failures in *RepairCoordinator*Test caused by race condition with nodetool repair
[
https://issues.apache.org/jira/browse/CASSANDRA-16585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16585:
--
Test and Documentation Plan: added tests
Status: Patch Available (was: Open)
> Periodic failures in *RepairCoordinator*Test caused by race condition with
> nodetool repair
> --
>
> Key: CASSANDRA-16585
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16585
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Consistency/Repair, Test/dtest/java
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Periodic failures in *RepairCoordinator*Test cause errors such as
> FullRepairCoordinatorNeighbourDownTest#validationParticipentCrashesAndComesBack[DATACENTER_AWARE/true]
>
> {code}
> nodetool command [repair, distributed_test_keyspace,
> validationparticipentcrashesandcomesback_full_datacenter_aware_true,
> --dc-parallel, --full] Error message 'Some repair failed' does not contain
> any of [/127.0.0.2:7012 died]
> stdout:
> [2021-04-07 22:45:24,887] Starting repair command #10
> (f129cb60-97f2-11eb-9316-794aa6ab8411), repairing keyspace
> distributed_test_keyspace with repair options (parallelism: dc_parallel,
> primary range: false, incremental: false, job threads: 1, ColumnFamilies:
> [validationparticipentcrashesandcomesback_full_datacenter_aware_true],
> dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 2, pull repair:
> false, force repair: false, optimise streams: false, ignore unreplicated
> keyspaces: false)
> [2021-04-07 22:45:32,864] Repair command #10 failed with error Repair session
> f1342ba0-97f2-11eb-9316-794aa6ab8411 for range [(-1,9223372036854775805],
> (9223372036854775805,-1]] failed with error Endpoint /127.0.0.2:7012 died
> [2021-04-07 22:45:32,887] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-04-07 22:45:32,887] Repair command #10 finished with error
> [2021-04-07 22:45:32,887] Some repair failed
> [2021-04-07 22:45:32,888] Repair command #10 finished with error
> stderr:
> error: Some repair failed
> -- StackTrace --
> java.io.IOException: Some repair failed
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:431)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:358)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:343)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:246)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:836)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$38(Instance.java:746)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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:834)
> Notifications:
> Notification{type=START, src=repair:10, message=Starting repair command #10
> (f129cb60-97f2-11eb-9316-794aa6ab8411), repairing keyspace
> distributed_test_keyspace with repair options (parallelism: dc_parallel,
> primary range: false, incremental: false, job threads: 1, ColumnFamilies:
> [validationparticipentcrashesandcomesback_full_datacenter_aware_true],
> dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 2, pull repair:
> false, force repair: false, optimise streams: false, ignore unreplicated
> keyspaces: false)}
> Notification{type=ERROR, src=repair:10, message=Repair command #10 failed
> with error Repair session f1342ba0-97f2-11eb-9316-794aa6ab8411 for range
> [(-1,9223372036854775805], (9223372036854775805,-1]] failed with error
> Endpoint /127.0.0.2:7012 died}
> Notification{type=COMPLETE, src=repair:10, message=Repair command #10
> finished with error}
> Error:
> java.io.IOException: Some repair failed
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:431)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.ap
[jira] [Commented] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318401#comment-17318401
]
Adam Holmberg commented on CASSANDRA-16582:
---
Circle ran well with one apparently unrelated timeout failure.
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll
[jira] [Updated] (CASSANDRA-14582) Add a system property to set the cassandra hostId if not yet initialized
[ https://issues.apache.org/jira/browse/CASSANDRA-14582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-14582: Reviewers: Paulo Motta > Add a system property to set the cassandra hostId if not yet initialized > > > Key: CASSANDRA-14582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14582 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: vincent royer >Assignee: Abuli Palagashvili >Priority: Low > Labels: lhf > Time Spent: 1h > Remaining Estimate: 0h > > Add a system property *cassandra.host_id* to set the cassandra hostId if not > yet initialized. > This allow to push the cassandra host ID when provisioning new cassandra > nodes rather than to retreive it after the first start. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318323#comment-17318323
]
Adam Holmberg edited comment on CASSANDRA-16582 at 4/10/21, 1:08 AM:
-
Benjamin was working on this and had to end the week while working through some
test issues. I took his work and updated the test here:
[patch|https://github.com/aholmberg/cassandra/pull/53]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16582]
(started)
was (Author: aholmber):
Benjamin was working on this and had to end the week in the middle of working
through some test issues. I took the branch and updated the test here:
[patch|https://github.com/aholmberg/cassandra/pull/53]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16582]
(started)
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>
[jira] [Comment Edited] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318323#comment-17318323
]
Adam Holmberg edited comment on CASSANDRA-16582 at 4/10/21, 1:09 AM:
-
Benjamin was working on this and had to end the week while working through some
test issues. I built on his work and updated the test here:
[patch|https://github.com/aholmberg/cassandra/pull/53]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16582]
(started)
was (Author: aholmber):
Benjamin was working on this and had to end the week while working through some
test issues. I took his work and updated the test here:
[patch|https://github.com/aholmberg/cassandra/pull/53]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16582]
(started)
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
[jira] [Created] (CASSANDRA-16586) Fix flaky test testAvailabilityV30ToV4 - org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
David Capwell created CASSANDRA-16586:
-
Summary: Fix flaky test testAvailabilityV30ToV4 -
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
Key: CASSANDRA-16586
URL: https://issues.apache.org/jira/browse/CASSANDRA-16586
Project: Cassandra
Issue Type: Bug
Components: CI
Reporter: David Capwell
https://app.circleci.com/pipelines/github/dcapwell/cassandra/881/workflows/8e477260-ac6a-4eab-b4be-cbc048199565/jobs/5269
testAvailabilityV30ToV4 -
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
{code}
junit.framework.AssertionFailedError: Unexpected error in case QUORUM-QUORUM
with not upgraded coordinator and 1 nodes down
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:186)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:53)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
Caused by: java.lang.RuntimeException:
org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
received only 1 responses.
at
org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
at
org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
at
org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
at
org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:120)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:139)
at
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:119)
Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
timed out - received only 1 responses.
at
org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
at
org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
at
org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1831)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1780)
at
org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1718)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1627)
at
org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1162)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:302)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:263)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:115)
at
org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:107)
at
org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:69)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16586) Fix flaky test testAvailabilityV30ToV4 - org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
[
https://issues.apache.org/jira/browse/CASSANDRA-16586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16586:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.0-rc
Severity: Normal
Status: Open (was: Triage Needed)
> Fix flaky test testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> --
>
> Key: CASSANDRA-16586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16586
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/881/workflows/8e477260-ac6a-4eab-b4be-cbc048199565/jobs/5269
> testAvailabilityV30ToV4 -
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test
> {code}
> junit.framework.AssertionFailedError: Unexpected error in case QUORUM-QUORUM
> with not upgraded coordinator and 1 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:127)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:79)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:186)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:81)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:53)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailabilityV30ToV4(MixedModeAvailabilityV30Test.java:39)
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 1 responses.
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
> at
> org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.lambda$test$1(MixedModeAvailabilityTestBase.java:120)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:139)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:119)
> Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation
> timed out - received only 1 responses.
> at
> org.apache.cassandra.service.ReadCallback.awaitResults(ReadCallback.java:136)
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:142)
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1831)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1780)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1718)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1627)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1162)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:302)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:263)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:115)
> at
> org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:107)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:69)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)
> at java.lan
