[cassandra-website] branch asf-staging updated: fix whitespace in blog url
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/asf-staging by this push: new 4daf60a fix whitespace in blog url 4daf60a is described below commit 4daf60a3c1181d4464726309111a7a82cc19e8bf Author: mck AuthorDate: Thu Apr 22 08:59:31 2021 +0200 fix whitespace in blog url --- content/blog/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/index.html b/content/blog/index.html index 6aa904d..b899778 100644 --- a/content/blog/index.html +++ b/content/blog/index.html @@ -188,7 +188,7 @@ Improving Apache Cassandra’s Front Door and BackpressureSeptember 03, 2020Apache Cassandra CommunityAs part of CASSANDRA-15013, we have improved Cassandra’s ability to handle high throughput workloads, while having enough safeguards in place to protect itself from po [...] Cassandra and Kubernetes: SIG Update and SurveyAugust 14, 2020Apache Cassandra CommunityFive operators for Apache Cassandra have been created that have made it easier to run containerized Cassandra on Kubernetes. Recently the major contributors to these operators cam [...] Introducing Apache Cassandra 4.0 Beta: Battle Tested From Day OneJuly 20, 2020Apache Cassandra CommunityThis is the most stable Apache Cassandra in history; you should start using Apache Cassandra 4.0 Beta today in your test and QA environments, head to the downloads [...] - Even Higher Availability with 5x Faster Streaming in Cassandra 4.0April 09, 2019Apache Cassandra CommunityStreaming is a process where nodes of a cluster exchange data in the form of SSTables. Streaming can kick in during many situations such as bootstrap, repair, re [...] + Even Higher Availability with 5x Faster Streaming in Cassandra 4.0April 09, 2019Apache Cassandra CommunityStreaming is a process where nodes of a cluster exchange data in the form of SSTables. Streaming can kick in during many situations such as bootstrap, repair, re [...] Introducing Transient ReplicationDecember 03, 2018Apache Cassandra CommunityTransient Replication is a new experimental feature soon to be available in 4.0. When enabled, it allows for the creation of keyspaces where replication factor can be specified as a number of [...] Audit Logging in Apache Cassandra 4.0October 29, 2018Apache Cassandra CommunityDatabase audit logging is an industry standard tool for enterprises to capture critical data change events including what data changed and who triggered the event. These captured records c [...] Finding Bugs in Cassandra's Internals with Property-based TestingOctober 17, 2018Apache Cassandra CommunityAs of September 1st, the Apache Cassandra community has shifted the focus of Cassandra 4.0 development from new feature work to testing, validation, and hardeni [...] - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated: test
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new a027972 test
a027972 is described below
commit a0279725d3bb4a2750bfd8c081971428917f8a0c
Author: mck
AuthorDate: Thu Apr 22 08:57:05 2021 +0200
test
---
content/index.html | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/content/index.html b/content/index.html
index 13f1c20..3121738 100644
--- a/content/index.html
+++ b/content/index.html
@@ -354,4 +354,5 @@
jQuery('#companies').html(members);
});
-
\ No newline at end of file
+
+
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated: test
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/asf-staging by this push: new 8ac1764 test 8ac1764 is described below commit 8ac1764a9c22ebbb4a247fa46ae0a9e27e7691bf Author: mck AuthorDate: Thu Apr 22 08:55:41 2021 +0200 test --- content/index.htm | 357 ++ 1 file changed, 357 insertions(+) diff --git a/content/index.htm b/content/index.htm new file mode 100644 index 000..13f1c20 --- /dev/null +++ b/content/index.htm @@ -0,0 +1,357 @@ + + + + + + Apache Cassandra | + +https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js";> + + https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400&family=Red+Hat+Display:ital,wght@0,400;0,500;0,700;1,400;1,500&display=swap"; rel="stylesheet"> + https://plausible.cassandra.apache.org/js/plausible.js";> + + + + + Cassandra Basics + Quickstart + Ecosystem + https://cassandra.apache.org/doc/latest/";>Documentation + Community + Case Studies + Resources + Blog + Download + + + + + + + + + + + + + Get Started + + + + + + + + Cassandra Basics + + + + + + + + + + Quickstart + + + + + + + + + + Ecosystem + + + + + + https://cassandra.apache.org/doc/latest/";>Documentation + +
[cassandra-website] branch asf-staging updated (2fcb98d -> 8f69e54)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 2fcb98d remove index.html This update removed existing revisions from the reference, leaving the reference pointing at a previous point in the repository history. * -- * -- N refs/heads/asf-staging (8f69e54) \ O -- O -- O (2fcb98d) Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. No new revisions were added by this update. Summary of changes: content/index.html | 357 + 1 file changed, 357 insertions(+) create mode 100644 content/index.html - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated: remove index.html
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/asf-staging by this push: new 2fcb98d remove index.html 2fcb98d is described below commit 2fcb98de43f034c9a4351e64ec0beae2b7215c16 Author: mck AuthorDate: Thu Apr 22 08:51:08 2021 +0200 remove index.html --- content/index.html | 357 - 1 file changed, 357 deletions(-) diff --git a/content/index.html b/content/index.html deleted file mode 100644 index 13f1c20..000 --- a/content/index.html +++ /dev/null @@ -1,357 +0,0 @@ - - - - - - Apache Cassandra | - -https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js";> - - https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400&family=Red+Hat+Display:ital,wght@0,400;0,500;0,700;1,400;1,500&display=swap"; rel="stylesheet"> - https://plausible.cassandra.apache.org/js/plausible.js";> - - - - - Cassandra Basics - Quickstart - Ecosystem - https://cassandra.apache.org/doc/latest/";>Documentation - Community - Case Studies - Resources - Blog - Download - - - - - - - - - - - - - Get Started - - - - - - - - Cassandra Basics - - - - - - - - - - Quickstart - - - - - - - - - - Ecosystem - - - - - - https://cassandra.apache.org/doc/latest/";>Documentation - -
[cassandra-website] 01/01: Fixes from Joshua Levy
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 8f69e54f2a277417bddf9b17313e902dfd0ea77e Author: mck AuthorDate: Thu Apr 22 08:38:33 2021 +0200 Fixes from Joshua Levy --- content/.htaccess | 22 ++ ...y-with-5x-Faster-Streaming-in-Cassandra-4.html} | 2 +- content/blog/index.html| 2 +- 3 files changed, 24 insertions(+), 2 deletions(-) diff --git a/content/.htaccess b/content/.htaccess new file mode 100644 index 000..c50e90d --- /dev/null +++ b/content/.htaccess @@ -0,0 +1,22 @@ + +RewriteEngine on +Redirect 301 /blog/2021/04/19/cass-world-party-speakers.html /blog/Speakers-Announced-for-April-28-Cassandra-4.0-World-Party.html +Redirect 301 /blog/2021/04/12/cass-changelog_6.html /blog/Apache-Cassandra-Changelog-6-April-2021.html +Redirect 301 /blog/2021/03/25/world_party.html /blog/World-Party.html +Redirect 301 /blog/2021/03/10/join_cassandra_gsoc_2021.html /blog/Join-Cassandra-GSoC-2021.html +Redirect 301 /blog/2021/03/08/cass_changelog_5.html /blog/Apache-Cassandra-Changelog-5-March-2021.html +Redirect 301 /blog/2021/02/11/cass-changelog_4.html /blog/Apache-Cassandra-Changelog-4-February-2021.html +Redirect 301 /blog/2021/01/19/cass-changelog_3.html /blog/Apache-Cassandra-Changelog-3-January-2021.html +Redirect 301 /blog/2020/12/01/cass_changelog_2.html /blog/Apache-Cassandra-Changelog-2-December-2020.html +Redirect 301 /blog/2020/10/28/cass_changelog_1.html /blog/Apache-Cassandra-ChanApache-Cassandra-Changelog-1-October-2020.html +Redirect 301 /blog/2020/09/17/cassandra-usage-report-2020.html /blog/Apache-Cassandra-Usage-Report-2020.html +Redirect 301 /blog/2020/09/03/improving-resiliency.html /blog/Improving-Apache-Cassandras-Front-Door-and-Backpressure.html +Redirect 301 /blog/2020/08/14/cassandra-and-kubernetes-sig-update.html /blog/Cassandra-and-Kubernetes-SIG-Update-and-Survey.html +Redirect 301 /blog/2020/07/20/apache-cassandra-4-0-beta1.html /blog/Introducing-Apache-Cassandra-4-Beta-Battle-Tested-From-Day-One.html +Redirect 301 /blog/2019/04/09/benchmarking_streaming.html /blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4.html +Redirect 301 /blog/2018/12/03/introducing-transient-replication.html /blog/Introducing-Transient-Replication.html +Redirect 301 /blog/2018/10/29/audit_logging_cassandra.html /blog/Audit-Logging-in-Apache-Cassandra-4.html +Redirect 301 /blog/2018/10/17/finding_bugs_with_property_based_testing.html /blog/Finding-Bugs-in-Cassandra's-Internals-with-Property-based-Testing.html +Redirect 301 /blog/2018/08/21/testing_apache_cassandra.html /blog/Testing-Apache-Cassandra-4.html +Redirect 301 /blog/2018/08/07/faster_streaming_in_cassandra.html /blog/Hardware-bound-Zero-Copy-Streaming-in-Apache-Cassandra-4.html + diff --git a/content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4 .html b/content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4.html similarity index 99% rename from content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4 .html rename to content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4.html index 81d6a8c..8718e7c 100644 --- a/content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4 .html +++ b/content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4.html @@ -10,7 +10,7 @@ https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400&family=Red+Hat+Display:ital,wght@0,400;0,500;0,700;1,400;1,500&display=swap"; rel="stylesheet"> - https://plausible.cassandra.apache.org/js/plausible.js";> + diff --git a/content/blog/index.html b/content/blog/index.html index 2091150..6aa904d 100644 --- a/content/blog/index.html +++ b/content/blog/index.html @@ -9,7 +9,7 @@ https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js";> https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400&family=Red+Hat+Display:ital,wght@0,400;0,500;0,700;1,400;1,500&display=swap"; rel="stylesheet"> https://cdnjs.cloudflare.com/ajax/libs/list.js/2.3.0/list.js";> - https://plausible.cassandra.apache.org/js/plausible.js";> + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (d1e830b -> 8f69e54)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard d1e830b small fixes from Joshua Levy new 8f69e54 Fixes from Joshua Levy 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 (d1e830b) \ N -- N -- N refs/heads/asf-staging (8f69e54) 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/index.html | 2 +- content/index.html | 210 ++-- 2 files changed, 151 insertions(+), 61 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated: small fixes from Joshua Levy
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/asf-staging by this push: new d1e830b small fixes from Joshua Levy d1e830b is described below commit d1e830b6234b0cc98306ef587e8d1bb692970571 Author: mck AuthorDate: Thu Apr 22 08:28:52 2021 +0200 small fixes from Joshua Levy --- content/.htaccess | 22 +++ ...y-with-5x-Faster-Streaming-in-Cassandra-4.html} | 2 +- content/index.html | 210 ++--- 3 files changed, 83 insertions(+), 151 deletions(-) diff --git a/content/.htaccess b/content/.htaccess new file mode 100644 index 000..c50e90d --- /dev/null +++ b/content/.htaccess @@ -0,0 +1,22 @@ + +RewriteEngine on +Redirect 301 /blog/2021/04/19/cass-world-party-speakers.html /blog/Speakers-Announced-for-April-28-Cassandra-4.0-World-Party.html +Redirect 301 /blog/2021/04/12/cass-changelog_6.html /blog/Apache-Cassandra-Changelog-6-April-2021.html +Redirect 301 /blog/2021/03/25/world_party.html /blog/World-Party.html +Redirect 301 /blog/2021/03/10/join_cassandra_gsoc_2021.html /blog/Join-Cassandra-GSoC-2021.html +Redirect 301 /blog/2021/03/08/cass_changelog_5.html /blog/Apache-Cassandra-Changelog-5-March-2021.html +Redirect 301 /blog/2021/02/11/cass-changelog_4.html /blog/Apache-Cassandra-Changelog-4-February-2021.html +Redirect 301 /blog/2021/01/19/cass-changelog_3.html /blog/Apache-Cassandra-Changelog-3-January-2021.html +Redirect 301 /blog/2020/12/01/cass_changelog_2.html /blog/Apache-Cassandra-Changelog-2-December-2020.html +Redirect 301 /blog/2020/10/28/cass_changelog_1.html /blog/Apache-Cassandra-ChanApache-Cassandra-Changelog-1-October-2020.html +Redirect 301 /blog/2020/09/17/cassandra-usage-report-2020.html /blog/Apache-Cassandra-Usage-Report-2020.html +Redirect 301 /blog/2020/09/03/improving-resiliency.html /blog/Improving-Apache-Cassandras-Front-Door-and-Backpressure.html +Redirect 301 /blog/2020/08/14/cassandra-and-kubernetes-sig-update.html /blog/Cassandra-and-Kubernetes-SIG-Update-and-Survey.html +Redirect 301 /blog/2020/07/20/apache-cassandra-4-0-beta1.html /blog/Introducing-Apache-Cassandra-4-Beta-Battle-Tested-From-Day-One.html +Redirect 301 /blog/2019/04/09/benchmarking_streaming.html /blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4.html +Redirect 301 /blog/2018/12/03/introducing-transient-replication.html /blog/Introducing-Transient-Replication.html +Redirect 301 /blog/2018/10/29/audit_logging_cassandra.html /blog/Audit-Logging-in-Apache-Cassandra-4.html +Redirect 301 /blog/2018/10/17/finding_bugs_with_property_based_testing.html /blog/Finding-Bugs-in-Cassandra's-Internals-with-Property-based-Testing.html +Redirect 301 /blog/2018/08/21/testing_apache_cassandra.html /blog/Testing-Apache-Cassandra-4.html +Redirect 301 /blog/2018/08/07/faster_streaming_in_cassandra.html /blog/Hardware-bound-Zero-Copy-Streaming-in-Apache-Cassandra-4.html + diff --git a/content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4 .html b/content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4.html similarity index 99% rename from content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4 .html rename to content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4.html index 81d6a8c..8718e7c 100644 --- a/content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4 .html +++ b/content/blog/Even-Higher-Availability-with-5x-Faster-Streaming-in-Cassandra-4.html @@ -10,7 +10,7 @@ https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400&family=Red+Hat+Display:ital,wght@0,400;0,500;0,700;1,400;1,500&display=swap"; rel="stylesheet"> - https://plausible.cassandra.apache.org/js/plausible.js";> + diff --git a/content/index.html b/content/index.html index 13f1c20..6aa904d 100644 --- a/content/index.html +++ b/content/index.html @@ -3,13 +3,14 @@ - Apache Cassandra | - -https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js";> - + Apache Cassandra | Blog + + + https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js";> https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400&family=Red+Hat+Display:ital,wght@0,400;0,500;0,700;1,400;1,500&display=swap"; rel="stylesheet"> - https://plausible.cassandra.apache.org/js/plausible.js";> - + https://cdnjs.cloudflare.com/ajax/libs/
[jira] [Commented] (CASSANDRA-16593) Fix flaky org.apache.cassandra.service.ActiveRepairServiceTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17327128#comment-17327128
]
Berenguer Blasi commented on CASSANDRA-16593:
-
Looks
[indeed|https://ci-cassandra.apache.org/job/Cassandra-trunk/457/testReport/org.apache.cassandra.service/ActiveRepairServiceTest/history/]
that could be it. I say we close and reopen if needed?
> Fix flaky org.apache.cassandra.service.ActiveRepairServiceTest
> --
>
> Key: CASSANDRA-16593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16593
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/612/tests
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<1>
> at
> org.apache.cassandra.service.ActiveRepairServiceTest.testQueueWhenPoolFullStrategy(ActiveRepairServiceTest.java:435)
> Standard Output
> INFO [main] 2021-04-10 17:37:25,869 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-04-10 17:37:25,872 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-04-10 17:37:25,950 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-04-10 17:37:25,968 PlatformDependent0
> ...[truncated 88170 chars]...
> build/test/cassandra/data:62/system/local-7ad54392bcdd35a684174e047860b377/na_txn_flush_6c2ddd10-9a23-11eb-9207-35733cfe3fbb.log
>
> DEBUG [MemtableFlushWriter:1] 2021-04-10 17:37:29,454
> ColumnFamilyStore.java:1197 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data:62/system/local-7ad54392bcdd35a684174e047860b377/na-15-big-Data.db')]
> (1 sstables, 4.943KiB), biggest 4.943KiB, smallest 4.943KiB
> DEBUG [main] 2021-04-10 17:37:29,456 StorageService.java:1617 - NORMAL
> {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-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16601:
Since Version: 3.11.x
Source Control Link:
[3.11|https://github.com/apache/cassandra/commit/4bfe68717d9a419ab6a0b3a681478b39117dee80]
and
[trunk|https://github.com/apache/cassandra/commit/b2e897f6a92b931f6f8595a2c0c8d12b04aaf601]
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {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
[cassandra] 02/02: CASSANDRA-16601 Flaky CassandraIndexTest
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit b2e897f6a92b931f6f8595a2c0c8d12b04aaf601
Author: Bereng
AuthorDate: Wed Apr 14 11:15:25 2021 +0200
CASSANDRA-16601 Flaky CassandraIndexTest
patch by Berenguer Blasi; reviewed by Andrés de la Peña for CASSANDRA-16601
---
.../index/internal/CassandraIndexTest.java | 25 +++---
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git
a/test/unit/org/apache/cassandra/index/internal/CassandraIndexTest.java
b/test/unit/org/apache/cassandra/index/internal/CassandraIndexTest.java
index 687c631..2c46bdb 100644
--- a/test/unit/org/apache/cassandra/index/internal/CassandraIndexTest.java
+++ b/test/unit/org/apache/cassandra/index/internal/CassandraIndexTest.java
@@ -18,6 +18,7 @@
package org.apache.cassandra.index.internal;
+import java.util.concurrent.TimeUnit;
import java.util.stream.Collectors;
import java.util.stream.Stream;
import java.util.stream.StreamSupport;
@@ -42,6 +43,7 @@ import org.apache.cassandra.schema.SchemaConstants;
import org.apache.cassandra.schema.TableMetadata;
import org.apache.cassandra.utils.ByteBufferUtil;
import org.apache.cassandra.utils.FBUtilities;
+import org.awaitility.Awaitility;
import static org.apache.cassandra.Util.throwAssert;
import static org.junit.Assert.assertArrayEquals;
@@ -561,33 +563,32 @@ public class CassandraIndexTest extends CQLTester
String selectBuiltIndexesQuery = String.format("SELECT * FROM
%s.\"%s\"",
SchemaConstants.SYSTEM_KEYSPACE_NAME,
SystemKeyspace.BUILT_INDEXES);
-UntypedResultSet rs = execute(selectBuiltIndexesQuery);
-int initialSize = rs.size();
+
+// Wait for any background index clearing tasks to complete. Warn:
When we used to run tests in parallel there
+// could also be cross test class talk and have other indices pop up
here.
+Awaitility.await()
+ .atMost(1, TimeUnit.MINUTES)
+ .pollDelay(1, TimeUnit.SECONDS)
+ .untilAsserted(() ->
assertRows(execute(selectBuiltIndexesQuery)));
String indexName = "build_remove_test_idx";
String tableName = createTable("CREATE TABLE %s (a int, b int, c int,
PRIMARY KEY (a, b))");
createIndex(String.format("CREATE INDEX %s ON %%s(c)", indexName));
waitForIndex(KEYSPACE, tableName, indexName);
+
// check that there are no other rows in the built indexes table
-rs = execute(selectBuiltIndexesQuery);
-int sizeAfterBuild = rs.size();
-assertRowsIgnoringOrderAndExtra(rs, row(KEYSPACE, indexName, null));
+assertRows(execute(selectBuiltIndexesQuery), row(KEYSPACE, indexName,
null));
// rebuild the index and verify the built status table
getCurrentColumnFamilyStore().rebuildSecondaryIndex(indexName);
waitForIndex(KEYSPACE, tableName, indexName);
// check that there are no other rows in the built indexes table
-rs = execute(selectBuiltIndexesQuery);
-assertEquals(sizeAfterBuild, rs.size());
-assertRowsIgnoringOrderAndExtra(rs, row(KEYSPACE, indexName, null));
+assertRows(execute(selectBuiltIndexesQuery), row(KEYSPACE, indexName,
null));
// check that dropping the index removes it from the built indexes
table
dropIndex("DROP INDEX %s." + indexName);
-rs = execute(selectBuiltIndexesQuery);
-assertEquals(initialSize, rs.size());
-rs.forEach(row ->
assertFalse(row.getString("table_name").equals(KEYSPACE) // table_name is
actually keyspace
- &&
row.getString("index_name").equals(indexName)));
+assertRows(execute(selectBuiltIndexesQuery));
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/02: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. bereng pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d273ecf9f2fc2387330cdc130323520d562e2fed Merge: 6564fe3 4bfe687 Author: Bereng AuthorDate: Thu Apr 22 07:53:06 2021 +0200 Merge branch 'cassandra-3.11' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated: Flaky CassandraIndexTest
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new 4bfe687 Flaky CassandraIndexTest
4bfe687 is described below
commit 4bfe68717d9a419ab6a0b3a681478b39117dee80
Author: Bereng
AuthorDate: Wed Apr 21 08:39:15 2021 +0200
Flaky CassandraIndexTest
patch by Berenguer Blasi; reviewed by Andrés de la Peña for CASSANDRA-16601
---
.../index/internal/CassandraIndexTest.java | 31 +-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git
a/test/unit/org/apache/cassandra/index/internal/CassandraIndexTest.java
b/test/unit/org/apache/cassandra/index/internal/CassandraIndexTest.java
index a5c1f60..4ad93b4 100644
--- a/test/unit/org/apache/cassandra/index/internal/CassandraIndexTest.java
+++ b/test/unit/org/apache/cassandra/index/internal/CassandraIndexTest.java
@@ -18,7 +18,6 @@
package org.apache.cassandra.index.internal;
-import java.nio.ByteBuffer;
import java.util.stream.Collectors;
import java.util.stream.Stream;
import java.util.stream.StreamSupport;
@@ -27,6 +26,7 @@ import com.google.common.base.Joiner;
import com.google.common.collect.*;
import org.junit.Test;
+import org.apache.cassandra.Util;
import org.apache.cassandra.config.CFMetaData;
import org.apache.cassandra.config.ColumnDefinition;
import org.apache.cassandra.config.SchemaConstants;
@@ -570,33 +570,38 @@ public class CassandraIndexTest extends CQLTester
String selectBuiltIndexesQuery = String.format("SELECT * FROM
%s.\"%s\"",
SchemaConstants.SYSTEM_KEYSPACE_NAME,
SystemKeyspace.BUILT_INDEXES);
-UntypedResultSet rs = execute(selectBuiltIndexesQuery);
-int initialSize = rs.size();
+
+// Wait for any background index clearing tasks to complete. Warn:
When we used to run tests in parallel there
+// could also be cross test class talk and have other indices pop up
here.
+Util.spinAssertEquals(0, () -> {
+try
+{
+return execute(selectBuiltIndexesQuery).size();
+}
+catch (Throwable e)
+{
+throw new AssertionError(e);
+}
+}, 60);
String indexName = "build_remove_test_idx";
String tableName = createTable("CREATE TABLE %s (a int, b int, c int,
PRIMARY KEY (a, b))");
createIndex(String.format("CREATE INDEX %s ON %%s(c)", indexName));
waitForIndex(KEYSPACE, tableName, indexName);
+
// check that there are no other rows in the built indexes table
-rs = execute(selectBuiltIndexesQuery);
-int sizeAfterBuild = rs.size();
-assertRowsIgnoringOrderAndExtra(rs, row(KEYSPACE, indexName));
+assertRows(execute(selectBuiltIndexesQuery), row(KEYSPACE, indexName));
// rebuild the index and verify the built status table
getCurrentColumnFamilyStore().rebuildSecondaryIndex(indexName);
waitForIndex(KEYSPACE, tableName, indexName);
// check that there are no other rows in the built indexes table
-rs = execute(selectBuiltIndexesQuery);
-assertEquals(sizeAfterBuild, rs.size());
-assertRowsIgnoringOrderAndExtra(rs, row(KEYSPACE, indexName));
+assertRows(execute(selectBuiltIndexesQuery), row(KEYSPACE, indexName));
// check that dropping the index removes it from the built indexes
table
dropIndex("DROP INDEX %s." + indexName);
-rs = execute(selectBuiltIndexesQuery);
-assertEquals(initialSize, rs.size());
-rs.forEach(row ->
assertFalse(row.getString("table_name").equals(KEYSPACE) // table_name is
actually keyspace
- &&
row.getString("index_name").equals(indexName)));
+assertRows(execute(selectBuiltIndexesQuery));
}
// this is slightly annoying, but we cannot read rows from the methods in
Util as
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (6564fe3 -> b2e897f)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 6564fe3 Merge branch 'cassandra-3.11' into trunk new 4bfe687 Flaky CassandraIndexTest new d273ecf Merge branch 'cassandra-3.11' into trunk new b2e897f CASSANDRA-16601 Flaky CassandraIndexTest The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../index/internal/CassandraIndexTest.java | 25 +++--- 1 file changed, 13 insertions(+), 12 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16625) Add a CircleCI job to run some tests repeatedly
[
https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17327094#comment-17327094
]
Berenguer Blasi commented on CASSANDRA-16625:
-
pytest-repeat comes in very handy and has been working for dtests for me:
{{pytest --count 30 ...}}
My 2cts.
> Add a CircleCI job to run some tests repeatedly
> ---
>
> Key: CASSANDRA-16625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16625
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Priority: Normal
>
> I think it could be useful to have an optional CircleCI job to run some
> specific tests n times. That way, tickets could attach CircleCI runs showing
> that the changes don't make a certain ticket flaky or, conversely, that they
> fix a flaky test. Doing this systematically should mitigate the risk of
> introducing new flaky tests, and I guess it would be more convenient and easy
> to share than running the tests locally or on a private CI system.
> It would also be nice to have something similar in Jenkins, but I'm focusing
> this ticket on CircleCI because it's available also for non-committers, so
> assignees can run their tests before setting the tickets as ready for review.
--
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-16465) Increased Read Latency With Cassandra >= 3.11.7
[ https://issues.apache.org/jira/browse/CASSANDRA-16465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17327082#comment-17327082 ] Cyril Scetbon commented on CASSANDRA-16465: --- Any news on that ticket. [~AhmedElJAMI] confirmed that it doesn't happen with 3.11.7 and [~skandyla] said the same for 3.11.8, so the title is misleading I think > Increased Read Latency With Cassandra >= 3.11.7 > --- > > Key: CASSANDRA-16465 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16465 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ahmed ELJAMI >Priority: Normal > Fix For: 3.11.11 > > > After upgrading Cassandra from 3.11.3 to 3.11.9, Cassandra read latency 99% > increased significantly. Getting back to 3.11.3 immediately fixed the issue. > I have observed "SStable reads" increases after upgrading to 3.11.9. > The same behavior was observed by some other users: > [https://www.mail-archive.com/user@cassandra.apache.org/msg61247.html] > According to Paulo Motta's comment, this behavior may be caused by > https://issues.apache.org/jira/browse/CASSANDRA-15690 which was introduced on > 3.11.7 and removed an optimization that may cause a correctness issue when > there are partition deletions. -- 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-16465) Increased Read Latency With Cassandra >= 3.11.7
[ https://issues.apache.org/jira/browse/CASSANDRA-16465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17327082#comment-17327082 ] Cyril Scetbon edited comment on CASSANDRA-16465 at 4/22/21, 4:03 AM: - Any news on that ticket ? [~AhmedElJAMI] confirmed that it doesn't happen with 3.11.7 and [~skandyla] said the same for 3.11.8, so the title is misleading I think was (Author: cscetbon): Any news on that ticket. [~AhmedElJAMI] confirmed that it doesn't happen with 3.11.7 and [~skandyla] said the same for 3.11.8, so the title is misleading I think > Increased Read Latency With Cassandra >= 3.11.7 > --- > > Key: CASSANDRA-16465 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16465 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ahmed ELJAMI >Priority: Normal > Fix For: 3.11.11 > > > After upgrading Cassandra from 3.11.3 to 3.11.9, Cassandra read latency 99% > increased significantly. Getting back to 3.11.3 immediately fixed the issue. > I have observed "SStable reads" increases after upgrading to 3.11.9. > The same behavior was observed by some other users: > [https://www.mail-archive.com/user@cassandra.apache.org/msg61247.html] > According to Paulo Motta's comment, this behavior may be caused by > https://issues.apache.org/jira/browse/CASSANDRA-15690 which was introduced on > 3.11.7 and removed an optimization that may cause a correctness issue when > there are partition deletions. -- 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-16605) The dependencies in the Cassandra DEB package prevent installation on Ubuntu 20.04+
[
https://issues.apache.org/jira/browse/CASSANDRA-16605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326992#comment-17326992
]
Erick Ramirez commented on CASSANDRA-16605:
---
You're right, Drift. Good pickup! (y)
But if I understood correctly, Michael is requesting a semantic update to the
use of the term {{python}} in the installation prerequisites and explicitly use
{{python3}}. Is that right, Michael?
> The dependencies in the Cassandra DEB package prevent installation on Ubuntu
> 20.04+
> ---
>
> Key: CASSANDRA-16605
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16605
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Michael Kelly
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0-rc1, 4.0
>
>
> The DEB package for Cassandra has a dependency on 'python >= 2.7'.
> In Ubuntu 18.04 there is a package called 'python' which installs python2.7.
> This package has been removed in Ubuntu 20.04 so the dependency cannot be
> satisified.
>
> Proposed solution:
> Change the dependency 'python >= 2.7' to something like 'python2 >= 2.7 OR
> python3 >= 3.6'.
--
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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16588:
-
Fix Version/s: (was: 4.0-rc)
(was: 3.11.x)
4.0-rc2
3.11.11
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/f6d19512c4d79f800371da1e54dfe01cae5d894e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
No related failures, committed.
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.11, 4.0-rc2
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 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)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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 (0fd8f0a -> 6564fe3)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 0fd8f0a Revise the metrics docs new f6d1951 Ignore stale ack in shadow round new 6564fe3 Merge branch 'cassandra-3.11' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 3 + src/java/org/apache/cassandra/gms/Gossiper.java| 15 .../apache/cassandra/service/StorageService.java | 2 +- .../org/apache/cassandra/gms/ShadowRoundTest.java | 97 ++ 4 files changed, 116 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 6564fe39ac556aef6d6c93e47cc955c75be2df26 Merge: 0fd8f0a f6d1951 Author: Brandon Williams AuthorDate: Wed Apr 21 17:27:29 2021 -0500 Merge branch 'cassandra-3.11' into trunk CHANGES.txt| 3 + src/java/org/apache/cassandra/gms/Gossiper.java| 15 .../apache/cassandra/service/StorageService.java | 2 +- .../org/apache/cassandra/gms/ShadowRoundTest.java | 97 ++ 4 files changed, 116 insertions(+), 1 deletion(-) diff --cc CHANGES.txt index c8434f7,443c2bf..49c1ce4 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,69 -1,11 +1,72 @@@ -3.11.11 ++4.0-rc2 ++Merged from 3.11: + * Ignore stale acks received in the shadow round (CASSANDRA-16588) +4.0-rc1 + * Allow for setting buffer max capacity to increase it dynamically as needed (CASSANDRA-16524) + * Harden internode message resource limit accounting against serialization failures (CASSANDRA-16616) + * Add back the source release of python driver in tree to avoid fetching from GitHub APIs (CASSANDRA-16599) + * Fix false unavailable for queries due to cluster topology changes (CASSANDRA-16545) + * Fixed a race condition issue in nodetool repair where we poll for the error before seeing the error notification, leading to a less meaningful message (CASSANDRA-16585) + * Fix mixed cluster GROUP BY queries (CASSANDRA-16582) + * Upgrade jflex to 1.8.2 (CASSANDRA-16576) + * 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) + * Make sure sstables with moved starts are removed correctly in LeveledGenerations (CASSANDRA-16552) + * Fix race between secondary index building and active compactions tracking (CASSANDRA-16554) + * Migrate dependency handling from maven-ant-tasks to resolver-ant-tasks, removing lib/ directory from version control (CASSANDRA-16391) + * Fix 4.0 node sending a repair prepare message to a 3.x node breaking the connection (CASSANDRA-16542) + * Removed synchronized modifier from StreamSession#onChannelClose to prevent deadlocking on flush (CASSANDRA-15892) + * Throw IOE in AbstractType.writeValue if value has wrong fixed length (CASSANDRA-16500) + * Execute background refreshing of auth caches on a dedicated executor (CASSANDRA-15177) + * Update bundled java and python drivers to 3.11.0 and 3.25.0 respectively (CASSANDRA-13951) + * Add io.netty.tryReflectionSetAccessible=true to j11 server options in order to enable netty to use Unsafe direct byte buffer construction (CASSANDRA-16493) + * Make cassandra-stress -node support host:port notation (CASSANDRA-16529) + * Better handle legacy gossip application states during (and after) upgrades (CASSANDRA-16525) + * Mark StreamingMetrics.ActiveOutboundStreams as deprecated (CASSANDRA-11174) + * Increase the cqlsh version number (CASSANDRA-16509) + * Fix the CQL generated for the views.where_clause column when some identifiers require quoting (CASSANDRA-16479) + * Send FAILED_SESSION_MSG on shutdown and on in-progress repairs during startup (CASSANDRA-16425) + * Reinstate removed ApplicationState padding (CASSANDRA-16484) + * Expose data dirs to ColumnFamilyStoreMBean (CASSANDRA-16335) + * Add possibility to copy SSTables in SSTableImporter instead of moving them (CASSANDRA-16407) + * Fix DESCRIBE statement for CUSTOM indices with options (CASSANDRA-16482) + * Fix cassandra-stress JMX connection (CASSANDRA-16473) + * Avoid processing redundant application states on endpoint changes (CASSANDRA-16381) + * Prevent parent repair sessions leak (CASSANDRA-16446) + * Fix timestamp issue in SinglePartitionSliceCommandTest testPartitionD…eletionRowDeletionTie (CASSANDRA-16443) + * Promote protocol V5 out of beta (CASSANDRA-14973) + * Fix incorrect encoding for strings can be UTF8 (CASSANDRA-16429) + * Fix node unable to join when RF > N in multi-DC with added warning (CASSANDRA-16296) + * Add an option to nodetool tablestats to check sstable location correctness (CASSANDRA-16344) + * Unable to ALTER KEYSPACE while decommissioned/assassinated nodes are in gossip (CASSANDRA-16422) + * Metrics backward compatibility restored after CASSANDRA-15066 (CASSANDRA-16083) + * Reduce new reserved keywords introduced since 3.0 (CASSANDRA-16439) + * Improve system tables handling in case of disk failures (CASSANDRA-14793) + * Add access and datacenters to unreserved keywords (CASSANDRA-16398) + * Fix nodetool ring, status output when DNS resolution or port printing are in use (CASSANDRA-16283) + * Upgrade Ja
[cassandra] branch cassandra-3.11 updated: Ignore stale ack in shadow round
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new f6d1951 Ignore stale ack in shadow round
f6d1951 is described below
commit f6d19512c4d79f800371da1e54dfe01cae5d894e
Author: Brandon Williams
AuthorDate: Wed Apr 14 13:49:21 2021 -0500
Ignore stale ack in shadow round
Patch by brandonwilliams, samt, and Matt Fleming, reviewed by samt for
CASSANDRA-16588
---
CHANGES.txt| 1 +
.../org/apache/cassandra/gms/EndpointState.java| 5 ++
src/java/org/apache/cassandra/gms/Gossiper.java| 16 +++-
.../apache/cassandra/service/StorageService.java | 2 +-
.../org/apache/cassandra/gms/ShadowRoundTest.java | 94 ++
5 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index d5ad726..443c2bf 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.11.11
+ * Ignore stale acks received in the shadow round (CASSANDRA-16588)
* Add autocomplete and error messages for provide_overlapping_tombstones
(CASSANDRA-16350)
* Add StorageServiceMBean.getKeyspaceReplicationInfo(keyspaceName)
(CASSANDRA-16447)
* Upgrade jackson-databind to 2.9.10.8 (CASSANDRA-16462)
diff --git a/src/java/org/apache/cassandra/gms/EndpointState.java
b/src/java/org/apache/cassandra/gms/EndpointState.java
index 674b597..b587635 100644
--- a/src/java/org/apache/cassandra/gms/EndpointState.java
+++ b/src/java/org/apache/cassandra/gms/EndpointState.java
@@ -83,6 +83,11 @@ public class EndpointState
return applicationState.get().get(key);
}
+public boolean containsApplicationState(ApplicationState key)
+{
+return applicationState.get().containsKey(key);
+}
+
public Set> states()
{
return applicationState.get().entrySet();
diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java
b/src/java/org/apache/cassandra/gms/Gossiper.java
index 69f7fee..6bc25b6 100644
--- a/src/java/org/apache/cassandra/gms/Gossiper.java
+++ b/src/java/org/apache/cassandra/gms/Gossiper.java
@@ -17,7 +17,6 @@
*/
package org.apache.cassandra.gms;
-import java.lang.management.ManagementFactory;
import java.net.InetAddress;
import java.net.UnknownHostException;
import java.util.*;
@@ -1701,12 +1700,27 @@ public class Gossiper implements
IFailureDetectionEventListener, GossiperMBean
return anyNodeOn30;
}
+public boolean sufficientForStartupSafetyCheck(Map epStateMap)
+{
+// it is possible for a previously queued ack to be sent to us when we
come back up in shadow
+EndpointState localState =
epStateMap.get(FBUtilities.getBroadcastAddress());
+// return false if response doesn't contain state necessary for safety
check
+return localState == null || isDeadState(localState) ||
localState.containsApplicationState(ApplicationState.HOST_ID);
+}
+
protected void maybeFinishShadowRound(InetAddress respondent, boolean
isInShadowRound, Map epStateMap)
{
if (inShadowRound)
{
if (!isInShadowRound)
{
+if (!sufficientForStartupSafetyCheck(epStateMap))
+{
+logger.debug("Not exiting shadow round because received
ACK with insufficient states {} -> {}",
+ FBUtilities.getBroadcastAddress(),
epStateMap.get(FBUtilities.getBroadcastAddress()));
+return;
+}
+
if (!seeds.contains(respondent))
logger.warn("Received an ack from {}, who isn't a seed.
Ensure your seed list includes a live node. Exiting shadow round",
respondent);
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index da3a4a8..89af682 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -616,7 +616,7 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
return localHostId;
}
-private synchronized void checkForEndpointCollision(UUID localHostId,
Set peers) throws ConfigurationException
+public synchronized void checkForEndpointCollision(UUID localHostId,
Set peers) throws ConfigurationException
{
if (Boolean.getBoolean("cassandra.allow_unsafe_join"))
{
diff --git a/test/unit/org/apache/cassandra/gms/ShadowRoundTest.java
b/test/unit/org/apache/cassandra/gms/ShadowRoundTest.java
index bc18813..a7368f4 100644
--- a/test/unit/org/apache/cassandra/gms/ShadowRoundTest.java
+++ b/test/unit/org/apache/cassandra/gms/ShadowRoundTest.java
@@ -19,17 +19,26 @@
package org.apache.cassan
[jira] [Comment Edited] (CASSANDRA-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326907#comment-17326907 ] Yifan Cai edited comment on CASSANDRA-16619 at 4/21/21, 9:41 PM: - ZCS streams a file as-is and w/o loading it into memory, hence fast. To remove a field metadata, a node needs to load the file into memory when receiving from remote. I think it is an expected behavior with ZCS. To distinguish, adding the original hostID in the metadata sounds valid. -- edit -- Talked with [~dcapwell] on slack. In the case of ZCS, the sstable metadata is updated after flushing the bytes. See [here.|https://github.com/apache/cassandra/blob/0fd8f0a52fbd69c47d073373abfe7d2437bbd9ca/src/java/org/apache/cassandra/db/streaming/CassandraEntireSSTableStreamReader.java#L142] Currently, it does not reset the commitLogInterval. But it is possible to just add a step to reset, and avoid updating the sstable format, i.e. add a new field. was (Author: yifanc): ZCS streams a file as-is and w/o loading it into memory, hence fast. To remove a field metadata, a node needs to load the file into memory when receiving from remote. I think it is an expected behavior with ZCS. To distinguish, adding the original hostID in the metadata sounds valid. > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326943#comment-17326943 ] David Capwell commented on CASSANDRA-16619: --- A backup/restore process which bypasses nodetool import and directly dumps the files in the CF directory makes sense to hit this, but if you go through import I would hope we strip out all the metadata which is no longer relevant (which we are trying to do in import as commit log position isn't the only thing we need to deal with). If we special case commit log, what do we do with other things such as repair, ancestry, level, etc? Since the cases which load SStables from external writers are few and well known, I feel it makes the most sense to make sure each strips the metadata the same way. Adding a method to MetadataSerializer such as resetCommitLogPosition and calling it in the places which import files would handle this without requiring a format change (import allows more flexibility in what we strip out, which backup/restore processes can use. So nice to have this method rather than a resetNonLocalMetadata method). > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-website] 02/02: hack in plausible tracking with …
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 eb60b84ab06cabac935c535e6bf32a8cd757c2e5
Author: mck
AuthorDate: Wed Apr 21 23:20:06 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-Changelog-5-March-2021.html | 2 +-
content/blog/Apache-Cassandra-Changelog-6-April-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/Join-Casssandra-GSoC-2021.html | 2 +-
.../blog/Speakers-Announced-for-April-28-Cassandra-4.0-World-Party.html | 2 +-
content/blog/Testing-Apache-Cassandra-4.html| 2 +-
content/blog/World-Party.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 +-
content/world-party/index.html | 2 +-
30 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/content/blog/Apache-Cassandra-Changelog-1-October-2020.html
b/content/blog/Apache-Cassandra-Changelog-1-October-2020.html
index 8aed8d6..57c9fa7 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 1fab895..7dd697f 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 2ecd448..359139b 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 f08b467..895c2b0 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-Changelog-5-March-2021.html
b/content/blog/Apache-Cassandra-Changel
[jira] [Commented] (CASSANDRA-16624) Update CONTRIBUTING.md
[ https://issues.apache.org/jira/browse/CASSANDRA-16624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326931#comment-17326931 ] Mitesh Gupta commented on CASSANDRA-16624: -- Done...thanks:)(y) > Update CONTRIBUTING.md > -- > > Key: CASSANDRA-16624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16624 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Mitesh Gupta >Assignee: Mitesh Gupta >Priority: Normal > Labels: pull-request-available > > It shows 'Page Not Found' when we open the link given in "Running Cassandra > in IDEA guide" because it is moved to another place. -- 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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326916#comment-17326916 ] Jeremiah Jordan edited comment on CASSANDRA-16619 at 4/21/21, 9:10 PM: --- [~dcapwell] this isn't just about ZCS. Any backup/restore process that copied an SSTable around is also affected. If a given node did not create the CommitLogPosition information then it needs to be ignored when loading the sstable. Hence the proposal to store the hostid in the metadata. If the hostid in the sstable doesn't match the hostid of the current node, then you can just ignore that erroneous information. This affects 3.x clusters as well, not just 4.x with ZCS. was (Author: jjordan): [~dcapwell] this isn't just about ZCS. Any backup/restore process that copied an SSTable around is also affected. If a given node did not create the CommitLogPosition information then it needs to be ignored when loading the sstable. > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326916#comment-17326916 ] Jeremiah Jordan commented on CASSANDRA-16619: - [~dcapwell] this isn't just about ZCS. Any backup/restore process that copied an SSTable around is also affected. If a given node did not create the CommitLogPosition information then it needs to be ignored when loading the sstable. > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326911#comment-17326911 ] David Capwell commented on CASSANDRA-16619: --- bq. a node needs to load the file into memory when receiving from remote we would already when we open the file, so can strip this out still > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-16619: -- Test and Documentation Plan: run regression tests Status: Patch Available (was: In Progress) > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-16619: -- Source Control Link: https://github.com/apache/cassandra/pull/976, https://github.com/apache/cassandra/pull/977, https://github.com/apache/cassandra/pull/978 (was: https://github.com/apache/cassandra/pull/976) > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326907#comment-17326907 ] Yifan Cai commented on CASSANDRA-16619: --- ZCS streams a file as-is and w/o loading it into memory, hence fast. To remove a field metadata, a node needs to load the file into memory when receiving from remote. I think it is an expected behavior with ZCS. To distinguish, adding the original hostID in the metadata sounds valid. > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326906#comment-17326906 ] David Capwell commented on CASSANDRA-16619: --- Looking at importer I don't see it cleaning up https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SSTableImporter.java#L365-L380. Ideally we should drop it, and ancestors (also missing) > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326899#comment-17326899 ] David Capwell edited comment on CASSANDRA-16619 at 4/21/21, 8:34 PM: - that sounds like a bug in zero-copy streaming then, ideally we should strip that info out before adding the SSTables was (Author: dcapwell): that sounds like a bug in zero-copy streaming then, ideally we should strip that info out before adding > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326899#comment-17326899 ] David Capwell commented on CASSANDRA-16619: --- that sounds like a bug in zero-copy streaming then, ideally we should strip that info out before adding > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16602) Revise the metrics docs in the website
[ https://issues.apache.org/jira/browse/CASSANDRA-16602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-16602: -- Fix Version/s: (was: 4.0-rc) 4.0-rc1 Since Version: 4.0-alpha1 Source Control Link: https://github.com/apache/cassandra/commit/0fd8f0a52fbd69c47d073373abfe7d2437bbd9ca Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [0fd8f0a|https://github.com/apache/cassandra/commit/0fd8f0a52fbd69c47d073373abfe7d2437bbd9ca] > Revise the metrics docs in the website > -- > > Key: CASSANDRA-16602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16602 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0-rc1 > > Time Spent: 10m > Remaining Estimate: 0h > > While inspecting the metrics code, I realized that the metrics docs (at > https://cassandra.apache.org/doc/latest/operating/metrics.html) has several > errors, e.g. > 1.JMX MBean names have incorrect format. They should be separated with > commas, but the doc has space separated values. Cassandra users referring to > this docs will not get it working. > 2.The MBean name for Keyspace metrics is wrong. In the code, we have > `keyspace=`, instead of `scope=`, which is listed in the > docs page. > 3.There are outdated fields. For instance, the `SyncTime` has been > renamed to `RepairSyncTime` under the TableMetrics. > To avoid frustrating and confusing the users that refer to the metrics page, > the docs need to be revised. -- 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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326894#comment-17326894 ] Jacek Lewandowski commented on CASSANDRA-16619: --- [~dcapwell] - how the streaming is expected to remove this info? I can see that zero copy streaming moves the whole files between the nodes and there is no transformation which removes that information. > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 20m > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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: Revise the metrics docs
This is an automated email from the ASF dual-hosted git repository. ycai pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 0fd8f0a Revise the metrics docs 0fd8f0a is described below commit 0fd8f0a52fbd69c47d073373abfe7d2437bbd9ca Author: Yifan Cai AuthorDate: Wed Apr 14 15:34:34 2021 -0700 Revise the metrics docs patch by Yifan Cai; reviewed by Brandon Williams for CASSANDRA-16602 --- doc/source/operating/metrics.rst | 368 +-- 1 file changed, 239 insertions(+), 129 deletions(-) diff --git a/doc/source/operating/metrics.rst b/doc/source/operating/metrics.rst index 83661a2..e3af955 100644 --- a/doc/source/operating/metrics.rst +++ b/doc/source/operating/metrics.rst @@ -72,7 +72,7 @@ Reported name format: ``org.apache.cassandra.metrics.Table...`` **JMX MBean** -``org.apache.cassandra.metrics:type=Table keyspace= scope= name=`` + ``org.apache.cassandra.metrics:type=Table,keyspace=,scope=,name=`` .. NOTE:: There is a special table called '``all``' without a keyspace. This represents the aggregation of metrics across @@ -82,83 +82,92 @@ Reported name format: === == === NameType Description === == === -MemtableOnHeapSize GaugeTotal amount of data stored in the memtable that resides **on**-heap, including column related overhead and partitions overwritten. -MemtableOffHeapSize GaugeTotal amount of data stored in the memtable that resides **off**-heap, including column related overhead and partitions overwritten. -MemtableLiveDataSizeGaugeTotal amount of live data stored in the memtable, excluding any data structure overhead. -AllMemtablesOnHeapSize GaugeTotal amount of data stored in the memtables (2i and pending flush memtables included) that resides **on**-heap. -AllMemtablesOffHeapSize GaugeTotal amount of data stored in the memtables (2i and pending flush memtables included) that resides **off**-heap. +AdditionalWritesCounterTotal number of additional writes sent to the replicas (other than the intial contacted ones). AllMemtablesLiveDataSizeGaugeTotal amount of live data stored in the memtables (2i and pending flush memtables included) that resides off-heap, excluding any data structure overhead. -MemtableColumnsCountGaugeTotal number of columns present in the memtable. -MemtableSwitchCount CounterNumber of times flush has resulted in the memtable being switched out. -CompressionRatioGauge Current compression ratio for all SSTables. -EstimatedPartitionSizeHistogram Gauge Histogram of estimated partition size (in bytes). -EstimatedPartitionCount GaugeApproximate number of keys in table. -EstimatedColumnCountHistogram Gauge Histogram of estimated number of columns. -SSTablesPerReadHistogramHistogram Histogram of the number of sstable data files accessed per single partition read. SSTables skipped due to Bloom Filters, min-max key or partition index lookup are not taken into acoount. -ReadLatency LatencyLocal read latency for this table. -RangeLatencyLatencyLocal range scan latency for this table. -WriteLatencyLatencyLocal write latency for this table. -CoordinatorReadLatency Timer Coordinator read latency for this table. -CoordinatorWriteLatency Timer Coordinator write latency for this table. -CoordinatorScanLatency Timer Coordinator range scan latency for this table. -PendingFlushes CounterEstimated number of flush tasks pending for this table. -BytesFlushedCounterTotal number of bytes flushed since server [re]start. -CompactionBytesWritten CounterTotal number of bytes written by compaction since server [re]start. -PendingCompactions Gauge Estimate of number of pending compactions for this table. -LiveSSTableCountGauge Number of SSTables on disk for this table. -LiveDiskSpaceUsed CounterDisk space used by SSTables belonging to this table (in
[jira] [Commented] (CASSANDRA-16602) Revise the metrics docs in the website
[ https://issues.apache.org/jira/browse/CASSANDRA-16602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326892#comment-17326892 ] Brandon Williams commented on CASSANDRA-16602: -- +1 > Revise the metrics docs in the website > -- > > Key: CASSANDRA-16602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16602 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > While inspecting the metrics code, I realized that the metrics docs (at > https://cassandra.apache.org/doc/latest/operating/metrics.html) has several > errors, e.g. > 1.JMX MBean names have incorrect format. They should be separated with > commas, but the doc has space separated values. Cassandra users referring to > this docs will not get it working. > 2.The MBean name for Keyspace metrics is wrong. In the code, we have > `keyspace=`, instead of `scope=`, which is listed in the > docs page. > 3.There are outdated fields. For instance, the `SyncTime` has been > renamed to `RepairSyncTime` under the TableMetrics. > To avoid frustrating and confusing the users that refer to the metrics page, > the docs need to be revised. -- 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-16602) Revise the metrics docs in the website
[ https://issues.apache.org/jira/browse/CASSANDRA-16602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16602: Reviewers: Brandon Williams (was: Brandon Williams, Ekaterina Dimitrova) > Revise the metrics docs in the website > -- > > Key: CASSANDRA-16602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16602 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > While inspecting the metrics code, I realized that the metrics docs (at > https://cassandra.apache.org/doc/latest/operating/metrics.html) has several > errors, e.g. > 1.JMX MBean names have incorrect format. They should be separated with > commas, but the doc has space separated values. Cassandra users referring to > this docs will not get it working. > 2.The MBean name for Keyspace metrics is wrong. In the code, we have > `keyspace=`, instead of `scope=`, which is listed in the > docs page. > 3.There are outdated fields. For instance, the `SyncTime` has been > renamed to `RepairSyncTime` under the TableMetrics. > To avoid frustrating and confusing the users that refer to the metrics page, > the docs need to be revised. -- 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-16602) Revise the metrics docs in the website
[ https://issues.apache.org/jira/browse/CASSANDRA-16602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16602: Status: Ready to Commit (was: Review In Progress) > Revise the metrics docs in the website > -- > > Key: CASSANDRA-16602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16602 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > While inspecting the metrics code, I realized that the metrics docs (at > https://cassandra.apache.org/doc/latest/operating/metrics.html) has several > errors, e.g. > 1.JMX MBean names have incorrect format. They should be separated with > commas, but the doc has space separated values. Cassandra users referring to > this docs will not get it working. > 2.The MBean name for Keyspace metrics is wrong. In the code, we have > `keyspace=`, instead of `scope=`, which is listed in the > docs page. > 3.There are outdated fields. For instance, the `SyncTime` has been > renamed to `RepairSyncTime` under the TableMetrics. > To avoid frustrating and confusing the users that refer to the metrics page, > the docs need to be revised. -- 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-16602) Revise the metrics docs in the website
[ https://issues.apache.org/jira/browse/CASSANDRA-16602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326890#comment-17326890 ] Ekaterina Dimitrova commented on CASSANDRA-16602: - OMG I didn't see I am still assigned reviewer and I was even wondering why this one is still not closed as there are two committers involved already. :( Feel free to commit it, we definitely trust [~brandon.williams] and you on this one, apologize! > Revise the metrics docs in the website > -- > > Key: CASSANDRA-16602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16602 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > While inspecting the metrics code, I realized that the metrics docs (at > https://cassandra.apache.org/doc/latest/operating/metrics.html) has several > errors, e.g. > 1.JMX MBean names have incorrect format. They should be separated with > commas, but the doc has space separated values. Cassandra users referring to > this docs will not get it working. > 2.The MBean name for Keyspace metrics is wrong. In the code, we have > `keyspace=`, instead of `scope=`, which is listed in the > docs page. > 3.There are outdated fields. For instance, the `SyncTime` has been > renamed to `RepairSyncTime` under the TableMetrics. > To avoid frustrating and confusing the users that refer to the metrics page, > the docs need to be revised. -- 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-16602) Revise the metrics docs in the website
[ https://issues.apache.org/jira/browse/CASSANDRA-16602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326885#comment-17326885 ] Yifan Cai commented on CASSANDRA-16602: --- Hi [~e.dimitrova], just to check if you are still going to review the doc changes. No hurry as it is not blocking anything. > Revise the metrics docs in the website > -- > > Key: CASSANDRA-16602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16602 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > While inspecting the metrics code, I realized that the metrics docs (at > https://cassandra.apache.org/doc/latest/operating/metrics.html) has several > errors, e.g. > 1.JMX MBean names have incorrect format. They should be separated with > commas, but the doc has space separated values. Cassandra users referring to > this docs will not get it working. > 2.The MBean name for Keyspace metrics is wrong. In the code, we have > `keyspace=`, instead of `scope=`, which is listed in the > docs page. > 3.There are outdated fields. For instance, the `SyncTime` has been > renamed to `RepairSyncTime` under the TableMetrics. > To avoid frustrating and confusing the users that refer to the metrics page, > the docs need to be revised. -- 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 (27cc2fc -> 3282f5e)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 27cc2fc Allow for setting buffer max capacity to increase it dynamically as needed add 3282f5e Prepare debian changelog for 4.0-rc1 No new revisions were added by this update. Summary of changes: debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15669) LeveledCompactionStrategy compact last level throw an ArrayIndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/CASSANDRA-15669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-15669: -- Reviewers: Marcus Eriksson, Yifan Cai (was: Marcus Eriksson) > LeveledCompactionStrategy compact last level throw an > ArrayIndexOutOfBoundsException > > > Key: CASSANDRA-15669 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15669 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: sunhaihong >Assignee: Alexey Zotov >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: cfs_compaction_info.png, error_info.png > > Time Spent: 1h > Remaining Estimate: 0h > > Cassandra will throw an ArrayIndexOutOfBoundsException when compact last > level. > My test is as follows： > # Create a table with LeveledCompactionStrategy and its params are > 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', > 'min_threshold': '4', 'sstable_size_in_mb': '2'（fanout_size and > sstable_size_in_mb are too small just to make it easier to reproduce the > problem）; > # Insert data into the table by stress; > # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 > sstables(this level score bigger than 1.001) > ERROR [CompactionExecutor:4] 2020-03-28 08:59:00,990 CassandraDaemon.java:442 > - Exception in thread Thread[CompactionExecutor:4,1,main] > java.lang.ArrayIndexOutOfBoundsException: 9 > at > org.apache.cassandra.db.compaction.LeveledManifest.getLevel(LeveledManifest.java:814) > at > org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:746) > at > org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:398) > at > org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:131) > at > org.apache.cassandra.db.compaction.CompactionStrategyHolder.lambda$getBackgroundTaskSuppliers$0(CompactionStrategyHolder.java:109) > at > org.apache.cassandra.db.compaction.AbstractStrategyHolder$TaskSupplier.getTask(AbstractStrategyHolder.java:66) > at > org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:214) > at > org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:289) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) > at java.util.concurrent.FutureTask.run(FutureTask.java) > 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) > I tested it on cassandra version 3.11.3 & 4.0-alpha3. The exception all > happened. > once it triggers, level1- leveln compaction no longer works, level0 is still > valid > -- 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
svn commit: r47317 - in /dev/cassandra/4.0-rc1/redhat: ./ repodata/
Author: mck Date: Wed Apr 21 18:12:02 2021 New Revision: 47317 Log: staging cassandra rpm packages for 4.0-rc1 Added: dev/cassandra/4.0-rc1/redhat/ dev/cassandra/4.0-rc1/redhat/cassandra-4.0~rc1-1.noarch.rpm (with props) dev/cassandra/4.0-rc1/redhat/cassandra-4.0~rc1-1.src.rpm (with props) dev/cassandra/4.0-rc1/redhat/cassandra-tools-4.0~rc1-1.noarch.rpm (with props) dev/cassandra/4.0-rc1/redhat/repodata/ dev/cassandra/4.0-rc1/redhat/repodata/128cb7d375f5026144ad961493bc5ef45a3f4642ba6f1eab82ae83c94271f69a-primary.xml.gz (with props) dev/cassandra/4.0-rc1/redhat/repodata/128cb7d375f5026144ad961493bc5ef45a3f4642ba6f1eab82ae83c94271f69a-primary.xml.gz.asc dev/cassandra/4.0-rc1/redhat/repodata/3ab116860a88525063f761fc7a5ef2a82e640c186a1ff752c3e85d39e5d837a2-primary.sqlite.bz2 (with props) dev/cassandra/4.0-rc1/redhat/repodata/3ab116860a88525063f761fc7a5ef2a82e640c186a1ff752c3e85d39e5d837a2-primary.sqlite.bz2.asc dev/cassandra/4.0-rc1/redhat/repodata/8297fed42b3e9f6e766e51190d5781b4ca25f6afdf4003b4cc88818d052346a4-filelists.xml.gz (with props) dev/cassandra/4.0-rc1/redhat/repodata/8297fed42b3e9f6e766e51190d5781b4ca25f6afdf4003b4cc88818d052346a4-filelists.xml.gz.asc dev/cassandra/4.0-rc1/redhat/repodata/b48e1cf4cf988f9322b4b1184b8cc5a1f98b6f5c1f4e47451fce60c23f60379f-other.xml.gz (with props) dev/cassandra/4.0-rc1/redhat/repodata/b48e1cf4cf988f9322b4b1184b8cc5a1f98b6f5c1f4e47451fce60c23f60379f-other.xml.gz.asc dev/cassandra/4.0-rc1/redhat/repodata/f5b86f81fe0d13baa58e52492e977910e64f05648455a222139c0e48136812a6-filelists.sqlite.bz2 (with props) dev/cassandra/4.0-rc1/redhat/repodata/f5b86f81fe0d13baa58e52492e977910e64f05648455a222139c0e48136812a6-filelists.sqlite.bz2.asc dev/cassandra/4.0-rc1/redhat/repodata/ff31cb83a6350e84e27a24bf6f35ca256b8e1289ac8e31c78e879c7ba68c5d7c-other.sqlite.bz2 (with props) dev/cassandra/4.0-rc1/redhat/repodata/ff31cb83a6350e84e27a24bf6f35ca256b8e1289ac8e31c78e879c7ba68c5d7c-other.sqlite.bz2.asc dev/cassandra/4.0-rc1/redhat/repodata/repomd.xml dev/cassandra/4.0-rc1/redhat/repodata/repomd.xml.asc Added: dev/cassandra/4.0-rc1/redhat/cassandra-4.0~rc1-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0-rc1/redhat/cassandra-4.0~rc1-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-rc1/redhat/cassandra-4.0~rc1-1.src.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0-rc1/redhat/cassandra-4.0~rc1-1.src.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-rc1/redhat/cassandra-tools-4.0~rc1-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0-rc1/redhat/cassandra-tools-4.0~rc1-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-rc1/redhat/repodata/128cb7d375f5026144ad961493bc5ef45a3f4642ba6f1eab82ae83c94271f69a-primary.xml.gz == Binary file - no diff available. Propchange: dev/cassandra/4.0-rc1/redhat/repodata/128cb7d375f5026144ad961493bc5ef45a3f4642ba6f1eab82ae83c94271f69a-primary.xml.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-rc1/redhat/repodata/128cb7d375f5026144ad961493bc5ef45a3f4642ba6f1eab82ae83c94271f69a-primary.xml.gz.asc == --- dev/cassandra/4.0-rc1/redhat/repodata/128cb7d375f5026144ad961493bc5ef45a3f4642ba6f1eab82ae83c94271f69a-primary.xml.gz.asc (added) +++ dev/cassandra/4.0-rc1/redhat/repodata/128cb7d375f5026144ad961493bc5ef45a3f4642ba6f1eab82ae83c94271f69a-primary.xml.gz.asc Wed Apr 21 18:12:02 2021 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmCAat8ACgkQ6RM1134+ +h8s5Tw//TpOfS3Hmc7ujh3geDBX3aFFM2SEjRTBgv5+KnWrQ0fYpABQhL02A0xOL +9YBYEQKCNFOONzkImT4yei3S06wcB2ge/IIfQGg7sdSFHo0cJ6YJwLK3dbwEoJZy +yrapcsnqr3hrS/IYD7+i457LkF3Wf1I6pt86QSzmL5V9BnH/QMTE3BM4b4XdsCn8 +Ags876O8HY6qSE+vxjL2sykZBbDHH1NlBOC3jbelPzHJr2owe5zO6sd4LrBOiG1O +I+iAeeCoq9jNs2XditBs3XnNj0+w2+NX7hxFPSsAMQv92Rxg/GqkmOE8bh+z0End +YS3gUBQvRrTFhAkCGidgqUvONIKKhXLKME0EEN72T+WgFk+Rx9A2o7pGaSVd7elx +rOR/6Efjgl+XnJEXpuDmOYq7hAiyYiNxKVjjyx4oDHyKjJzpI9aWmPq8oBbK7gMT +oge084d3vby4KSg3AXUjH7t0NWEEXuVqgMX1JktS49CTmHHZdEc5qWwt5BZZ3ocf +9qOqla4n8eHDpHxH/1VYwQ80qjq6FPbz9rqe3t4g6x6WXmfBQklbqpQ
svn commit: r47315 - in /dev/cassandra/4.0-rc1/debian: ./ dists/ dists/40x/ dists/40x/main/ dists/40x/main/binary-amd64/ dists/40x/main/binary-arm64/ dists/40x/main/binary-i386/ dists/40x/main/source/
Author: mck Date: Wed Apr 21 18:01:05 2021 New Revision: 47315 Log: staging cassandra debian packages for 4.0-rc1 Added: dev/cassandra/4.0-rc1/debian/ dev/cassandra/4.0-rc1/debian/cassandra-tools_4.0~rc1_all.deb (with props) dev/cassandra/4.0-rc1/debian/cassandra_4.0~rc1.dsc dev/cassandra/4.0-rc1/debian/cassandra_4.0~rc1.tar.gz (with props) dev/cassandra/4.0-rc1/debian/cassandra_4.0~rc1_all.deb (with props) dev/cassandra/4.0-rc1/debian/cassandra_4.0~rc1_amd64.buildinfo dev/cassandra/4.0-rc1/debian/cassandra_4.0~rc1_amd64.changes dev/cassandra/4.0-rc1/debian/dists/ dev/cassandra/4.0-rc1/debian/dists/40x/ dev/cassandra/4.0-rc1/debian/dists/40x/InRelease dev/cassandra/4.0-rc1/debian/dists/40x/Release dev/cassandra/4.0-rc1/debian/dists/40x/Release.gpg dev/cassandra/4.0-rc1/debian/dists/40x/main/ dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-amd64/ dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-amd64/Packages dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-amd64/Packages.gz (with props) dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-amd64/Release dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-arm64/ dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-arm64/Packages dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-arm64/Packages.gz (with props) dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-arm64/Release dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-i386/ dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-i386/Packages dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-i386/Packages.gz (with props) dev/cassandra/4.0-rc1/debian/dists/40x/main/binary-i386/Release dev/cassandra/4.0-rc1/debian/dists/40x/main/source/ dev/cassandra/4.0-rc1/debian/dists/40x/main/source/Release dev/cassandra/4.0-rc1/debian/dists/40x/main/source/Sources.gz (with props) dev/cassandra/4.0-rc1/debian/pool/ dev/cassandra/4.0-rc1/debian/pool/main/ dev/cassandra/4.0-rc1/debian/pool/main/c/ dev/cassandra/4.0-rc1/debian/pool/main/c/cassandra/ dev/cassandra/4.0-rc1/debian/pool/main/c/cassandra/cassandra-tools_4.0~rc1_all.deb (with props) dev/cassandra/4.0-rc1/debian/pool/main/c/cassandra/cassandra_4.0~rc1.dsc dev/cassandra/4.0-rc1/debian/pool/main/c/cassandra/cassandra_4.0~rc1.tar.gz (with props) dev/cassandra/4.0-rc1/debian/pool/main/c/cassandra/cassandra_4.0~rc1_all.deb (with props) Added: dev/cassandra/4.0-rc1/debian/cassandra-tools_4.0~rc1_all.deb == Binary file - no diff available. Propchange: dev/cassandra/4.0-rc1/debian/cassandra-tools_4.0~rc1_all.deb -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-rc1/debian/cassandra_4.0~rc1.dsc == --- dev/cassandra/4.0-rc1/debian/cassandra_4.0~rc1.dsc (added) +++ dev/cassandra/4.0-rc1/debian/cassandra_4.0~rc1.dsc Wed Apr 21 18:01:05 2021 @@ -0,0 +1,41 @@ +-BEGIN PGP SIGNED MESSAGE- +Hash: SHA512 + +Format: 1.0 +Source: cassandra +Binary: cassandra, cassandra-tools +Architecture: all +Version: 4.0~rc1 +Maintainer: Eric Evans +Uploaders: Sylvain Lebresne +Homepage: http://cassandra.apache.org +Standards-Version: 3.8.3 +Vcs-Browser: https://gitbox.apache.org/repos/asf?p=cassandra.git +Vcs-Git: https://gitbox.apache.org/repos/asf/cassandra.git +Build-Depends: debhelper (>= 11), openjdk-8-jdk | java8-jdk, ant (>= 1.9), ant-optional (>= 1.9), dh-python, python3-dev (>= 3.6), quilt, bash-completion +Package-List: + cassandra deb misc extra arch=all + cassandra-tools deb misc extra arch=all +Checksums-Sha1: + fc5c7b398a4320b48e199ca840d7db13b4b5dd07 234654376 cassandra_4.0~rc1.tar.gz +Checksums-Sha256: + 69a90e1327384aef98ebde6880a4f8c692a2d0a3ea3559e3833fb7c5a72784f1 234654376 cassandra_4.0~rc1.tar.gz +Files: + 04797c2da8d412925ba0237b9b316f85 234654376 cassandra_4.0~rc1.tar.gz + +-BEGIN PGP SIGNATURE- + +iQIzBAEBCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmCAZ9cACgkQ6RM1134+ +h8vLLg/9G2TiAtKp1KdYeX1F4+fKIUzesXM0YfmoB/LhwfQx4wej/sMiWN9e8M2G +QT9JKy9nVfUpRcfysfBMBusCEddellUuDnE4W+ndNKx44fwf12PgFm/bDZwktvXQ +Dd5ME8mSQ33rgexUck3NAcIXWyf8z8//9w/W3mcOR5r7OIps7mOkACaJG7OQjyDB +ODusdMydUcLcgozKApgjzCvp0Rras3NysXfxWZepV1IkfZz8pp8LRhHOAQNZOviC +ZtpTVqsYcWbxTz5Vq7D6DASVsET/QatAU2EFpjuVZFqcMq7N0NTooll7dBhhr8vC +jCiS5pef+Kgr+WWxQVjJB9WaIWXbL3VvqxWvjXfrNQNpgvCxUnz8dvGHHNpSfsfH +v29VJlRIMPTJoKAo7t6M7W1aBfQvsJ50+/ZgDNqHqiw4AomAFnGxqJB75fUewv9M +/shVkeAGYGpXRCR6/paGb5+4boChpWIgMws9lGzo80W+QZLZSRxHufe7O8BD+Ugh ++ciCwek73Fpqz0TWiEtvcHUwKJNPWMIRLTznZvtA/JsuH/Ng0QA7Cy6V6vciwIOs +4N6oSTf2Hyt2QCHozK9QWeBnBNp0RygcUUOlYacOF7DNzdHOBhd66eMYFSURs2Uu +TTDZ0JLi8IaW5HnE7skInmjkn3SV3IL0nK+08H8UCk3JTCLP3jo= +=FFTm +-END PGP SIGNATURE- Added: dev/cassandra/4.0-rc1/debia
svn commit: r47314 - /dev/cassandra/4.0-rc1/
Author: mck Date: Wed Apr 21 17:46:11 2021 New Revision: 47314 Log: staging cassandra 4.0-rc1 Added: dev/cassandra/4.0-rc1/ dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz (with props) dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.asc dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.sha256 dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.sha512 dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz (with props) dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz.asc dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz.sha256 dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz.sha512 Added: dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.asc == --- dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.asc (added) +++ dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.asc Wed Apr 21 17:46:11 2021 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmCAYuAACgkQ6RM1134+ +h8uH0g/+Lr3ozFZwBH4xBmM2NwxwuoXee8GdqZ9KX4p5CAnIrNjrCNgZogthbk6b +Pn0y9yGkegkPm4M0Pp4AaA85rJWiOtj2j9u4Tpsim0vw/+5i6UanXTDKQvVeXyLt +GI635DA81GH7y9EMvAhPme/fKckwmbHz4yOZFK4K2SbXf0YDYTGpIKKmof4HJkxt +oHicOe1TnjFAsolfaousuulcC5wZZH+S/PsfqpO29gEQp5+9z+2OmUKynEVzumIV +B1nCrNmL+Fh4j16Xmh2hlHOIgplkr/BnRo7CLbC1axsl2WV0d2Nz+CwQfB+5peWU +Resf0AR9uXGbaz3GnExQNErRLAwgsgSwgscBbUSSub2326sLqzHiy+W1QjzMWnF3 +c1kaSY74bJEC+dQXiqJN6KgNFMlYMDAet9oY7tNlBKhXlJcjFHty6mLOTVXDDhQg +SQ0RAZ14DGTgXh/DrR2Ffc2hj3myZonv5x4GSjt4Oj6IOP84JBu3+AjCscVsfUx1 +1Y95L5KHFuu08ibSFQRhr+d3jS/kTv5xLz+rDuv/GrbTCL3HvtQDvMoCIxsXGI6s +WVsUrg4isULRprx6YsVD96TuhwQ3/MXIqPV1pYAAVhqUVfLbb7nu7nZAb3HsGGfK +NmALkDfgwDEtGd7zHGcCs+paH43Fkx6MC3pEVl6wi0aozk9+FAk= +=Ko8e +-END PGP SIGNATURE- Added: dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.sha256 == --- dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.sha256 (added) +++ dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.sha256 Wed Apr 21 17:46:11 2021 @@ -0,0 +1 @@ +5dc5ed3c17a3b4511d012d06d876a04f2f88cfcc8cc67d37306bf8d9f5542dfe Added: dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.sha512 == --- dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.sha512 (added) +++ dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-bin.tar.gz.sha512 Wed Apr 21 17:46:11 2021 @@ -0,0 +1 @@ +68fe510809c44584a48fafc66b87ffdc46eb3ea403af1aae21ad8fbca8c3bbbe484aaf783ad6d20c63fc201f0d04e45f56a16d01b674119da5b3a9e70fa6168d Added: dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz.asc == --- dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz.asc (added) +++ dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz.asc Wed Apr 21 17:46:11 2021 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmCAYuYACgkQ6RM1134+ +h8t7GQ/8DCD/Z3Tq02VL6L82fq+xOSNTza77manQkatImzeBzMqy5o9YxaU2soiU +sZpf9E8hrQfeOv4r+Q7m3rTZ9o0yLQSxf/nM97CnWD/Ym95Y8CkNVGAOyziQGokR +sHb+yKliSWMmq8BZmAdR2bMRpKWSUC3ImuADY/2ecmHHJOi5vBrn/1rYmUtku8xC +zf3obz/5j/zO1GTkgi9vEdg05Fgy0Twsw2ejm9MEYpMbftlekiPDRsz4WEwFJ1r4 +a3EBbhBthI70Wj6rhHArjGYBM9jLN4O7NhQrlTO1ukjVgBroRr2PAkSE6W0KNqPr +pzFXYmY5RKKsN+R4g/2XNwL06qE/4mF8QXgdbvYgRoq4jzNT9AQnCdJ7LXXXkL6X +ESa3z5ezifwdx8CuLfO52vWrJpWhsr89bVNtOWyPBurOn6J73KXFwFMwGwUB44Hc +Grz5JM6Fkuw8uiIM/Tpo5Tf7+0UYI9YT22R9oeJQ19Tt93OaZxF7mEA97lNOhel3 +w/rw+i2s478QCfRwxw17JXiZD0Lr+HnjVkmzP7d4FHJzgj4Lh0sgJEvbWz2meACR +uPjN4GeFAF0v3ZiDv76HCozL3kDN09ymeX3LT8TdKisFVKinvA+e7gtDLME1lx88 +7y9ujDVpG6WhmAbE+LMkVE4xaCFuvXUwiWT08gW8YuIykuk7j9Q= +=K0nS +-END PGP SIGNATURE- Added: dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz.sha256 == --- dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz.sha256 (added) +++ dev/cassandra/4.0-rc1/apache-cassandra-4.0-rc1-src.tar.gz.sha256 Wed Apr 21 17:46:11 2021 @@
[jira] [Commented] (CASSANDRA-16610) Implement XXHashPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-16610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326764#comment-17326764
]
Chris Lohfink commented on CASSANDRA-16610:
---
to be fair, our murmur implementation isnt even a correct implementation but we
cant fix it. A new partitioner might be chance to get a more standard thing for
client drivers wanting token awareness to not have to do custom
implementations. That said we also need code changes to all the drivers to
support this...
> Implement XXHashPartitioner
> ---
>
> Key: CASSANDRA-16610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16610
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Priority: Normal
> Attachments: jmh-result.json
>
>
> I implemented partitioner based on XXHash algorithm.
> There are two branches, the first xxhash, extracts common parts with Murmur
> as there is a lot of overlap between these two.
> The second branch just copies everything from Murmur and changes just bits
> which are necessary.
> I am not sure what path we want to go with so I just provided both to easier
> elaborate on.
> I have written a microbenchmark measuring both partitioners and XXHash
> implementation is very fast, around 10x faster (on greater payloads).
> Benchmark is included in xxhash-2 branch.
> https://github.com/instaclustr/cassandra/tree/xxhash-2
> https://github.com/instaclustr/cassandra/tree/xxhash
> {code:java}
> [java] Benchmark (bufferSize) Mode Cnt
> Score Error Units
> [java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
> 157.942 ± 0.110 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
> 204.670 ± 0.152 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
> 361.068 ± 0.228 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
> 1325.670 ± 1.255 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
> 2594.651 ± 2.725 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
> 5082.166 ± 1.721 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
> 10112.020 ± 3.637 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
> 40.650 ± 0.025 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
> 53.305 ± 0.035 ns/op
> [java] PartitionersBench.benchXXHashPartitioner131 avgt 20
> 67.098 ± 0.057 ns/op
> [java] PartitionersBench.benchXXHashPartitioner517 avgt 20
> 150.415 ± 0.107 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
> 265.614 ± 0.140 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
> 365.796 ± 0.225 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
> 925.841 ± 0.664 ns/op
> {code}
> {code:java}
> [java] PartitionersBench.benchMurmur3Partitioner 3 avgt5
> 44.516 ± 0.345 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 5 avgt5
> 54.930 ± 0.450 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 7 avgt5
> 63.428 ± 0.266 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 9 avgt5
> 69.456 ± 0.467 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner11 avgt5
> 81.411 ± 0.535 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner16 avgt5
> 68.621 ± 0.417 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 3 avgt5
> 26.820 ± 0.271 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 5 avgt5
> 28.182 ± 0.139 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 7 avgt5
> 31.557 ± 0.161 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 9 avgt5
> 31.017 ± 0.212 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 11 avgt5
> 33.233 ± 0.136 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 16 avgt5
> 31.386 ± 0.128 ns/op
> {code}
> https://github.com/OpenHFT/Zero-Allocation-Hashing
> https://cyan4973.github.io/xxHash/
--
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] tag 4.0-rc1-tentative created (now 3282f5e)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 4.0-rc1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. at 3282f5e (commit) This tag includes the following new commits: new 3282f5e Prepare debian changelog for 4.0-rc1 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Prepare debian changelog for 4.0-rc1
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to tag 4.0-rc1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 3282f5ecf187ecbb56b8d73ab9a9110c010898b0 Author: Mick Semb Wever AuthorDate: Wed Apr 21 19:32:21 2021 +0200 Prepare debian changelog for 4.0-rc1 --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 66630ba..bde2f1e 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,7 +2,7 @@ cassandra (4.0~rc1) unstable; urgency=medium * New release - -- Mick Semb Wever Fri, 26 Mar 2021 20:55:56 +0100 + -- Mick Semb Wever Wed, 21 Apr 2021 19:24:28 +0200 cassandra (4.0~beta4) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16625) Add a CircleCI job to run some tests repeatedly
[
https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326753#comment-17326753
]
David Capwell edited comment on CASSANDRA-16625 at 4/21/21, 5:28 PM:
-
Good idea, it would replace my following scripts (which just runs the test in a
loop till it fails)
{code}
$ cat ci-test-loop
#!/usr/bin/env bash
#set -o xtrace
set -o errexit
set -o pipefail
set -o nounset
bin="$(cd "$(dirname "$0")" > /dev/null; pwd)"
class_name="$1"
path="$(echo "$class_name" | tr '.' '/' ).java"
if [[ ! "$path" =~ distributed/upgrade ]]; then
ant realclean && ant && ant generate-idea-files
fi
counter=1
echo ">>> Running attempt $counter"
while $bin/ci-test "$class_name" --reuse; do
counter=$(( $counter + 1 ))
echo ">>> Running attempt $counter"
done;
{code}
{code}
$ cat ci-test
#!/usr/bin/env bash
#set -o xtrace
set -o errexit
set -o pipefail
set -o nounset
usage() {
if [[ $# -gt 0 ]]; then
echo "$*" 1>&2
fi
cat < /dev/null; pwd)"
class_name="$1"
path="$(echo "$class_name" | tr '.' '/' ).java"
#prefix="$( find test | grep "$path" | awk -F/ '{print $2}' )"
if [[ ! "$path" =~ distributed/upgrade ]]; then
ant realclean && ant && ant generate-idea-files
fi
#test_timeout=$(grep "name=\"test.$prefix.timeout\"" build.xml | awk -F'"'
'{print $4}' || true)
#if [ -z "$test_timeout" ]; then
# test_timeout=$(grep 'name="test.timeout"' build.xml | awk -F'"' '{print $4}')
#fi
counter=1
echo ">>> Running attempt $counter"
while $bin/ci-test "$class_name" --reuse; do
counter=$(( $counter + 1 ))
echo ">>> Running attempt $counter"
done;
{code}
{code}
$ cat ci-test
#!/usr/bin/env bash
#set -o xtrace
set -o errexit
set -o pipefail
set -o nounset
usage() {
if [[ $# -gt 0 ]]; then
echo "$*" 1>&2
fi
cat < Add a CircleCI job to run some tests repeatedly
> ---
>
> Key: CASSANDRA-16625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16625
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Priority: Normal
>
> I think it could be useful to have an optional CircleCI job to run some
> specific tests n times. That way, tickets could attach CircleCI runs showing
> that the changes don't make a certain ticket flaky or, conversely, that they
> fix a flaky test. Doing this systematically should mitigate the risk of
> introducing new flaky tests, and I guess it would be more convenient and easy
> to share than running the tests locally or on a private CI system.
> It would also be nice to have something similar in Jenkins, but I'm focusing
> this ticket on CircleCI because it's available also for non-committers, so
> assignees can run their tests before setting the tickets as ready for review.
--
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-16625) Add a CircleCI job to run some tests repeatedly
[
https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326753#comment-17326753
]
David Capwell commented on CASSANDRA-16625:
---
Good idea, it would replace my following scripts (which just runs the test in a
loop till it fails)
{code}
$ cat ci-test-loop
#!/usr/bin/env bash
#set -o xtrace
set -o errexit
set -o pipefail
set -o nounset
bin="$(cd "$(dirname "$0")" > /dev/null; pwd)"
class_name="$1"
path="$(echo "$class_name" | tr '.' '/' ).java"
#prefix="$( find test | grep "$path" | awk -F/ '{print $2}' )"
if [[ ! "$path" =~ distributed/upgrade ]]; then
ant realclean && ant && ant generate-idea-files
fi
#test_timeout=$(grep "name=\"test.$prefix.timeout\"" build.xml | awk -F'"'
'{print $4}' || true)
#if [ -z "$test_timeout" ]; then
# test_timeout=$(grep 'name="test.timeout"' build.xml | awk -F'"' '{print $4}')
#fi
counter=1
echo ">>> Running attempt $counter"
while $bin/ci-test "$class_name" --reuse; do
counter=$(( $counter + 1 ))
echo ">>> Running attempt $counter"
done;
{code}
{code}
$ cat ci-test
#!/usr/bin/env bash
#set -o xtrace
set -o errexit
set -o pipefail
set -o nounset
usage() {
if [[ $# -gt 0 ]]; then
echo "$*" 1>&2
fi
cat < Add a CircleCI job to run some tests repeatedly
> ---
>
> Key: CASSANDRA-16625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16625
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Priority: Normal
>
> I think it could be useful to have an optional CircleCI job to run some
> specific tests n times. That way, tickets could attach CircleCI runs showing
> that the changes don't make a certain ticket flaky or, conversely, that they
> fix a flaky test. Doing this systematically should mitigate the risk of
> introducing new flaky tests, and I guess it would be more convenient and easy
> to share than running the tests locally or on a private CI system.
> It would also be nice to have something similar in Jenkins, but I'm focusing
> this ticket on CircleCI because it's available also for non-committers, so
> assignees can run their tests before setting the tickets as ready for review.
--
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
svn commit: r47313 - /dev/cassandra/4.0-rc1/
Author: mck Date: Wed Apr 21 16:55:03 2021 New Revision: 47313 Log: Cassandra 4.0-rc1 first vote didn't pass ref: https://lists.apache.org/thread.html/ra2157e9245717f872069e6dd5f582981bf645678fcf552eb7fa53598%40%3Cdev.cassandra.apache.org%3E Removed: dev/cassandra/4.0-rc1/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0-rc1-tentative deleted (was 2facbc9)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 4.0-rc1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. *** WARNING: tag 4.0-rc1-tentative was deleted! *** was 2facbc9 Prepare debian changelog for 4.0-rc1 The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16624) Update CONTRIBUTING.md
[ https://issues.apache.org/jira/browse/CASSANDRA-16624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16624: - Test and Documentation Plan: docs Status: Patch Available (was: Open) > Update CONTRIBUTING.md > -- > > Key: CASSANDRA-16624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16624 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Mitesh Gupta >Assignee: Mitesh Gupta >Priority: Normal > Labels: pull-request-available > > It shows 'Page Not Found' when we open the link given in "Running Cassandra > in IDEA guide" because it is moved to another place. -- 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-16624) Update CONTRIBUTING.md
[ https://issues.apache.org/jira/browse/CASSANDRA-16624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326699#comment-17326699 ] Brandon Williams commented on CASSANDRA-16624: -- There are a few more links that we could update as well: https://github.com/driftx/cassandra/tree/CASSANDRA-16624 > Update CONTRIBUTING.md > -- > > Key: CASSANDRA-16624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16624 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Mitesh Gupta >Assignee: Mitesh Gupta >Priority: Normal > Labels: pull-request-available > > It shows 'Page Not Found' when we open the link given in "Running Cassandra > in IDEA guide" because it is moved to another place. -- 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-16624) Update CONTRIBUTING.md
[ https://issues.apache.org/jira/browse/CASSANDRA-16624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16624: - Change Category: Operability Component/s: Documentation/Website Status: Open (was: Triage Needed) > Update CONTRIBUTING.md > -- > > Key: CASSANDRA-16624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16624 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Mitesh Gupta >Assignee: Mitesh Gupta >Priority: Normal > Labels: pull-request-available > > It shows 'Page Not Found' when we open the link given in "Running Cassandra > in IDEA guide" because it is moved to another place. -- 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-16625) Add a CircleCI job to run some tests repeatedly
Andres de la Peña created CASSANDRA-16625: - Summary: Add a CircleCI job to run some tests repeatedly Key: CASSANDRA-16625 URL: https://issues.apache.org/jira/browse/CASSANDRA-16625 Project: Cassandra Issue Type: Task Components: CI Reporter: Andres de la Peña I think it could be useful to have an optional CircleCI job to run some specific tests n times. That way, tickets could attach CircleCI runs showing that the changes don't make a certain ticket flaky or, conversely, that they fix a flaky test. Doing this systematically should mitigate the risk of introducing new flaky tests, and I guess it would be more convenient and easy to share than running the tests locally or on a private CI system. It would also be nice to have something similar in Jenkins, but I'm focusing this ticket on CircleCI because it's available also for non-committers, so assignees can run their tests before setting the tickets as ready for review. -- 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-16624) Update CONTRIBUTING.md
[ https://issues.apache.org/jira/browse/CASSANDRA-16624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mitesh Gupta updated CASSANDRA-16624: - Complexity: Low Hanging Fruit Component/s: (was: Documentation/Website) Labels: pull-request-available (was: ) > Update CONTRIBUTING.md > -- > > Key: CASSANDRA-16624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16624 > Project: Cassandra > Issue Type: Task >Reporter: Mitesh Gupta >Assignee: Mitesh Gupta >Priority: Normal > Labels: pull-request-available > > It shows 'Page Not Found' when we open the link given in "Running Cassandra > in IDEA guide" because it is moved to another place. -- 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-16624) Update CONTRIBUTING.md
[ https://issues.apache.org/jira/browse/CASSANDRA-16624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326688#comment-17326688 ] Mitesh Gupta commented on CASSANDRA-16624: -- https://github.com/apache/cassandra/pull/961 > Update CONTRIBUTING.md > -- > > Key: CASSANDRA-16624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16624 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Mitesh Gupta >Assignee: Mitesh Gupta >Priority: Normal > > It shows 'Page Not Found' when we open the link given in "Running Cassandra > in IDEA guide" because it is moved to another place. -- 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-16624) Update CONTRIBUTING.md
Mitesh Gupta created CASSANDRA-16624: Summary: Update CONTRIBUTING.md Key: CASSANDRA-16624 URL: https://issues.apache.org/jira/browse/CASSANDRA-16624 Project: Cassandra Issue Type: Task Components: Documentation/Website Reporter: Mitesh Gupta Assignee: Mitesh Gupta It shows 'Page Not Found' when we open the link given in "Running Cassandra in IDEA guide" because it is moved to another place. -- 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-16605) The dependencies in the Cassandra DEB package prevent installation on Ubuntu 20.04+
[ https://issues.apache.org/jira/browse/CASSANDRA-16605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326550#comment-17326550 ] Brandon Williams edited comment on CASSANDRA-16605 at 4/21/21, 3:49 PM: I'm not sure what version this is supposed to apply to, but python3 isn't supported until 4.0 in CASSANDRA-10190 which already has packaging to allow both in CASSANDRA-16396. was (Author: brandon.williams): I'm not sure what version this is supposed to apply to, but python3 isn't support until 4.0 in CASSANDRA-10190 which already has packaging to allow both in CASSANDRA-16396. > The dependencies in the Cassandra DEB package prevent installation on Ubuntu > 20.04+ > --- > > Key: CASSANDRA-16605 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16605 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Michael Kelly >Assignee: Erick Ramirez >Priority: Normal > Fix For: 4.0-rc1, 4.0 > > > The DEB package for Cassandra has a dependency on 'python >= 2.7'. > In Ubuntu 18.04 there is a package called 'python' which installs python2.7. > This package has been removed in Ubuntu 20.04 so the dependency cannot be > satisified. > > Proposed solution: > Change the dependency 'python >= 2.7' to something like 'python2 >= 2.7 OR > python3 >= 3.6'. -- 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-16066) Update and rework cassandra-website material to work with Antora
[
https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326637#comment-17326637
]
Anthony Grasso commented on CASSANDRA-16066:
A near complete implementation of the new website tooling can be found on my
cassandra-website [fork|https://github.com/ossarga/cassandra-website] on branch
[anthony/CASSANDRA-16066_rebased|https://github.com/ossarga/cassandra-website/commits/anthony/CASSANDRA-16066_rebased].
Items left to do:
* Complete repository README updates
* Update CI commands and triggers
If you look through the changes on the branch above you will notice the website
repository code is separated into two main parts. These parts are represented
by the directories at the root level of the project. Specifically the structure
of the repository is:
{code}
ROOT
- site-content
- site-ui
{code}
h2. Site UI
The 'site-ui' directory contains only the UI styling files that determines the
look and feel of the site. A ui-bundle.zip file containing the styling
information will be generated from the contents of this directory. Generation
of the ui-bundle.zip will be done using {{gulp}} launched inside a Docker
container.
h2. Site Content
The 'site-content' directory contains all the raw page information e.g. where
to download, developer guidelines, how to commit patches, etc. The live website
HTML is generated from the contents of this directory. Generation of the HTML
content is done by {{antora}} launched inside a Docker container. As part of
the website HTML generation, the _ui-bundle.zip_ file, and the Cassandra
documentation location are passed to {{antora}}. It uses the ui-bundle.zip to
style the website. The Cassandra documentation location will be used to gather
and generate documentation for each Cassandra version.
h1. Developer Examples
The development cycle is very similar to the existing website development
cycle. As such, to test changes before committing, it is a requirement that you
build the website locally. Building the Apache Cassandra website takes a number
of steps. To make things easier we have provided a suite of tools to build the
full website in a few simple commands and have it ready to commit via git.
h2. Tooling components
The tooling is made up of the following components
* Run script: {{./run.sh}} - Provides a single command line interface that
generates the docker commands to run the website and UI docker containers.
Using the containers, it can build the Cassandra website UI components,
generate the Cassandra versioned documentation, and generate the website HTML.
* Website Docker container: {{Dockerfile}} and {{docker-entrypoint.sh}} -
Contains the libraries necessary to generate the Cassandra versioned
documentation, and generate the website HTML using Antora.
* Antora Site YAML script: {{bin/site_yaml_generator.py}} - Used by the Website
Docker container to create the YAML file that defines the sources for the
website content, optionally the cassandra versioned documentation, and the UI
styling bundle to apply.
* Website UI Docker container: {{site-ui/Dockerfile}} and
{{site-ui/docker-entrypoint.sh}} - Contains the libraries necessary to generate
the UI bundle ZIP file the is applied by Antora to style the website and
documentation.
h2. Building Prerequisites
To build and run the Docker container you will need {{Docker}} version 2.0.0.0
or greater. If you need a copy of the site code you will need {{git}} as well.
h2. Building the Website
If you need a copy of the site code run this command:
{code}
$ git clone https://github.com/apache/cassandra-website.git
$ cd ./cassandra-website
{code}
To build the website only, run the following command from within the
{{./cassandra-website}} directory (assuming you used the above clone command).
{code}
$ ./run.sh website build
{code}
*Tip:* In order to prevent root-owned modified files in your repository, the
container user, {{build}}, is set up with a default {{UID=1000:GID=1000}},
which is usually the first user configured on a linux machine. If your local
user is different you should set up the container user with your local host
user's UID:GID, replace the above with:
{code}
$ ./run.sh -v UID_ARG=$(id -u) -v GID_ARG=$(id -g) website container
$ ./run.sh website build
{code}
This will build the website content using your local copy of the
cassandra-website, and the current checked-out branch. Use this command if you
want to make a change to a top-level webpage without building the docs for any
versions of cassandra.
Once building has completed, the HTML content will be in the
{{./site-content/build/html/}} directory ready to be reviewed and committed.
h2. Build the Website when Developing
The website tooling is very flexible and allows for a wide range of development
scenarios.
h3. Build the website from a different branch
You can te
[jira] [Updated] (CASSANDRA-16623) Remove references to run_dtests from README
[
https://issues.apache.org/jira/browse/CASSANDRA-16623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16623:
Change Category: Quality Assurance
Complexity: Low Hanging Fruit
Fix Version/s: 4.0.x
Priority: Low (was: Normal)
Status: Open (was: Triage Needed)
> Remove references to run_dtests from README
> ---
>
> Key: CASSANDRA-16623
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16623
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Matt Fleming
>Priority: Low
> Fix For: 4.0.x
>
>
> Newcomers to cassandra-dtest that look through README.md will see that the
> run_dtests.py script is the quickest way to get started running tests.
> Unfortunately, the script has a number of problems and I'm not sure it ever
> work properly after the move to the pytest framework.
> h2. Process stdout/stderr buffering
> Firstly, when I execute run_dtests.py I don't see any output after
> {{$ ./run_dtests.py --dtest-tests paging_test.py }}
> {{= test session starts
> ==}}
> This looks likely to be because of the buffering that pytest does internally
> for stdout and stderr and because of the way that it's executed by
> run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following
> line for most of the execution because there's no data available in the pipe
> for stderr:
> {{stderr_output = sp.stderr.readline()}}
> See also [https://github.com/pytest-dev/pytest/issues/1886]
> h2. --pytest-options doesn't work
> Secondly, the options specified in --pytest-options aren't actually passed
> through to pytest.
> h2. Most devs run pytest directly
> When I spoke to [~edimitrova] it seemed like most developers just run the
> tests directly with pytest which would explain why run_dtests.py has
> bitrotted.
--
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-16623) Remove references to run_dtests from README
[
https://issues.apache.org/jira/browse/CASSANDRA-16623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Fleming updated CASSANDRA-16623:
-
Description:
Newcomers to cassandra-dtest that look through README.md will see that the
run_dtests.py script is the quickest way to get started running tests.
Unfortunately, the script has a number of problems and I'm not sure it ever
work properly after the move to the pytest framework.
h2. Process stdout/stderr buffering
Firstly, when I execute run_dtests.py I don't see any output after
{{$ ./run_dtests.py --dtest-tests paging_test.py }}
{{= test session starts
==}}
This looks likely to be because of the buffering that pytest does internally
for stdout and stderr and because of the way that it's executed by
run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following
line for most of the execution because there's no data available in the pipe
for stderr:
{{stderr_output = sp.stderr.readline()}}
See also [https://github.com/pytest-dev/pytest/issues/1886]
h2. --pytest-options doesn't work
Secondly, the options specified in --pytest-options aren't actually passed
through to pytest.
h2. Most devs run pytest directly
When I spoke to [~edimitrova] it seemed like most developers just run the tests
directly with pytest which would explain why run_dtests.py has bitrotted.
was:
Newcomers to cassandra-dtest that look through README.md will see that the
run_dtests.py script is the quickest way to get started running tests.
Unfortunately, the script has a number of problems and I'm not sure it ever
work properly after the move to the pytest framework.
h2. Process stdout/stderr buffering
Firstly, when I execute run_dtests.py I don't see any output after
{{$ ./run_dtests.py --dtest-tests paging_test.py }}
{{ = test session starts
==}}
This looks likely to be because of the buffering that pytest does internally
for stdout and stderr and because of the way that it's executed by
run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following
line for most of the execution because there's no data available in the pipe
for stderr:
{{stderr_output = sp.stderr.readline()}}
See also https://github.com/pytest-dev/pytest/issues/1886
h2. --pytest-options doesn't work
Secondly, the options specified in --pytest-options aren't actually passed
through to pytest.
h2. Most devs run pytest directly
When I spoke to [~edimitrova] it seemed like most developers just run the tests
directly with pytest which would explain why run_dtests.py has bitrotted.
> Remove references to run_dtests from README
> ---
>
> Key: CASSANDRA-16623
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16623
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Matt Fleming
>Priority: Normal
>
> Newcomers to cassandra-dtest that look through README.md will see that the
> run_dtests.py script is the quickest way to get started running tests.
> Unfortunately, the script has a number of problems and I'm not sure it ever
> work properly after the move to the pytest framework.
> h2. Process stdout/stderr buffering
> Firstly, when I execute run_dtests.py I don't see any output after
> {{$ ./run_dtests.py --dtest-tests paging_test.py }}
> {{= test session starts
> ==}}
> This looks likely to be because of the buffering that pytest does internally
> for stdout and stderr and because of the way that it's executed by
> run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following
> line for most of the execution because there's no data available in the pipe
> for stderr:
> {{stderr_output = sp.stderr.readline()}}
> See also [https://github.com/pytest-dev/pytest/issues/1886]
> h2. --pytest-options doesn't work
> Secondly, the options specified in --pytest-options aren't actually passed
> through to pytest.
> h2. Most devs run pytest directly
> When I spoke to [~edimitrova] it seemed like most developers just run the
> tests directly with pytest which would explain why run_dtests.py has
> bitrotted.
--
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-16597) Introduce Maven wrapper to build for Maven-less build environments
[ https://issues.apache.org/jira/browse/CASSANDRA-16597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-16597: - Assignee: (was: Stefan Miklosovic) > Introduce Maven wrapper to build for Maven-less build environments > -- > > Key: CASSANDRA-16597 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16597 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > With the introduction of CASSANDRA-16391, the build machine needs to have > Maven installed locally as it executes "mvn" command in its tasks. This might > be avoided by adding Maven wrapper which would download (and cache) such > installation so build environment might be completely Maven-less otherwise. -- 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-16238) Fix flaky jvm-dtests that fail with Unable to contact any seeds
[
https://issues.apache.org/jira/browse/CASSANDRA-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-16238:
Assignee: Brandon Williams
> Fix flaky jvm-dtests that fail with Unable to contact any seeds
> ---
>
> Key: CASSANDRA-16238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16238
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 16238-archived-failures.txt
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4231
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795),
> ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)]
> {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-16623) Remove references to run_dtests from README
[
https://issues.apache.org/jira/browse/CASSANDRA-16623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Fleming updated CASSANDRA-16623:
-
Description:
Newcomers to cassandra-dtest that look through README.md will see that the
run_dtests.py script is the quickest way to get started running tests.
Unfortunately, the script has a number of problems and I'm not sure it ever
work properly after the move to the pytest framework.
h2. Process stdout/stderr buffering
Firstly, when I execute run_dtests.py I don't see any output after
{{$ ./run_dtests.py --dtest-tests paging_test.py }}
{{ = test session starts
==}}
This looks likely to be because of the buffering that pytest does internally
for stdout and stderr and because of the way that it's executed by
run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following
line for most of the execution because there's no data available in the pipe
for stderr:
{{stderr_output = sp.stderr.readline()}}
See also https://github.com/pytest-dev/pytest/issues/1886
h2. --pytest-options doesn't work
Secondly, the options specified in --pytest-options aren't actually passed
through to pytest.
h2. Most devs run pytest directly
When I spoke to [~edimitrova] it seemed like most developers just run the tests
directly with pytest which would explain why run_dtests.py has bitrotted.
was:
Newcomers to cassandra-dtest that look through README.md will see that the
run_dtests.py script is the quickest way to get started running tests.
Unfortunately, the script has a number of problems and I'm not sure it ever
work properly after the move to the pytest framework.
h2. Process stdout/stderr buffering
Firstly, when I execute run_dtests.py I don't see any output after
$ ./run_dtests.py --dtest-tests paging_test.py
= test session starts
==
This looks likely to be because of the buffering that pytest does internally
for stdout and stderr and because of the way that it's executed by
run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following
line for most of the execution because there's no data available in the pipe
for stderr:
stderr_output = sp.stderr.readline()
See also pytest-dev/pytest#1886
h2. --pytest-options doesn't work
Secondly, the options specified in --pytest-options aren't actually passed
through to pytest.
h2. Most devs run pytest directly
When I spoke to [~edimitrova] it seemed like most developers just run the tests
directly with pytest which would explain why run_dtests.py has bitrotted.
> Remove references to run_dtests from README
> ---
>
> Key: CASSANDRA-16623
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16623
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Matt Fleming
>Priority: Normal
>
> Newcomers to cassandra-dtest that look through README.md will see that the
> run_dtests.py script is the quickest way to get started running tests.
> Unfortunately, the script has a number of problems and I'm not sure it ever
> work properly after the move to the pytest framework.
> h2. Process stdout/stderr buffering
> Firstly, when I execute run_dtests.py I don't see any output after
> {{$ ./run_dtests.py --dtest-tests paging_test.py }}
> {{ = test session starts
> ==}}
> This looks likely to be because of the buffering that pytest does internally
> for stdout and stderr and because of the way that it's executed by
> run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following
> line for most of the execution because there's no data available in the pipe
> for stderr:
> {{stderr_output = sp.stderr.readline()}}
> See also https://github.com/pytest-dev/pytest/issues/1886
> h2. --pytest-options doesn't work
> Secondly, the options specified in --pytest-options aren't actually passed
> through to pytest.
> h2. Most devs run pytest directly
> When I spoke to [~edimitrova] it seemed like most developers just run the
> tests directly with pytest which would explain why run_dtests.py has
> bitrotted.
--
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-16623) Remove references to run_dtests from README
[ https://issues.apache.org/jira/browse/CASSANDRA-16623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Fleming updated CASSANDRA-16623: - Description: Newcomers to cassandra-dtest that look through README.md will see that the run_dtests.py script is the quickest way to get started running tests. Unfortunately, the script has a number of problems and I'm not sure it ever work properly after the move to the pytest framework. h2. Process stdout/stderr buffering Firstly, when I execute run_dtests.py I don't see any output after $ ./run_dtests.py --dtest-tests paging_test.py = test session starts == This looks likely to be because of the buffering that pytest does internally for stdout and stderr and because of the way that it's executed by run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following line for most of the execution because there's no data available in the pipe for stderr: stderr_output = sp.stderr.readline() See also pytest-dev/pytest#1886 h2. --pytest-options doesn't work Secondly, the options specified in --pytest-options aren't actually passed through to pytest. h2. Most devs run pytest directly When I spoke to [~edimitrova] it seemed like most developers just run the tests directly with pytest which would explain why run_dtests.py has bitrotted. was: Newcomers to cassandra-dtest that look through README.md will see that the run_dtests.py script is the quickest way to get started running tests. Unfortunately, the script has a number of problems and I'm not sure it ever work properly after the move to the pytest framework. h2. Process stdout/stderr buffering Firstly, when I execute run_dtests.py I don't see any output after $ ./run_dtests.py --dtest-tests paging_test.py = test session starts == This looks likely to be because of the buffering that pytest does internally for stdout and stderr and because of the way that it's executed by run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following line for most of the execution because there's no data available in the pipe for stderr: stderr_output = sp.stderr.readline() See also pytest-dev/pytest#1886 h2. --pytest-options doesn't work Secondly, the options specified in --pytest-options aren't actually passed through to pytest. h2. Most devs run pytest directly When I spoke to @ekaterinadimitrova2 it seemed like most developers just run the tests directly with pytest which would explain why run_dtests.py has bitrotted. > Remove references to run_dtests from README > --- > > Key: CASSANDRA-16623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16623 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Matt Fleming >Priority: Normal > > Newcomers to cassandra-dtest that look through README.md will see that the > run_dtests.py script is the quickest way to get started running tests. > Unfortunately, the script has a number of problems and I'm not sure it ever > work properly after the move to the pytest framework. > h2. Process stdout/stderr buffering > Firstly, when I execute run_dtests.py I don't see any output after > $ ./run_dtests.py --dtest-tests paging_test.py > = test session starts > == > This looks likely to be because of the buffering that pytest does internally > for stdout and stderr and because of the way that it's executed by > run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following > line for most of the execution because there's no data available in the pipe > for stderr: > stderr_output = sp.stderr.readline() > See also pytest-dev/pytest#1886 > h2. --pytest-options doesn't work > Secondly, the options specified in --pytest-options aren't actually passed > through to pytest. > h2. Most devs run pytest directly > When I spoke to [~edimitrova] it seemed like most developers just run the > tests directly with pytest which would explain why run_dtests.py has > bitrotted. -- 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-16593) Fix flaky org.apache.cassandra.service.ActiveRepairServiceTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-16593:
Assignee: (was: Brandon Williams)
> Fix flaky org.apache.cassandra.service.ActiveRepairServiceTest
> --
>
> Key: CASSANDRA-16593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16593
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/612/tests
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<1>
> at
> org.apache.cassandra.service.ActiveRepairServiceTest.testQueueWhenPoolFullStrategy(ActiveRepairServiceTest.java:435)
> Standard Output
> INFO [main] 2021-04-10 17:37:25,869 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-04-10 17:37:25,872 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-04-10 17:37:25,950 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-04-10 17:37:25,968 PlatformDependent0
> ...[truncated 88170 chars]...
> build/test/cassandra/data:62/system/local-7ad54392bcdd35a684174e047860b377/na_txn_flush_6c2ddd10-9a23-11eb-9207-35733cfe3fbb.log
>
> DEBUG [MemtableFlushWriter:1] 2021-04-10 17:37:29,454
> ColumnFamilyStore.java:1197 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data:62/system/local-7ad54392bcdd35a684174e047860b377/na-15-big-Data.db')]
> (1 sstables, 4.943KiB), biggest 4.943KiB, smallest 4.943KiB
> DEBUG [main] 2021-04-10 17:37:29,456 StorageService.java:1617 - NORMAL
> {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-16623) Remove references to run_dtests from README
[ https://issues.apache.org/jira/browse/CASSANDRA-16623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326599#comment-17326599 ] Matt Fleming commented on CASSANDRA-16623: -- A patch to update README.md can be found here https://github.com/mfleming/cassandra-dtest/tree/run_dtests > Remove references to run_dtests from README > --- > > Key: CASSANDRA-16623 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16623 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Matt Fleming >Priority: Normal > > Newcomers to cassandra-dtest that look through README.md will see that the > run_dtests.py script is the quickest way to get started running tests. > Unfortunately, the script has a number of problems and I'm not sure it ever > work properly after the move to the pytest framework. > h2. Process stdout/stderr buffering > Firstly, when I execute run_dtests.py I don't see any output after > $ ./run_dtests.py --dtest-tests paging_test.py > = test session starts > == > This looks likely to be because of the buffering that pytest does internally > for stdout and stderr and because of the way that it's executed by > run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following > line for most of the execution because there's no data available in the pipe > for stderr: > stderr_output = sp.stderr.readline() > See also pytest-dev/pytest#1886 > h2. --pytest-options doesn't work > Secondly, the options specified in --pytest-options aren't actually passed > through to pytest. > h2. Most devs run pytest directly > When I spoke to @ekaterinadimitrova2 it seemed like most developers just run > the tests directly with pytest which would explain why run_dtests.py has > bitrotted. -- 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-16593) Fix flaky org.apache.cassandra.service.ActiveRepairServiceTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326597#comment-17326597
]
Brandon Williams commented on CASSANDRA-16593:
--
Unable to repro and I don't see any recent failures, so perhaps another victim
of concurrency.
> Fix flaky org.apache.cassandra.service.ActiveRepairServiceTest
> --
>
> Key: CASSANDRA-16593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16593
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/612/tests
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<1>
> at
> org.apache.cassandra.service.ActiveRepairServiceTest.testQueueWhenPoolFullStrategy(ActiveRepairServiceTest.java:435)
> Standard Output
> INFO [main] 2021-04-10 17:37:25,869 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-04-10 17:37:25,872 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-04-10 17:37:25,950 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-04-10 17:37:25,968 PlatformDependent0
> ...[truncated 88170 chars]...
> build/test/cassandra/data:62/system/local-7ad54392bcdd35a684174e047860b377/na_txn_flush_6c2ddd10-9a23-11eb-9207-35733cfe3fbb.log
>
> DEBUG [MemtableFlushWriter:1] 2021-04-10 17:37:29,454
> ColumnFamilyStore.java:1197 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data:62/system/local-7ad54392bcdd35a684174e047860b377/na-15-big-Data.db')]
> (1 sstables, 4.943KiB), biggest 4.943KiB, smallest 4.943KiB
> DEBUG [main] 2021-04-10 17:37:29,456 StorageService.java:1617 - NORMAL
> {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-16623) Remove references to run_dtests from README
Matt Fleming created CASSANDRA-16623: Summary: Remove references to run_dtests from README Key: CASSANDRA-16623 URL: https://issues.apache.org/jira/browse/CASSANDRA-16623 Project: Cassandra Issue Type: Improvement Components: Test/dtest/python Reporter: Matt Fleming Newcomers to cassandra-dtest that look through README.md will see that the run_dtests.py script is the quickest way to get started running tests. Unfortunately, the script has a number of problems and I'm not sure it ever work properly after the move to the pytest framework. h2. Process stdout/stderr buffering Firstly, when I execute run_dtests.py I don't see any output after $ ./run_dtests.py --dtest-tests paging_test.py = test session starts == This looks likely to be because of the buffering that pytest does internally for stdout and stderr and because of the way that it's executed by run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following line for most of the execution because there's no data available in the pipe for stderr: stderr_output = sp.stderr.readline() See also pytest-dev/pytest#1886 h2. --pytest-options doesn't work Secondly, the options specified in --pytest-options aren't actually passed through to pytest. h2. Most devs run pytest directly When I spoke to @ekaterinadimitrova2 it seemed like most developers just run the tests directly with pytest which would explain why run_dtests.py has bitrotted. -- 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-16622) Remove references to run_dtests from README
Matt Fleming created CASSANDRA-16622: Summary: Remove references to run_dtests from README Key: CASSANDRA-16622 URL: https://issues.apache.org/jira/browse/CASSANDRA-16622 Project: Cassandra Issue Type: Improvement Components: Test/dtest/python Reporter: Matt Fleming Newcomers to cassandra-dtest that look through README.md will see that the run_dtests.py script is the quickest way to get started running tests. Unfortunately, the script has a number of problems and I'm not sure it ever work properly after the move to the pytest framework. h2. Process stdout/stderr buffering Firstly, when I execute run_dtests.py I don't see any output after $ ./run_dtests.py --dtest-tests paging_test.py = test session starts == This looks likely to be because of the buffering that pytest does internally for stdout and stderr and because of the way that it's executed by run_dtests.py, i.e. I suspect that run_dtests.py is blocked on the following line for most of the execution because there's no data available in the pipe for stderr: stderr_output = sp.stderr.readline() See also pytest-dev/pytest#1886 h2. --pytest-options doesn't work Secondly, the options specified in --pytest-options aren't actually passed through to pytest. I ran into this when trying to get more output during the execution of run_dtests.py (see above). h2. Most devs run pytest directly When I spoke to @ekaterinadimitrova2 it seemed like most developers just run the tests directly with pytest which would explain why run_dtests.py has bitrotted. -- 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-16597) Introduce Maven wrapper to build for Maven-less build environments
[
https://issues.apache.org/jira/browse/CASSANDRA-16597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326569#comment-17326569
]
Stefan Miklosovic commented on CASSANDRA-16597:
---
The error Mick got above comes from the fact that he the most probably tried to
do this in offline mode.
What happens when a dev is offline, that wrapper downloads an empty jar but
when we are back online, it will not find it because it will not attempt to
download it again (as that file is there, just empty) and empty jar does not
contain any classes ...
We discussed workarounds:
1) Use Ant's task "isreachable"
I do no think this work reliably, under the hood, it uses
InetAddress.isReachable(int) and in my case it just returns false (hence Ant
task always return false)
Quick reproducer:
{code:java}
import java.net.InetAddress;
public class Main
{
public static final void main(String[] args) throws Exception
{
InetAddress address = java.net.InetAddress.getByName("google.com");
// always returns false, this is what Ant task isreachable uses
System.out.println(address.isReachable(5));
}
}
{code}
{code:java}
https://www.google.com"; timeout="10"/>
{code}
In my case (or any variation of that), I was never able to get "true" on the
output. "isReachable" is known to be buggy, after very simple investigation
there is a lot of problems people have with this method of evaluating if a host
is reachable or not hence I think this solution is not applicable to be used in
a heterogeneous environments Cassandra developers work in.
2) Add binary JAR to repository and not try to download it - this is what we
are trying to avoid in a broader sense so that is not applicable too, I would
say
What I came up with is the custom task which would try wrapper's path and if
not successful and its wrapper jar is of size 0, it means that we are offline
as it could not download it so we fallback to system's Maven installation.
I was not able to script this in Ant so I extended ExecTask and did it there
specifically for our usecase.
https://github.com/apache/cassandra/pull/963/commits/ddac95d64131fa495cfbde436fd584e8f1531089
> Introduce Maven wrapper to build for Maven-less build environments
> --
>
> Key: CASSANDRA-16597
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16597
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> With the introduction of CASSANDRA-16391, the build machine needs to have
> Maven installed locally as it executes "mvn" command in its tasks. This might
> be avoided by adding Maven wrapper which would download (and cache) such
> installation so build environment might be completely Maven-less otherwise.
--
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-16605) The dependencies in the Cassandra DEB package prevent installation on Ubuntu 20.04+
[ https://issues.apache.org/jira/browse/CASSANDRA-16605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326550#comment-17326550 ] Brandon Williams commented on CASSANDRA-16605: -- I'm not sure what version this is supposed to apply to, but python3 isn't support until 4.0 in CASSANDRA-10190 which already has packaging to allow both in CASSANDRA-16396. > The dependencies in the Cassandra DEB package prevent installation on Ubuntu > 20.04+ > --- > > Key: CASSANDRA-16605 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16605 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Michael Kelly >Assignee: Erick Ramirez >Priority: Normal > Fix For: 4.0-rc1, 4.0 > > > The DEB package for Cassandra has a dependency on 'python >= 2.7'. > In Ubuntu 18.04 there is a package called 'python' which installs python2.7. > This package has been removed in Ubuntu 20.04 so the dependency cannot be > satisified. > > Proposed solution: > Change the dependency 'python >= 2.7' to something like 'python2 >= 2.7 OR > python3 >= 3.6'. -- 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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326000#comment-17326000
]
Brandon Williams edited comment on CASSANDRA-16588 at 4/21/21, 1:40 PM:
||Patch|CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-16588]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/693/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/691/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-16588-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/694/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/692/pipeline]|
We have to be careful in the test not to let StorageService get too far in
joining the ring otherwise all kinds of things start up that are not easily
restartable, so instead we can test checkForEndpointCollision directly.
was (Author: brandon.williams):
||Patch|CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-16588]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/691/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/691/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-16588-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/692/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/692/pipeline]|
We have to be careful in the test not to let StorageService get too far in
joining the ring otherwise all kinds of things start up that are not easily
restartable, so instead we can test checkForEndpointCollision directly.
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 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)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-16604) Parallelise docker container runs for tests in ci-cassandra.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326515#comment-17326515 ] Tomasz Lasica commented on CASSANDRA-16604: --- Code LGTM, but i have limited bash focus capability... > Before committing, more extensive CI required I am not sure if I should run it or you plan to run ? > Parallelise docker container runs for tests in ci-cassandra.a.o > --- > > Key: CASSANDRA-16604 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16604 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x > > > This was raised on the dev ML, where the consensus was to remove it: > https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E > The idea is to then replace ant test parallelism with docker container > parallelism. > PoC patch: > https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:mck/16587-2/trunk > This is just a quick PoC, aimed at the ci-cassandra agents that have > 4 cores and 16gb ram available to each executor, but I imagine instead > something that spawns a number of containers based on system > resources, like we currently do with get-cores and get-mem. > Also worth noting the overhead here, compared with the ant parallelism > approach, docker > builds everything in each container from scratch, but this too can be > improved easily enough. > Cleaning up any remnant `-Dtest.runners=` options is also part of this ticket. -- 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-16604) Parallelise docker container runs for tests in ci-cassandra.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Lasica updated CASSANDRA-16604: -- Reviewers: Tomasz Lasica Status: Review In Progress (was: Patch Available) > Parallelise docker container runs for tests in ci-cassandra.a.o > --- > > Key: CASSANDRA-16604 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16604 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x > > > This was raised on the dev ML, where the consensus was to remove it: > https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E > The idea is to then replace ant test parallelism with docker container > parallelism. > PoC patch: > https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:mck/16587-2/trunk > This is just a quick PoC, aimed at the ci-cassandra agents that have > 4 cores and 16gb ram available to each executor, but I imagine instead > something that spawns a number of containers based on system > resources, like we currently do with get-cores and get-mem. > Also worth noting the overhead here, compared with the ant parallelism > approach, docker > builds everything in each container from scratch, but this too can be > improved easily enough. > Cleaning up any remnant `-Dtest.runners=` options is also part of this ticket. -- 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-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16524:
---
Fix Version/s: (was: 4.0-beta)
4.0-rc1
Since Version: 4.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/27cc2fc3e275f56f1fa1df7285c389d5491acc8c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into trunk at 27cc2fc3e275f56f1fa1df7285c389d5491acc8c
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-rc1, 4.0
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> 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:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException:
> writerIndex(8560) + minWritableByte
[jira] [Commented] (CASSANDRA-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326500#comment-17326500
]
Benjamin Lerer commented on CASSANDRA-16524:
A big thank you to [~gianluca], [~bereng], [~e.dimitrova] and [~jasonstack] for
the patch and the reviews. Great job!
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> 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:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException:
> writerIndex(8560) + minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.ssl.OpenSslKeyMaterialManager.setKeyMaterial(OpenSslKeyMaterialM
[cassandra] branch trunk updated: Allow for setting buffer max capacity to increase it dynamically as needed
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 27cc2fc Allow for setting buffer max capacity to increase it
dynamically as needed
27cc2fc is described below
commit 27cc2fc3e275f56f1fa1df7285c389d5491acc8c
Author: Gianluca Righetto
AuthorDate: Mon Apr 19 13:42:56 2021 -0300
Allow for setting buffer max capacity to increase it dynamically as needed
patch by Gianluca Righetto; reviewed by Berenguer Blasi, Ekaterina
Dimitrova and Zhao Yang
for CASSANDRA-16524
---
CHANGES.txt| 1 +
.../apache/cassandra/net/BufferPoolAllocator.java | 43 -
.../cassandra/net/GlobalBufferPoolAllocator.java | 2 +-
.../cassandra/net/BufferPoolAllocatorTest.java | 196 +
4 files changed, 238 insertions(+), 4 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 108a762..c8434f7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-rc1
+ * Allow for setting buffer max capacity to increase it dynamically as needed
(CASSANDRA-16524)
* Harden internode message resource limit accounting against serialization
failures (CASSANDRA-16616)
* Add back the source release of python driver in tree to avoid fetching from
GitHub APIs (CASSANDRA-16599)
* Fix false unavailable for queries due to cluster topology changes
(CASSANDRA-16545)
diff --git a/src/java/org/apache/cassandra/net/BufferPoolAllocator.java
b/src/java/org/apache/cassandra/net/BufferPoolAllocator.java
index 11c0641..145d03d 100644
--- a/src/java/org/apache/cassandra/net/BufferPoolAllocator.java
+++ b/src/java/org/apache/cassandra/net/BufferPoolAllocator.java
@@ -26,6 +26,9 @@ import io.netty.buffer.UnpooledUnsafeDirectByteBuf;
import org.apache.cassandra.io.compress.BufferType;
import org.apache.cassandra.utils.memory.BufferPool;
import org.apache.cassandra.utils.memory.BufferPools;
+import org.assertj.core.util.VisibleForTesting;
+
+import static java.lang.Integer.max;
/**
* A trivial wrapper around BufferPool for integrating with Netty, but
retaining ownership of pooling behaviour
@@ -56,7 +59,7 @@ public abstract class BufferPoolAllocator extends
AbstractByteBufAllocator
@Override
protected ByteBuf newDirectBuffer(int minCapacity, int maxCapacity)
{
-ByteBuf result = new Wrapped(this, getAtLeast(minCapacity));
+ByteBuf result = new Wrapped(this, getAtLeast(minCapacity),
maxCapacity);
result.clear();
return result;
}
@@ -81,6 +84,12 @@ public abstract class BufferPoolAllocator extends
AbstractByteBufAllocator
bufferPool.putUnusedPortion(buffer);
}
+@VisibleForTesting
+public long usedSizeInBytes()
+{
+return bufferPool.usedSizeInBytes();
+}
+
void release()
{
}
@@ -93,15 +102,43 @@ public abstract class BufferPoolAllocator extends
AbstractByteBufAllocator
{
private ByteBuffer wrapped;
-Wrapped(BufferPoolAllocator allocator, ByteBuffer wrap)
+Wrapped(BufferPoolAllocator allocator, ByteBuffer wrap, int
maxCapacity)
{
-super(allocator, wrap, wrap.capacity());
+super(allocator, wrap, max(wrap.capacity(), maxCapacity));
wrapped = wrap;
}
@Override
+public ByteBuf capacity(int newCapacity)
+{
+if (newCapacity == capacity())
+return this;
+
+ByteBuf newBuffer = super.capacity(newCapacity);
+ByteBuffer nioBuffer = newBuffer.nioBuffer(0,
newBuffer.capacity());
+
+bufferPool.put(wrapped);
+wrapped = nioBuffer;
+return newBuffer;
+}
+
+@Override
+protected ByteBuffer allocateDirect(int initialCapacity)
+{
+return bufferPool.getAtLeast(initialCapacity, BufferType.OFF_HEAP);
+}
+
+@Override
+protected void freeDirect(ByteBuffer buffer)
+{
+// noop
+// buffer is put back into the pool by deallocate()
+}
+
+@Override
public void deallocate()
{
+super.deallocate();
if (wrapped != null)
bufferPool.put(wrapped);
}
diff --git a/src/java/org/apache/cassandra/net/GlobalBufferPoolAllocator.java
b/src/java/org/apache/cassandra/net/GlobalBufferPoolAllocator.java
index d368642..16fd5c6 100644
--- a/src/java/org/apache/cassandra/net/GlobalBufferPoolAllocator.java
+++ b/src/java/org/apache/cassandra/net/GlobalBufferPoolAllocator.java
@@ -36,6 +36,6 @@ public class GlobalBufferPoolAllocator extends
BufferPoolAllocator
static ByteBuf wrap(ByteBuffer buffer)
{
-return new Wrapped(instance, buffer);
+return new Wrapped(instance, buffer, buffer.capacity());
[jira] [Commented] (CASSANDRA-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326493#comment-17326493
]
Berenguer Blasi commented on CASSANDRA-16524:
-
So we cleared these doubts with [~blerer] on Slack. {{allocateDirect()}} being
overridden is the key here. Upon resizing it gets called by Netty and that will
prevent going over the threshold. That also makes current tests already have
that check implicit.
+1
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> 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:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException:
> writerIndex(8560) + minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAlloc
[jira] [Commented] (CASSANDRA-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326483#comment-17326483
]
Benjamin Lerer commented on CASSANDRA-16524:
Sorry, [~bereng], I missed your comment.
When {{Wrapped.capacity(int newCapacity)}} is called it calls
{{super.capacity(int newCapacity)}} that call back {{Wrapped.allocateDirect}}
that take care of using the BufferPool instead of allocating the buffer itself.
I checked the test and they trigger that path before checking that the changes
have updated correctly the {{BufferPool}}.
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> 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:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.net.ssl.SSLException: java.lang
[jira] [Updated] (CASSANDRA-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-16619: -- Source Control Link: https://github.com/apache/cassandra/pull/976 > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 10m > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16601:
--
Status: Ready to Commit (was: Review In Progress)
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {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-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326432#comment-17326432
]
Benjamin Lerer commented on CASSANDRA-16524:
The patch has been approved by [~e.dimitrova] and [~jasonstack]. CI looks good.
I will fix 1 formatting issue and rename the test class as suggested by
[~e.dimitrova] and commit.
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> 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:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException:
> writerIndex(8560) + minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.ssl
[jira] [Updated] (CASSANDRA-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16524:
---
Status: Ready to Commit (was: Review In Progress)
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> 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:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException:
> writerIndex(8560) + minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.ssl.OpenSslKeyMaterialManager.setKeyMaterial(OpenSslKeyMaterialManager.java:115)
> at
> io.netty.handler.ssl.OpenSslKeyMaterialManager.setKeyMaterialServerSide(OpenSslKeyMaterialM
[jira] [Updated] (CASSANDRA-15669) LeveledCompactionStrategy compact last level throw an ArrayIndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/CASSANDRA-15669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15669: Reviewers: Marcus Eriksson > LeveledCompactionStrategy compact last level throw an > ArrayIndexOutOfBoundsException > > > Key: CASSANDRA-15669 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15669 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: sunhaihong >Assignee: Alexey Zotov >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: cfs_compaction_info.png, error_info.png > > Time Spent: 50m > Remaining Estimate: 0h > > Cassandra will throw an ArrayIndexOutOfBoundsException when compact last > level. > My test is as follows： > # Create a table with LeveledCompactionStrategy and its params are > 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', > 'min_threshold': '4', 'sstable_size_in_mb': '2'（fanout_size and > sstable_size_in_mb are too small just to make it easier to reproduce the > problem）; > # Insert data into the table by stress; > # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 > sstables(this level score bigger than 1.001) > ERROR [CompactionExecutor:4] 2020-03-28 08:59:00,990 CassandraDaemon.java:442 > - Exception in thread Thread[CompactionExecutor:4,1,main] > java.lang.ArrayIndexOutOfBoundsException: 9 > at > org.apache.cassandra.db.compaction.LeveledManifest.getLevel(LeveledManifest.java:814) > at > org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:746) > at > org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:398) > at > org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:131) > at > org.apache.cassandra.db.compaction.CompactionStrategyHolder.lambda$getBackgroundTaskSuppliers$0(CompactionStrategyHolder.java:109) > at > org.apache.cassandra.db.compaction.AbstractStrategyHolder$TaskSupplier.getTask(AbstractStrategyHolder.java:66) > at > org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:214) > at > org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:289) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) > at java.util.concurrent.FutureTask.run(FutureTask.java) > 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) > I tested it on cassandra version 3.11.3 & 4.0-alpha3. The exception all > happened. > once it triggers, level1- leveln compaction no longer works, level0 is still > valid > -- 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-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326337#comment-17326337
]
Berenguer Blasi edited comment on CASSANDRA-16524 at 4/21/21, 9:08 AM:
---
If I followed the code correctly I _think_ we're not checking, neither is
Netty, for {{BuffePool.memoryUsageThreshold}}. In this case that'd be
{{NETWORKING_MEMORY_USAGE_THRESHOLD}} coming from
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/memory/BufferPools.java#L45].
That is being honored in reads i.e. but I think it'd be nice to do the same on
resizing. At least I would add a unit test that tries to violate the buffer
pool's memory threshold as future proofing.
was (Author: bereng):
If I followed the code correctly I _think_ we're not checking, neither is
Netty, for {{BuffePool.memoryUsageThreshold}}. In this case that'd be
{{NETWORKING_MEMORY_USAGE_THRESHOLD}} coming from
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/memory/BufferPools.java#L45].
That is being honored in reads i.e. but I think it's be nice to do the same on
resizing. At least I would add a unit test that tries to violate the buffer
pool's memory threshold as future proofing.
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> 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.fireChannelRea
[jira] [Comment Edited] (CASSANDRA-16614) Flaky test_pending_range
[
https://issues.apache.org/jira/browse/CASSANDRA-16614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17325608#comment-17325608
]
Berenguer Blasi edited comment on CASSANDRA-16614 at 4/21/21, 9:07 AM:
---
The window of opportunity for the test to check the node is Down/Moving on
{{nodetool}} is too small. It may have already gone to Down/Normal by the time
we check. So better check all nodes saw the node moving in the logs instead.
Logs of failed run
[here|https://nightlies.apache.org/cassandra/trunk/Cassandra-trunk-dtest-large-novnode/148/Cassandra-trunk-dtest-large-novnode/label=cassandra-dtest-large,split=3/].
was (Author: bereng):
The window of opportunity for the test to check the node is Down/Moving is too
small. It may have already gone to Down/Normal by the time we check. So better
check all nodes saw the node moving in the logs instead.
Logs of failed run
[here|https://nightlies.apache.org/cassandra/trunk/Cassandra-trunk-dtest-large-novnode/148/Cassandra-trunk-dtest-large-novnode/label=cassandra-dtest-large,split=3/].
> Flaky test_pending_range
>
>
> Key: CASSANDRA-16614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16614
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Flaky
> [test_pending_range|https://ci-cassandra.apache.org/job/Cassandra-trunk/445/testReport/junit/dtest-large-novnode.pending_range_test/TestPendingRangeMovements/test_pending_range/]
> {noformat}
> Error Message
> AssertionError: assert None is not None + where None = 0x7f29dfa83b80>('127\\.0\\.0\\.1.*?Down.*?Moving', '\nDatacenter:
> datacenter1\n==\nAddress RackStatus State Load
> Owns ... rack1 Up Normal 90.86 KiB
> 40.00% 5534023222112865484 \n\n\n ') +
>where = re.search
> {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-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326337#comment-17326337
]
Berenguer Blasi commented on CASSANDRA-16524:
-
If I followed the code correctly I _think_ we're not checking, neither is
Netty, for {{BuffePool.memoryUsageThreshold}}. In this case that'd be
{{NETWORKING_MEMORY_USAGE_THRESHOLD}} coming from
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/memory/BufferPools.java#L45].
That is being honored in reads but I think it's be nice to do the same on
resizing. At least I would add a unit test that tries to violate the buffer
pool's memory threshold as future proofing.
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> 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:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(Fa
[jira] [Comment Edited] (CASSANDRA-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326337#comment-17326337
]
Berenguer Blasi edited comment on CASSANDRA-16524 at 4/21/21, 7:53 AM:
---
If I followed the code correctly I _think_ we're not checking, neither is
Netty, for {{BuffePool.memoryUsageThreshold}}. In this case that'd be
{{NETWORKING_MEMORY_USAGE_THRESHOLD}} coming from
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/memory/BufferPools.java#L45].
That is being honored in reads i.e. but I think it's be nice to do the same on
resizing. At least I would add a unit test that tries to violate the buffer
pool's memory threshold as future proofing.
was (Author: bereng):
If I followed the code correctly I _think_ we're not checking, neither is
Netty, for {{BuffePool.memoryUsageThreshold}}. In this case that'd be
{{NETWORKING_MEMORY_USAGE_THRESHOLD}} coming from
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/memory/BufferPools.java#L45].
That is being honored in reads but I think it's be nice to do the same on
resizing. At least I would add a unit test that tries to violate the buffer
pool's memory threshold as future proofing.
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> 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(Def
