[jira] [Commented] (CASSANDRA-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024907#comment-17024907 ] Michael Semb Wever commented on CASSANDRA-14970: bq. I will commit the 2.2 - trunk changes, but leave the ticket 'in review' as I test the release script to cut the next releases. Committed as 06a36045fe3dcf07205e2649b2e5eaf0daff5164 > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png, > cassandra-2.1_14970_updated.patch > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit f1e94db34ccea660b320f9a571a998fd370e7f8c
Merge: 6449f40 d71625a
Author: Mick Semb Wever
AuthorDate: Tue Jan 28 07:57:30 2020 +0100
Merge branch 'cassandra-3.11' into trunk
build.xml | 88 +-
doc/source/development/dependencies.rst| 1 -
doc/source/development/release_process.rst | 26 +
3 files changed, 40 insertions(+), 75 deletions(-)
diff --cc build.xml
index 3af3163,7deef1e..cad8ca4
--- a/build.xml
+++ b/build.xml
@@@ -781,25 -667,26 +802,15 @@@
-
- https://cassandra.apache.org;
-name="Apache Cassandra">
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
- https://cassandra.apache.org;
- name="Apache Cassandra">
-
-
-
@@@ -1180,13 -1098,6 +1191,11 @@@
-
+
+
+
+
@@@ -2247,19 -2108,16 +2254,6 @@@
file="${build.dir}/${final.name}-parent.pom"
packaging="pom"/>
-
-
-
-
-
-
-
-
--
@@@ -2280,19 -2139,16 +2274,6 @@@
file="${build.dir}/${final.name}-parent.pom"
packaging="pom"/>
-
-
-
-
-
-
-
-
--
diff --cc doc/source/development/dependencies.rst
index 7d230d3,000..6dd1cc4
mode 100644,00..100644
--- a/doc/source/development/dependencies.rst
+++ b/doc/source/development/dependencies.rst
@@@ -1,54 -1,0 +1,53 @@@
+.. Licensed to the Apache Software Foundation (ASF) under one
+.. or more contributor license agreements. See the NOTICE file
+.. distributed with this work for additional information
+.. regarding copyright ownership. The ASF licenses this file
+.. to you under the Apache License, Version 2.0 (the
+.. "License"); you may not use this file except in compliance
+.. with the License. You may obtain a copy of the License at
+..
+.. http://www.apache.org/licenses/LICENSE-2.0
+..
+.. Unless required by applicable law or agreed to in writing, software
+.. distributed under the License is distributed on an "AS IS" BASIS,
+.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+.. See the License for the specific language governing permissions and
+.. limitations under the License.
+
+Dependency Management
+*
+
+Managing libraries for Cassandra is a bit less straight forward compared to
other projects, as the build process is based on ant, maven and manually
managed jars. Make sure to follow the steps below carefully and pay attention
to any emerging issues in the :doc:`ci` and reported related issues on Jira/ML,
in case of any project dependency changes.
+
+As Cassandra is an Apache product, all included libraries must follow
Apache's `software license requirements
`_.
+
+Required steps to add or update libraries
+=
+
+* Add or replace jar file in ``lib`` directory
+* Add or update ``lib/license`` files
+* Update dependencies in ``build.xml``
+
+ * Add to ``parent-pom`` with correct version
+ * Add to ``all-pom`` if simple Cassandra dependency (see below)
+
+
+POM file types
+==
+
+* **parent-pom** - contains all dependencies with the respective version. All
other poms will refer to the artifacts with specified versions listed here.
+* **build-deps-pom(-sources)** + **coverage-deps-pom** - used by ``ant
build`` compile target. Listed dependenices will be resolved and copied to
``build/lib/{jar,sources}`` by executing the ``maven-ant-tasks-retrieve-build``
target. This should contain libraries that are required for build tools
(grammar, docs, instrumentation), but are not shipped as part of the Cassandra
distribution.
+* **test-deps-pom** - refered by ``maven-ant-tasks-retrieve-test`` to
retrieve and save dependencies to ``build/test/lib``. Exclusively used during
JUnit test execution.
+* **all-pom** - pom for `cassandra-all.jar
`_ that
can be installed or deployed to public maven repos via ``ant publish``
- * **dist-pom** - pom for tarball distribution (cassandra-{bin,src}.tar.gz)
created by ``ant artifacts``. Should be left as is, but needed for installing
or deploying releases.
+
+
+Troubleshooting and conflict resolution
+===
+
+Here are some useful commands that may help you out resolving
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d71625a42ec7c29c5e9446bfa4c37719356193f0 Merge: 7819eb9 5508fec Author: Mick Semb Wever AuthorDate: Tue Jan 28 07:56:03 2020 +0100 Merge branch 'cassandra-3.0' into cassandra-3.11 build.xml | 88 +++ 1 file changed, 37 insertions(+), 51 deletions(-) diff --cc build.xml index 213ebb8,98c22a5..7deef1e --- a/build.xml +++ b/build.xml @@@ -660,22 -627,17 +681,12 @@@ - - https://cassandra.apache.org; -name="Apache Cassandra"> - - - + + + + + - https://cassandra.apache.org; - name="Apache Cassandra"> - - - - 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 (7819eb9 -> d71625a)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 7819eb9 Merge branch 'cassandra-3.0' into cassandra-3.11 new 06a3604 Source and build artifacts are published with sha512 checksums new 5508fec Merge branch 'cassandra-2.2' into cassandra-3.0 new d71625a Merge branch 'cassandra-3.0' into cassandra-3.11 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: build.xml | 88 +++ 1 file changed, 37 insertions(+), 51 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-2.2 updated: Source and build artifacts are published with sha512 checksums
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-2.2
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-2.2 by this push:
new 06a3604 Source and build artifacts are published with sha512 checksums
06a3604 is described below
commit 06a36045fe3dcf07205e2649b2e5eaf0daff5164
Author: Mick Semb Wever
AuthorDate: Wed Nov 13 14:32:30 2019 +0100
Source and build artifacts are published with sha512 checksums
patch by Mick Semb Wever; reviewed by Michael Shuler for CASSANDRA-14970
---
build.xml | 90 +++
1 file changed, 39 insertions(+), 51 deletions(-)
diff --git a/build.xml b/build.xml
index c307e26..a55709d 100644
--- a/build.xml
+++ b/build.xml
@@ -305,7 +305,7 @@
-
+
@@ -313,7 +313,25 @@
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -336,6 +354,9 @@
name="Apache Cassandra"
inceptionYear="2009"
description="The Apache Cassandra Project develops a
highly scalable second-generation distributed database, bringing together
Dynamo's fully distributed design and Bigtable's ColumnFamily-based data
model.">
+
+
+
https://www.apache.org/licenses/LICENSE-2.0.txt"/>
@@ -643,16 +664,6 @@
- https://cassandra.apache.org;
-name="Apache Cassandra">
-
-
-
@@ -1104,8 +1115,7 @@
-
+
@@ -1157,23 +1167,22 @@
-
-
-
+
-
+
+
-
+
-
+
+
+
+
@@ -1182,7 +1191,6 @@
-
@@ -2036,7 +2044,7 @@
@@ -2044,19 +2052,6 @@
file="${build.dir}/${final.name}-parent.pom"
packaging="pom"/>
-
-
-
-
-
@@ -2097,19 +2092,6 @@
-
-
-
-
-
+
@@ -2139,5 +2122,10 @@
+
+
+
+
+
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (b80e146 -> 5508fec)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from b80e146 Merge branch 'cassandra-2.2' into cassandra-3.0 new 06a3604 Source and build artifacts are published with sha512 checksums new 5508fec Merge branch 'cassandra-2.2' into cassandra-3.0 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: build.xml | 90 +++ 1 file changed, 38 insertions(+), 52 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (6449f40 -> f1e94db)
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 6449f40 Update NEWS for CASSANDRA-15257 new 06a3604 Source and build artifacts are published with sha512 checksums new 5508fec Merge branch 'cassandra-2.2' into cassandra-3.0 new d71625a Merge branch 'cassandra-3.0' into cassandra-3.11 new f1e94db Merge branch 'cassandra-3.11' into trunk The 4 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: build.xml | 88 +- doc/source/development/dependencies.rst| 1 - doc/source/development/release_process.rst | 26 + 3 files changed, 40 insertions(+), 75 deletions(-) - 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-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 5508fecf54a521792fa78345ad04c83de5ae3a82 Merge: b80e146 06a3604 Author: Mick Semb Wever AuthorDate: Tue Jan 28 07:52:50 2020 +0100 Merge branch 'cassandra-2.2' into cassandra-3.0 build.xml | 90 +++ 1 file changed, 38 insertions(+), 52 deletions(-) diff --cc build.xml index e543316,a55709d..98c22a5 --- a/build.xml +++ b/build.xml @@@ -617,17 -663,7 +638,6 @@@ - - https://cassandra.apache.org; - name="Apache Cassandra"> - - - - @@@ -1057,8 -1115,7 +1067,6 @@@ - - @@@ -2039,28 -2044,15 +2045,15 @@@ - + - - - - - - + - - + - - - - - + + + + + + + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-14970: --- Reviewers: Michael Shuler, Michael Semb Wever (was: Michael Semb Wever, Michael Shuler) Michael Shuler, Michael Semb Wever (was: Michael Shuler) Status: Review In Progress (was: Patch Available) > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png, > cassandra-2.1_14970_updated.patch > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-14970: --- Test and Documentation Plan: `ant artifacts` and cutting 4.0-alpha3 Status: Patch Available (was: In Progress) > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png, > cassandra-2.1_14970_updated.patch > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024898#comment-17024898 ] Michael Semb Wever commented on CASSANDRA-14970: Thanks [~mshuler]. I will commit the 2.2 - trunk changes, but leave the ticket 'in review' as I test the release script to cut the next releases. > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png, > cassandra-2.1_14970_updated.patch > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-15470) Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-15470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024885#comment-17024885
]
Jordan West commented on CASSANDRA-15470:
-
Thanks Dinesh. I like the improvements to {{ByteUnit}}. I agree that a more
wholesale review of {{DatabaseDescriptor}} would be good but is best saved for
a separate ticket and at a different time in the release cycle.
> Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB
> & Bytes
> -
>
> Key: CASSANDRA-15470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15470
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jordan West
>Assignee: Mallika Kulkarni
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DatabaseDescriptor}} has several functions that convert between user
> supplied sizes in KB/MB and bytes. These are implemented without much
> consistency and, while unlikely, several have the potential to overflow since
> validation on the input is missing. Meanwhile, some widen the number to a
> long correctly. Options include: widening in all places or simply doing
> better validation on start up — currently only the lower bound of the valid
> range is checked for many of these fields.
> List of Affected {{DatabaseDescriptor}} Methods:
> * {{getColumnIndexSize}}
> * {{getColumnIndexCacheSize}}
> * {{getBatchSizeWarnThreshold}}
> * {{getNativeTransportFrameBlockSize}}
> * {{getRepairSessionSpaceInMegabytes}}
> * {{getNativeTransportMaxFrameSize}}
--
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-15470) Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-15470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024885#comment-17024885
]
Jordan West edited comment on CASSANDRA-15470 at 1/28/20 5:59 AM:
--
Thanks [~djoshi]. I like the improvements to {{ByteUnit}}. I agree that a more
wholesale review of {{DatabaseDescriptor}} would be good but is best saved for
a separate ticket and at a different time in the release cycle.
+1
was (Author: jrwest):
Thanks [~djoshi]. I like the improvements to {{ByteUnit}}. I agree that a more
wholesale review of {{DatabaseDescriptor}} would be good but is best saved for
a separate ticket and at a different time in the release cycle.
> Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB
> & Bytes
> -
>
> Key: CASSANDRA-15470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15470
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jordan West
>Assignee: Mallika Kulkarni
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DatabaseDescriptor}} has several functions that convert between user
> supplied sizes in KB/MB and bytes. These are implemented without much
> consistency and, while unlikely, several have the potential to overflow since
> validation on the input is missing. Meanwhile, some widen the number to a
> long correctly. Options include: widening in all places or simply doing
> better validation on start up — currently only the lower bound of the valid
> range is checked for many of these fields.
> List of Affected {{DatabaseDescriptor}} Methods:
> * {{getColumnIndexSize}}
> * {{getColumnIndexCacheSize}}
> * {{getBatchSizeWarnThreshold}}
> * {{getNativeTransportFrameBlockSize}}
> * {{getRepairSessionSpaceInMegabytes}}
> * {{getNativeTransportMaxFrameSize}}
--
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-15469) IndexInfo/ColumnIndex Refactors & Cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-15469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024887#comment-17024887 ] Jordan West commented on CASSANDRA-15469: - Pushed an update to the branch with the discussed changes > IndexInfo/ColumnIndex Refactors & Cleanup > - > > Key: CASSANDRA-15469 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15469 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Changes determined by audit of IndexInfo and ColumnIndex changes for > Cassandra 4.0 -- 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-15470) Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-15470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024885#comment-17024885
]
Jordan West edited comment on CASSANDRA-15470 at 1/28/20 5:59 AM:
--
Thanks [~djoshi]. I like the improvements to {{ByteUnit}}. I agree that a more
wholesale review of {{DatabaseDescriptor}} would be good but is best saved for
a separate ticket and at a different time in the release cycle.
was (Author: jrwest):
Thanks Dinesh. I like the improvements to {{ByteUnit}}. I agree that a more
wholesale review of {{DatabaseDescriptor}} would be good but is best saved for
a separate ticket and at a different time in the release cycle.
> Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB
> & Bytes
> -
>
> Key: CASSANDRA-15470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15470
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jordan West
>Assignee: Mallika Kulkarni
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DatabaseDescriptor}} has several functions that convert between user
> supplied sizes in KB/MB and bytes. These are implemented without much
> consistency and, while unlikely, several have the potential to overflow since
> validation on the input is missing. Meanwhile, some widen the number to a
> long correctly. Options include: widening in all places or simply doing
> better validation on start up — currently only the lower bound of the valid
> range is checked for many of these fields.
> List of Affected {{DatabaseDescriptor}} Methods:
> * {{getColumnIndexSize}}
> * {{getColumnIndexCacheSize}}
> * {{getBatchSizeWarnThreshold}}
> * {{getNativeTransportFrameBlockSize}}
> * {{getRepairSessionSpaceInMegabytes}}
> * {{getNativeTransportMaxFrameSize}}
--
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-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankitha updated CASSANDRA-15529:
Description:
Hello Team,
For the background of this problem, kindly refer this ticket
https://issues.apache.org/jira/browse/CASSANDRA-15263
++
It was proposed that after the upgrade of the cluster from 2.1.16 to 3.11.4, we
should no longer be seeing any type of exceptions (WARN/ERROR).
But even after a month of upgrade we still see the below exceptions
{code:java}
WARN [ReadStage-231] 2020-01-23 02:29:11,137
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-231,5,main]: {}
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
[apache-cassandra-3.11.4.jar:3.11.4]
{code}
*and* **
{code:java}
WARN [MutationStage-36] 2020-01-21 19:31:03,343
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[MutationStage-36,5,main]: {}
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
[apache-cassandra-3.11.4.jar:3.11.4] .{code}
*Problem:*
If one of the node goes down, and we try to bring it up, the node hangs at a
stage of reading Key-cache. Sometimes the node comes up after a long period of
pause with the above *Mutation-stage* warnings. Other times , the node does not
come up and we have to manually clear the Key-cache to bring up the node.
Also,once the node is up we see lot of above *Read-Stage* warnings.
In some cases like below , gossip is shutting down and when trying to bring up
the node it is getting stuck:
{code:java}
[StorageServiceShutdownHook] 2020-01-24 02:19:30,586 HintsService.java:209 -
Paused hints dispatch
INFO [HintsDispatcher:14410] 2020-01-24 02:19:30,593
HintsDispatchExecutor.java:289 - Finished hinted handoff of file
594f065a-3134-4a39-b00d-b87b0e4625ff-1579831570632-1.hints to endpoint
/10.177.56.125: 594f065a-3134-4a39-b00d-b87b0e4625ff, partially
INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,623 Server.java:176 -
Stop listening for CQL clients
INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,624 Gossiper.java:1551 -
Announcing shutdown
INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,625
StorageService.java:2327 - Node ont-dce-cass-sal05-priv/10.103.56.25 state jump
to shutdown
INFO [HintsDispatcher:14411] 2020-01-24 02:19:30,682
HintsDispatchExecutor.java:289 - Finished hinted handoff of file
b224b069-5b16-42f9-971b-6ae8f8bbcf23-1579829423673-1.hints to endpoint
/10.177.56.116: b224b069-5b16-42f9-971b-6ae8f8bbcf23, partially
INFO [StorageServiceShutdownHook] 2020-01-24 02:19:32,629
MessagingService.java:981 - Waiting for messaging service to quiesce
INFO [ACCEPT-ont-dce-cass-sal05-priv/10.103.56.25] 2020-01-24 02:19:32,631
MessagingService.java:1336 - MessagingService has terminated the accept() thread
INFO [main] 2020-01-24 02:20:06,214 YamlConfigurationLoader.java:89 -
Configuration location:
file:/opt/cass/apache-cassandra-3.11.4/conf/cassandra.yamlWARN
[MutationStage-12] 2020-01-24 02:24:57,608
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[MutationStage-12,5,main]: {}
java.lang.AssertionError: null at
org.apache.cassandra.utils.memory.AbstractAllocator.clone(AbstractAllocator.java:35)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.RangeTombstoneList.clone(RangeTombstoneList.java:130)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.RangeTombstoneList.copy(RangeTombstoneList.java:119)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.MutableDeletionInfo.copy(MutableDeletionInfo.java:90)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.MutableDeletionInfo.copy(MutableDeletionInfo.java:33)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(AtomicBTreePartition.java:141)
~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.db.Memtable.put(Memtable.java:282)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1352)
~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:626)
~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:470)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
[jira] [Comment Edited] (CASSANDRA-15519) Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at runtime
[
https://issues.apache.org/jira/browse/CASSANDRA-15519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024874#comment-17024874
]
Jordan West edited comment on CASSANDRA-15519 at 1/28/20 5:20 AM:
--
[~clohfink] and I spoke off JIRA and moving things into {{StorageServiceMBean}}
works well and cleans things up nicely as an added bonus. Branch updated.
was (Author: jrwest):
[~clohfink] and I spoke offline and moving things into {{StorageServiceMBean}}
works well and cleans things up nicely as an added bonus. Branch updated.
> Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at
> runtime
> -
>
> Key: CASSANDRA-15519
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15519
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Messaging/Client
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-15013 added configurable global and per endpoint limits on the
> number of in flight requests, measured in bytes. During times when the
> cluster is overloaded, it can be useful to change this setting without having
> to restart the Cassandra process. Changing the limits should affect all
> existing and new connections.
--
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-15519) Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at runtime
[
https://issues.apache.org/jira/browse/CASSANDRA-15519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024874#comment-17024874
]
Jordan West commented on CASSANDRA-15519:
-
[~clohfink] and I spoke offline and moving things into {{StorageServiceMBean}}
works well and cleans things up nicely as an added bonus. Branch updated.
> Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at
> runtime
> -
>
> Key: CASSANDRA-15519
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15519
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Messaging/Client
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-15013 added configurable global and per endpoint limits on the
> number of in flight requests, measured in bytes. During times when the
> cluster is overloaded, it can be useful to change this setting without having
> to restart the Cassandra process. Changing the limits should affect all
> existing and new connections.
--
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-15505) Add message interceptors to in-jvm dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-15505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024870#comment-17024870
]
Yifan Cai commented on CASSANDRA-15505:
---
{{.messagesMatching(_lambda_)}} is the new filter that one can have general
and custom matching logic on the message info. It is a more general matching
form of the existing {{.from(int...)}}, {{.to(int...)}} and {{.verbs(verb...)}}
+1 LGTM
> Add message interceptors to in-jvm dtests
> -
>
> Key: CASSANDRA-15505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15505
> Project: Cassandra
> Issue Type: New Feature
> Components: Test/dtest
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Currently we only have means to filter messages in in-jvm tests. We need a
> facility to intercept and modify the messages between nodes for testing
> purposes.
--
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-14587) TrueDiskSpaceUsed overcounts snapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-14587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024846#comment-17024846 ] Ekaterina Dimitrova commented on CASSANDRA-14587: - After checking the initial ticket where the command was implemented and digging into the code itself, I don't see a bug. The command is implemented as per CASSANDRA-5742, just to go through all snapshots and sum TrueDiskSize. There are two options, either to change It or to improve the documentation so the output is understood without ambiguities. [~jjordan] any thoughts? > TrueDiskSpaceUsed overcounts snapshots > -- > > Key: CASSANDRA-14587 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14587 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool > Environment: Debian 8 > Cassandra 3.11.2 >Reporter: Elliott Sims >Assignee: Ekaterina Dimitrova >Priority: Low > > Running 'nodetool listsnapshots' seems to overcount "TrueDiskSpaceUsed" under > some circumstances. Specifically when there's a large number of snapshots. > I suspect that it's not deduplicating space used when multiple snapshots > share sstables that are not part of the current table. > Results of "nodetool listsnapshots": > Total TrueDiskSpaceUsed: 396.11 MiB > Results of "du -hcs" on the table's directory: > 18M total > This is 50+ snapshots (every minute) run with "-t -sf > --column-family " > The results of a "du -hcs -L "TrueDiskSpaceUsed" > I have only tested against 3.11.2, but have no reason to believe it's unique > to that version or even 3.x. -- 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-15257) Remove joda time from dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-15257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024829#comment-17024829
]
Brandon Williams commented on CASSANDRA-15257:
--
The intention was to eliminate the dependency, since joda time is not really
maintained now that Java 8+ has support for this, if not entirely compatible.
I've updated NEWS.txt in 6449f400ce599d34ab4b97be4ca59ad9b9a222c7 to reflect
this.
> Remove joda time from dependencies
> --
>
> Key: CASSANDRA-15257
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15257
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Boris Tsirkin
>Assignee: Boris Tsirkin
>Priority: Low
> Labels: pull-request-available
> Fix For: 4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Joda time is not supported anymore
> {quote}
> Note that Joda-Time is considered to be a largely “finished” project. No
> major enhancements are planned. If using Java SE 8, please migrate to
> {{java.time}} (JSR-310).
> {quote}
> See: https://www.joda.org/joda-time/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Update NEWS for CASSANDRA-15257
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 The following commit(s) were added to refs/heads/trunk by this push: new 6449f40 Update NEWS for CASSANDRA-15257 6449f40 is described below commit 6449f400ce599d34ab4b97be4ca59ad9b9a222c7 Author: Brandon Williams AuthorDate: Mon Jan 27 20:27:21 2020 -0600 Update NEWS for CASSANDRA-15257 --- NEWS.txt | 4 1 file changed, 4 insertions(+) diff --git a/NEWS.txt b/NEWS.txt index e51203f..9c6b43f 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -223,6 +223,10 @@ Upgrading their clusters or otherwise synchronize their clocks, and that clocks are mostly in sync, since this is a requirement for general correctness of last write wins. +- CASSANDRA-15257 removed the joda time dependency. Any time formats + passed will now need to conform to java.time.format.DateTimeFormatter. + Most notably, days and months must be two digits, and years exceeding + four digits need to be prefixed with a plus or minus sign. Materialized Views - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15257) Remove joda time from dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-15257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024822#comment-17024822
]
Dinesh Joshi commented on CASSANDRA-15257:
--
Hi [~brandon.williams], this patch breaks {{TestCqlsh::test_datetime_values}}.
CI run
[here|https://circleci.com/gh/dineshjoshi/cassandra/1565#tests/containers/40].
Here are the errors.
{noformat}
E AssertionError: Failed to execute cqlsh: :13:InvalidRequest:
Error from server: code=2200 [Invalid query] message="Unable to coerce
'1582-1-1' to a formatted date (long)"
E :15:InvalidRequest: Error from server: code=2200 [Invalid
query] message="Unable to coerce '0-1-1' to a formatted date (long)"
E :17:InvalidRequest: Error from server: code=2200 [Invalid
query] message="Unable to coerce '1-1-1' to a formatted date (long)"
E :19:InvalidRequest: Error from server: code=2200 [Invalid
query] message="Unable to coerce '-1-1' to a formatted date (long)"
E :21:InvalidRequest: Error from server: code=2200 [Invalid
query] message="Unable to coerce '1-1-1' to a formatted date (long)"
{noformat}
This test passes at commit 9a280516ca8b9e730ae0648e5e29ee6280605132 and breaks
on trunk (2f2b2ae607b2531836c805da913ca2e545162275).
I am not sure if the intention of this ticket was to simply eliminate the Joda
Time dependency while maintaining backward compatibility. If that is the
intention, we should fix the server code. If not, we need to document it in
NEWS.txt so that operators are not surprised.
> Remove joda time from dependencies
> --
>
> Key: CASSANDRA-15257
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15257
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Boris Tsirkin
>Assignee: Boris Tsirkin
>Priority: Low
> Labels: pull-request-available
> Fix For: 4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Joda time is not supported anymore
> {quote}
> Note that Joda-Time is considered to be a largely “finished” project. No
> major enhancements are planned. If using Java SE 8, please migrate to
> {{java.time}} (JSR-310).
> {quote}
> See: https://www.joda.org/joda-time/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022679#comment-17022679 ] Dinesh Joshi edited comment on CASSANDRA-10190 at 1/28/20 1:45 AM: --- I have rebased and squashed, [~ptbannister]'s original branch into my repo [here|https://github.com/dineshjoshi/cassandra/tree/10190-trunk-review]. Let's use this branch going forward. I also ran [circleci|https://circleci.com/workflow-run/53b5f86f-2a97-4ce8-8269-9fab522f9406] jobs. There are about 5 tests that are failing right now. The following tests pass locally but fail on CircleCI (let's debug these later) – - test_writing_with_token_boundaries - test_datetime_values - test_remote_query The following tests fail locally and on CircleCI so I think these are genuine failures (let's focus on them right now) – - test_complex_schema - test_complex_data_types was (Author: djoshi3): I have rebased and squashed, [~ptbannister]'s original branch into my repo [here|https://github.com/dineshjoshi/cassandra/tree/10190-trunk-review]. Let's use this branch going forward. I also ran [circleci|https://circleci.com/workflow-run/53b5f86f-2a97-4ce8-8269-9fab522f9406] jobs. There are about 5 tests that are failing right now. The following tests pass locally but fail on CircleCI (let's debug these later) – - test_writing_with_token_boundaries - test_datetime_values - test_remote_query The following tests fail locally and on CircleCI so I think these are Genuine failures (let's focus on them right now) – - test_complex_schema - test_complex_data_types > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Fix For: 4.0, 4.0-alpha > > Attachments: > 0001-Fix-issues-from-version-specific-logic-commit.patch, > 0001-Update-six-to-1.12.0.patch, > 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch, > coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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-10190) Python 3 support for cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024803#comment-17024803
]
Dinesh Joshi edited comment on CASSANDRA-10190 at 1/28/20 1:44 AM:
---
I have pushed an update to my
[branch|https://github.com/dineshjoshi/cassandra/tree/10190-trunk-review] which
fixes {{test_complex_schema}} and {{test_complex_data_types}}. Turned out to be
a minor issue. I also ran into an issue with running cqlsh on the command line.
The code was trying to import {{six}} before it was included in the
{{PYTHONPATH}}.
Tests are running
[here|https://circleci.com/workflow-run/6ae89f2e-b357-48ac-b945-4bc2d9f78f30].
was (Author: djoshi3):
I have pushed an update to my
[branch|https://github.com/dineshjoshi/cassandra/tree/10190-trunk-review] which
fixes {{test_complex_schema}} and {{test_complex_data_types}}. Turned out to be
a minor issue. I also ran into an issue with running cqlsh on the command line.
The code was trying to import {{six}} before it was included in the
{{PYTHONPATH}}.
> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 4.0-alpha
>
> Attachments:
> 0001-Fix-issues-from-version-specific-logic-commit.patch,
> 0001-Update-six-to-1.12.0.patch,
> 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch,
> coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh.
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a
> .python-version containing "2.7". But it would be nice if cqlsh supported
> modern Python versions out of the box.
--
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-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-10190: - Status: Review In Progress (was: Changes Suggested) > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Fix For: 4.0, 4.0-alpha > > Attachments: > 0001-Fix-issues-from-version-specific-logic-commit.patch, > 0001-Update-six-to-1.12.0.patch, > 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch, > coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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-10190) Python 3 support for cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024803#comment-17024803
]
Dinesh Joshi commented on CASSANDRA-10190:
--
I have pushed an update to my
[branch|https://github.com/dineshjoshi/cassandra/tree/10190-trunk-review] which
fixes {{test_complex_schema}} and {{test_complex_data_types}}. Turned out to be
a minor issue. I also ran into an issue with running cqlsh on the command line.
The code was trying to import {{six}} before it was included in the
{{PYTHONPATH}}.
> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 4.0-alpha
>
> Attachments:
> 0001-Fix-issues-from-version-specific-logic-commit.patch,
> 0001-Update-six-to-1.12.0.patch,
> 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch,
> coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh.
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a
> .python-version containing "2.7". But it would be nice if cqlsh supported
> modern Python versions out of the box.
--
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-15508) Failing jvm dtest: FailingRepairTest.testFailingMessage
[
https://issues.apache.org/jira/browse/CASSANDRA-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024783#comment-17024783
]
David Capwell commented on CASSANDRA-15508:
---
Rebased against master and rewrote the j11 changes to match the new model; here
is the java 11 pipeline
https://app.circleci.com/github/dcapwell/cassandra/pipelines/af287bdf-41b3-4231-b1bf-095dc91803fa/workflows/bffb62c8-997c-4461-af4c-66b9f725528c
> Failing jvm dtest: FailingRepairTest.testFailingMessage
> ---
>
> Key: CASSANDRA-15508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15508
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Attachments: Screen Shot 2020-01-17 at 4.51.17 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems we can't run parameterized unit tests with {{ant testsome}}:
> {code}
> $ ant testsome
> -Dtest.name=org.apache.cassandra.distributed.test.FailingRepairTest
> -Dtest.methods=testFailingMessage
>
> [junit-timeout] Testcase:
> initializationError(org.junit.runner.manipulation.Filter):Caused an ERROR
> [junit-timeout] No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] java.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {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-15463) Fix in-jvm dtest java 11 compatibility
[ https://issues.apache.org/jira/browse/CASSANDRA-15463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-15463: Since Version: 4.0 Source Control Link: https://github.com/apache/cassandra/commit/1f7e3c2835c79363025a01a8470ee85d17457cf8 Resolution: Fixed Status: Resolved (was: Ready to Commit) Comitted to trunk as [1f7e3c2835c79363025a01a8470ee85d17457cf8|https://github.com/apache/cassandra/commit/1f7e3c2835c79363025a01a8470ee85d17457cf8]. FailingRepairTest is still failing, but should be addressed in CASSANDRA-15508. > Fix in-jvm dtest java 11 compatibility > -- > > Key: CASSANDRA-15463 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15463 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0-alpha > > > The url classloader used by the in jvm dtests is not accessible by default in > java 11. -- 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-15508) Failing jvm dtest: FailingRepairTest.testFailingMessage
[
https://issues.apache.org/jira/browse/CASSANDRA-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024771#comment-17024771
]
David Capwell commented on CASSANDRA-15508:
---
CASSANDRA-15463 adds jvm dtests running on java 11, so get a merge conflict
with this. If that goes in first, will need to rebase trunk.
> Failing jvm dtest: FailingRepairTest.testFailingMessage
> ---
>
> Key: CASSANDRA-15508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15508
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Attachments: Screen Shot 2020-01-17 at 4.51.17 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems we can't run parameterized unit tests with {{ant testsome}}:
> {code}
> $ ant testsome
> -Dtest.name=org.apache.cassandra.distributed.test.FailingRepairTest
> -Dtest.methods=testFailingMessage
>
> [junit-timeout] Testcase:
> initializationError(org.junit.runner.manipulation.Filter):Caused an ERROR
> [junit-timeout] No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] java.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {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-15463) Fix in-jvm dtest java 11 compatibility
[ https://issues.apache.org/jira/browse/CASSANDRA-15463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-15463: Status: Ready to Commit (was: Review In Progress) > Fix in-jvm dtest java 11 compatibility > -- > > Key: CASSANDRA-15463 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15463 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0-alpha > > > The url classloader used by the in jvm dtests is not accessible by default in > java 11. -- 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: Fix in-jvm dtest java 11 compatibility
This is an automated email from the ASF dual-hosted git repository. bdeggleston 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 1f7e3c2 Fix in-jvm dtest java 11 compatibility 1f7e3c2 is described below commit 1f7e3c2835c79363025a01a8470ee85d17457cf8 Author: Blake Eggleston AuthorDate: Thu Dec 19 14:24:13 2019 -0800 Fix in-jvm dtest java 11 compatibility Patch by Blake Eggleston; Reviewed by Alex Petrov and David Capwell for CASSANDRA-15463 --- .circleci/config-2_1.yml | 17 .circleci/config-2_1.yml.high_res.patch| 16 ++- .circleci/config.yml | 46 + .circleci/config.yml.HIGHRES | 113 +++-- .circleci/config.yml.LOWRES| 49 + CHANGES.txt| 1 + build.xml | 1 + .../distributed/test/MessageForwardingTest.java| 4 +- 8 files changed, 204 insertions(+), 43 deletions(-) diff --git a/.circleci/config-2_1.yml b/.circleci/config-2_1.yml index ee0b914..99a0390 100644 --- a/.circleci/config-2_1.yml +++ b/.circleci/config-2_1.yml @@ -34,6 +34,12 @@ j11_par_executor: _par_executor #exec_resource_class: xlarge parallelism: 4 +j11_seq_executor: _seq_executor + executor: +name: java11-executor +#exec_resource_class: xlarge + parallelism: 1 # sequential, single container tests: no parallelism benefits + j8_with_dtests_jobs: _with_dtests_jobs jobs: - j8_build @@ -133,6 +139,9 @@ j11_with_dtests_jobs: _with_dtests_jobs - j11_unit_tests: requires: - start_j11_unit_tests +- j11_jvm_dtests: +requires: + - j11_build # Java 11 dtests (on request) - start_j11_dtests: type: approval @@ -264,6 +273,14 @@ jobs: - log_environment - run_parallel_junit_tests + j11_jvm_dtests: +<<: *j11_seq_executor +steps: + - attach_workspace: + at: /home/cassandra + - run_junit_tests: + target: test-jvm-dtest-forking + j8_jvm_upgrade_dtests: <<: *j8_seq_executor steps: diff --git a/.circleci/config-2_1.yml.high_res.patch b/.circleci/config-2_1.yml.high_res.patch index 083f3a5..4d5e9e1 100644 --- a/.circleci/config-2_1.yml.high_res.patch +++ b/.circleci/config-2_1.yml.high_res.patch @@ -1,22 +1,20 @@ -18,19c18,19 -< CCM_MAX_HEAP_SIZE: 1024M -< CCM_HEAP_NEWSIZE: 256M -> CCM_MAX_HEAP_SIZE: 2048M -> CCM_HEAP_NEWSIZE: 512M -24,25c24,25 +22,23c22,23 < #exec_resource_class: xlarge < parallelism: 4 --- > exec_resource_class: xlarge > parallelism: 100 -30c30 +28c28 < #exec_resource_class: xlarge --- > exec_resource_class: xlarge -36,37c36,37 +34,35c34,35 < #exec_resource_class: xlarge < parallelism: 4 --- > exec_resource_class: xlarge > parallelism: 100 +40c40 +< #exec_resource_class: xlarge +--- +> exec_resource_class: xlarge diff --git a/.circleci/config.yml b/.circleci/config.yml index 0a02e3a..d23d344 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -492,6 +492,49 @@ jobs: - CCM_HEAP_NEWSIZE: 256M - JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64 - JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64 + j11_jvm_dtests: +docker: +- image: spod/cassandra-testing-ubuntu1810-java11:20181210 +resource_class: medium +working_directory: ~/ +shell: /bin/bash -eo pipefail -l +parallelism: 1 +steps: +- attach_workspace: +at: /home/cassandra +- run: +name: Run Unit Tests (test-jvm-dtest-forking) +command: | + export PATH=$JAVA_HOME/bin:$PATH + time mv ~/cassandra /tmp + cd /tmp/cassandra + ant test-jvm-dtest-forking +no_output_timeout: 15m +- store_test_results: +path: /tmp/cassandra/build/test/output/ +- store_artifacts: +path: /tmp/cassandra/build/test/output +destination: junitxml +- store_artifacts: +path: /tmp/cassandra/build/test/logs +destination: logs +environment: +- ANT_HOME: /usr/share/ant +- LANG: en_US.UTF-8 +- KEEP_TEST_DIR: true +- DEFAULT_DIR: /home/cassandra/cassandra-dtest +- PYTHONIOENCODING: utf-8 +- PYTHONUNBUFFERED: true +- CASS_DRIVER_NO_EXTENSIONS: true +- CASS_DRIVER_NO_CYTHON: true +- CASSANDRA_SKIP_SYNC: true +- DTEST_REPO: git://github.com/apache/cassandra-dtest.git +- DTEST_BRANCH: master +- CCM_MAX_HEAP_SIZE: 1024M +- CCM_HEAP_NEWSIZE: 256M +- JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64 +- JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64 +- CASSANDRA_USE_JDK11: true j11_build: docker: - image: spod/cassandra-testing-ubuntu1810-java11:20181210 @@ -1169,6 +1212,9 @@
[jira] [Commented] (CASSANDRA-15470) Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-15470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024732#comment-17024732
]
Dinesh Joshi commented on CASSANDRA-15470:
--
Hi [~jrwest], I have made changes per your feedback.
{{testIndexedReaderRowDeletion}}, {{testIndexedReaderTombstone}} and
{{testIndexedReaderRT}} get the {{column_index_size_in_kb}}. Unfortunately get
getter, {{getColumnIndexSize}}, returns this in bytes while the setter
{{setColumnIndexSize}} accepts it in KB. This leads to a situation that we
cannot pass in the value returned from the getter into the setter. This issue
surfaced when we added the overflow checks. I think in the longer term we need
to fix this throughout the codebase but that is an exercise for another ticket.
> Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB
> & Bytes
> -
>
> Key: CASSANDRA-15470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15470
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jordan West
>Assignee: Mallika Kulkarni
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DatabaseDescriptor}} has several functions that convert between user
> supplied sizes in KB/MB and bytes. These are implemented without much
> consistency and, while unlikely, several have the potential to overflow since
> validation on the input is missing. Meanwhile, some widen the number to a
> long correctly. Options include: widening in all places or simply doing
> better validation on start up — currently only the lower bound of the valid
> range is checked for many of these fields.
> List of Affected {{DatabaseDescriptor}} Methods:
> * {{getColumnIndexSize}}
> * {{getColumnIndexCacheSize}}
> * {{getBatchSizeWarnThreshold}}
> * {{getNativeTransportFrameBlockSize}}
> * {{getRepairSessionSpaceInMegabytes}}
> * {{getNativeTransportMaxFrameSize}}
--
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-2848) Make the Client API support passing down timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-2848: - Test and Documentation Plan: unit test and CI Status: Patch Available (was: Open) > Make the Client API support passing down timeouts > - > > Key: CASSANDRA-2848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2848 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client, Messaging/Internode >Reporter: Chris Goffinet >Assignee: Yifan Cai >Priority: Low > Labels: protocolv5 > Fix For: 4.0-beta > > Attachments: 2848-trunk-v2.txt, 2848-trunk.txt > > > Having a max server RPC timeout is good for worst case, but many applications > that have middleware in front of Cassandra, might have higher timeout > requirements. In a fail fast environment, if my application starting at say > the front-end, only has 20ms to process a request, and it must connect to X > services down the stack, by the time it hits Cassandra, we might only have > 10ms. I propose we provide the ability to specify the timeout on each call we > do optionally. -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[
https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024728#comment-17024728
]
Michael Shuler commented on CASSANDRA-14970:
Patches above for 2.2, 3.0, 3.11, and trunk look good to me on {{ant
artifacts}} tests for each branch.
I did also try to build 2.1 and the build currently fails, due to the old http
URLs in build.xml and build.properties.default now being disabled. There was
someone on slack with the same problem, so I added a 2.1 backport patch to
CASSANDRA-15137. With that patch applied to the {{cassandra-2.1}} branch and
the 2.1 patch above on top, I did not get the desired .sha256 & .sha512 files
created when building the artifacts for some reason. That can probably be
worked on later, if needed.
> New releases must supply SHA-256 and/or SHA-512 checksums
> -
>
> Key: CASSANDRA-14970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14970
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Semb Wever
>Priority: Urgent
> Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0
>
> Attachments:
> 0001-Update-downloads-for-sha256-sha512-checksum-files.patch,
> 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch,
> ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png,
> cassandra-2.1_14970_updated.patch
>
>
> Release policy was updated around 9/2018 to state:
> "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT
> supply MD5 or SHA-1. Existing releases do not need to be changed."
> build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both.
> cassandra-builds/cassandra-release scripts need to be updated to work with
> the new checksum files.
> http://www.apache.org/dev/release-distribution#sigs-and-sums
--
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-15137) Switch http to https URLs in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024723#comment-17024723 ] Michael Shuler commented on CASSANDRA-15137: Adding 2.1 backport patch to ticket, since the build is broken after http URLs have been disabled. [^2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch] > Switch http to https URLs in build.xml > -- > > Key: CASSANDRA-15137 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15137 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Normal > Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0 > > Attachments: 0001-Switch-http-to-https-URLs-in-build.xml.patch, > 2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch > > > Switch to using https URLs wherever possible in build.xml. -- 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-15137) Switch http to https URLs in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15137: --- Attachment: 2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch > Switch http to https URLs in build.xml > -- > > Key: CASSANDRA-15137 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15137 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Normal > Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0 > > Attachments: 0001-Switch-http-to-https-URLs-in-build.xml.patch, > 2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch > > > Switch to using https URLs wherever possible in build.xml. -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14970: --- Attachment: cassandra-2.1_14970_updated.patch > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png, > cassandra-2.1_14970_updated.patch > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-15470) Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-15470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024712#comment-17024712
]
Jordan West commented on CASSANDRA-15470:
-
[~djoshi] moving the {{ByteUnit}} changes out to a separate ticket SGTM. Can
you say a bit more about what test failed and why? I missed that. Thanks.
> Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB
> & Bytes
> -
>
> Key: CASSANDRA-15470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15470
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jordan West
>Assignee: Mallika Kulkarni
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DatabaseDescriptor}} has several functions that convert between user
> supplied sizes in KB/MB and bytes. These are implemented without much
> consistency and, while unlikely, several have the potential to overflow since
> validation on the input is missing. Meanwhile, some widen the number to a
> long correctly. Options include: widening in all places or simply doing
> better validation on start up — currently only the lower bound of the valid
> range is checked for many of these fields.
> List of Affected {{DatabaseDescriptor}} Methods:
> * {{getColumnIndexSize}}
> * {{getColumnIndexCacheSize}}
> * {{getBatchSizeWarnThreshold}}
> * {{getNativeTransportFrameBlockSize}}
> * {{getRepairSessionSpaceInMegabytes}}
> * {{getNativeTransportMaxFrameSize}}
--
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-2848) Make the Client API support passing down timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-2848: Reviewers: Dinesh Joshi > Make the Client API support passing down timeouts > - > > Key: CASSANDRA-2848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2848 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client, Messaging/Internode >Reporter: Chris Goffinet >Assignee: Yifan Cai >Priority: Low > Labels: protocolv5 > Fix For: 4.0-beta > > Attachments: 2848-trunk-v2.txt, 2848-trunk.txt > > > Having a max server RPC timeout is good for worst case, but many applications > that have middleware in front of Cassandra, might have higher timeout > requirements. In a fail fast environment, if my application starting at say > the front-end, only has 20ms to process a request, and it must connect to X > services down the stack, by the time it hits Cassandra, we might only have > 10ms. I propose we provide the ability to specify the timeout on each call we > do optionally. -- 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-15524) Fix flakey test - org.apache.cassandra.distributed.test.MessageForwardingTest mutationsForwardedToAllReplicasTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15524:
--
Resolution: Duplicate
Status: Resolved (was: Open)
> Fix flakey test - org.apache.cassandra.distributed.test.MessageForwardingTest
> mutationsForwardedToAllReplicasTest
> -
>
> Key: CASSANDRA-15524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15524
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: /127.0.0.2 should have been randomized
> to forward messages
> at
> org.apache.cassandra.distributed.test.MessageForwardingTest.lambda$mutationsForwardedToAllReplicasTest$7(MessageForwardingTest.java:87)
> at java.base/java.util.HashMap.forEach(HashMap.java:1336)
> at
> org.apache.cassandra.distributed.test.MessageForwardingTest.mutationsForwardedToAllReplicasTest(MessageForwardingTest.java:87)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.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-15524) Fix flakey test - org.apache.cassandra.distributed.test.MessageForwardingTest mutationsForwardedToAllReplicasTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024695#comment-17024695
]
David Capwell commented on CASSANDRA-15524:
---
Turns out that CASSANDRA-15463 is attempting to fix this. I reviewed it but
forgot it was this test... Closing this as a duplicate.
> Fix flakey test - org.apache.cassandra.distributed.test.MessageForwardingTest
> mutationsForwardedToAllReplicasTest
> -
>
> Key: CASSANDRA-15524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15524
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: /127.0.0.2 should have been randomized
> to forward messages
> at
> org.apache.cassandra.distributed.test.MessageForwardingTest.lambda$mutationsForwardedToAllReplicasTest$7(MessageForwardingTest.java:87)
> at java.base/java.util.HashMap.forEach(HashMap.java:1336)
> at
> org.apache.cassandra.distributed.test.MessageForwardingTest.mutationsForwardedToAllReplicasTest(MessageForwardingTest.java:87)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.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-2848) Make the Client API support passing down timeouts
[
https://issues.apache.org/jira/browse/CASSANDRA-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024659#comment-17024659
]
Yifan Cai edited comment on CASSANDRA-2848 at 1/27/20 9:31 PM:
---
[Code|https://github.com/yifan-c/cassandra/tree/CASSANDRA-2848-per-request-timeout],
[PR|https://github.com/apache/cassandra/pull/432],
[Test|https://app.circleci.com/jobs/github/yifan-c/cassandra/207]
At high-level, this patch allows clients to set an optional timeout for each
query. If the timeout is present and it is valid to be applied, the coordinator
adjusts the waiting time and the expiration time of the internode messages are
adjusted accordingly.
The optional timeout has the following specifications:
* New flag & option added in V5 native protocol to allow specifying the
optional timeout.
* The timeout is in milliseconds and the valid range is (0, 2147483647), not
inclusive.
* Data type is Integer. Not using short because the max value of short is
32767, which may not satisfy all cases.
* Default value is Integer.MAX_VALUE
* The timeout value cannot exceeds the database configured one effectively.
** Perform Math.min between the optional timeout (defaults to
Integer.MAX_VALUE) and the configured one.
*Handling the optional timeout*
The server (coordinator) receives the request and deserializes message with the
QueryOptions. QueryState is then created with the computed timings, including
the timeout for this query. The query is processed and the coordinator waits
for the time duration according to the computed timeout in QueryState. The
expiration of the internode messages are adjusted according to the timeout in
QueryState, so that the message can be dropped properly if timeout.
QueryOptions contains all the options set by client. The values of the options
remains immutable.
QueryState stores all the server-side computed values. For example, it has the
resolved timeout for the query. QueryState is now truly one per query as an
outcome of patch CASSANDRA-14677.
{{CQLStatement}} gains a new method {{void resolveTimeout(QueryOptions options,
QueryState state);}} in order to compute the proper timeout for the query at
the start of query processing. The resolved timeout is stored in QueryState,
which is passed along to the code that 1) awaits for response and 2) generates
the internode messages. The method is implemented in the concrete CQL
statements and it is called at `QueryHandler#process`
*Read path*
* Single read: adjust the timeout and capped at `ReadRpcTimeout`
* Range read: adjust the timeout and capped at `RnageRpcTimeout`
* Blocking read repair: adjust the timeout of the repair mutation phase to the
remaining of the read timeout
*Write path*
* Counter mutation: adjust the timeout and capped at `CounterWriteRpcTimeout`
* Normal mutation: adjust the timeout and capped at `WriteRpcTimeout`
* CAS: adjust the timeout and capped at `WriteRpcTimeout`
** There is another timeout value to track the contention time
(CasContentionTimeout) during cas. This timeout remains unchanged.
* Batch
** Counter batch: see counter mutation
** CAS or normal: adjust the time and capped at `WriteRpcTimeout`
*Mix-versions compatibility*
The feature is available only in protocol V5.
*_Client-Server compatibility_*
| |Server V4|Server V5|
|Client V4|Good.|Good. The V4 client will not set the optional timeout. The V5
server uses the default value, Integer.MAX_VALUE|
|Client V5|Good. But the client acts just like a v4 one. |Good.|
_*Server-Server compatibility*_
| |Server V4 (Replica)|Server V5 (Replica)|
|Server V4 (Coordinator)|Good.|Good.|
|Server V5 (Coordinator)|Good. The V5 coordinator updates the expiration. The
V4 replica nodes honor it. |Good.|
*Integration with other components*
Full query logging: the optional timeout exists in QueryOptions. It is already
encoded into the log entry properly.
Audit logging: right now, a timed out query is already logged as
`REQUEST_FAILURE` with the exception message by the audit logger. Is it worthy
to add the additional timeout in nanoseconds?
_Added a diagram to visually describe the patch_
https://gist.github.com/yifan-c/11780706d3666034f940f3476d37c5d8#file-cassandra-2848-per-request-timeout-svg
was (Author: yifanc):
[Code|https://github.com/yifan-c/cassandra/tree/CASSANDRA-2848-per-request-timeout],
[PR|https://github.com/apache/cassandra/pull/432],
[Test|https://app.circleci.com/jobs/github/yifan-c/cassandra/207]
At high-level, this patch allows clients to set an optional timeout for each
query. If the timeout is present and it is valid to be applied, the coordinator
adjusts the waiting time and the expiration time of the internode messages are
adjusted accordingly.
The optional timeout has the following specifications:
* New flag & option added in V5 native protocol to allow specifying the
[jira] [Commented] (CASSANDRA-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024676#comment-17024676 ] Michael Semb Wever commented on CASSANDRA-14970: bq. Set myself as reviewer. First comment: there have been no commits since the cassandra-2.1.21 release (Feb 2019) and this is not a security/critical patch? I suppose if we have a release planned to fix something for 2.1, implement this patch at that time? I don't have a problem with that. We will need to remember to do so if the need does arise. Though once the release scripts are also merged (in cassandra-builds) it will become obvious. > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-15508) Failing jvm dtest: FailingRepairTest.testFailingMessage
[
https://issues.apache.org/jira/browse/CASSANDRA-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024674#comment-17024674
]
David Capwell commented on CASSANDRA-15508:
---
3.11 is passing now.
[~marcuse] the dag layout match, and tests are all passing. Can you look again?
> Failing jvm dtest: FailingRepairTest.testFailingMessage
> ---
>
> Key: CASSANDRA-15508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15508
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Attachments: Screen Shot 2020-01-17 at 4.51.17 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems we can't run parameterized unit tests with {{ant testsome}}:
> {code}
> $ ant testsome
> -Dtest.name=org.apache.cassandra.distributed.test.FailingRepairTest
> -Dtest.methods=testFailingMessage
>
> [junit-timeout] Testcase:
> initializationError(org.junit.runner.manipulation.Filter):Caused an ERROR
> [junit-timeout] No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] java.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024669#comment-17024669 ] Michael Shuler commented on CASSANDRA-14970: Set myself as reviewer. First comment: there have been no commits since the cassandra-2.1.21 release (Feb 2019) and this is not a security/critical patch? I suppose if we have a release planned to fix something for 2.1, implement this patch at that time? > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14970: --- Reviewers: Michael Shuler > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-2848) Make the Client API support passing down timeouts
[
https://issues.apache.org/jira/browse/CASSANDRA-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024659#comment-17024659
]
Yifan Cai commented on CASSANDRA-2848:
--
[Code|https://github.com/yifan-c/cassandra/tree/CASSANDRA-2848-per-request-timeout],
[PR|https://github.com/apache/cassandra/pull/432],
[Test|https://app.circleci.com/jobs/github/yifan-c/cassandra/207]
At high-level, this patch allows clients to set an optional timeout for each
query. If the timeout is present and it is valid to be applied, the coordinator
adjusts the waiting time and the expiration time of the internode messages are
adjusted accordingly.
The optional timeout has the following specifications:
* New flag & option added in V5 native protocol to allow specifying the
optional timeout.
* The timeout is in milliseconds and the valid range is (0, 2147483647), not
inclusive.
* Data type is Integer. Not using short because the max value of short is
32767, which may not satisfy all cases.
* Default value is Integer.MAX_VALUE
* The timeout value cannot exceeds the database configured one effectively.
** Perform Math.min between the optional timeout (defaults to
Integer.MAX_VALUE) and the configured one.
*Handling the optional timeout*
The server (coordinator) receives the request and deserializes message with the
QueryOptions. QueryState is then created with the computed timings, including
the timeout for this query. The query is processed and the coordinator waits
for the time duration according to the computed timeout in QueryState. The
expiration of the internode messages are adjusted according to the timeout in
QueryState, so that the message can be dropped properly if timeout.
QueryOptions contains all the options set by client. The values of the options
remains immutable.
QueryState stores all the server-side computed values. For example, it has the
resolved timeout for the query. QueryState is now truly one per query as an
outcome of patch CASSANDRA-14677.
{{CQLStatement}} gains a new method {{void resolveTimeout(QueryOptions options,
QueryState state);}} in order to compute the proper timeout for the query at
the start of query processing. The resolved timeout is stored in QueryState,
which is passed along to the code that 1) awaits for response and 2) generates
the internode messages. The method is implemented in the concrete CQL
statements and it is called at `QueryHandler#process`
*Read path*
* Single read: adjust the timeout and capped at `ReadRpcTimeout`
* Range read: adjust the timeout and capped at `RnageRpcTimeout`
* Blocking read repair: adjust the timeout of the repair mutation phase to the
remaining of the read timeout
*Write path*
* Counter mutation: adjust the timeout and capped at `CounterWriteRpcTimeout`
* Normal mutation: adjust the timeout and capped at `WriteRpcTimeout`
* CAS: adjust the timeout and capped at `WriteRpcTimeout`
** There is another timeout value to track the contention time
(CasContentionTimeout) during cas. This timeout remains unchanged.
* Batch
** Counter batch: see counter mutation
** CAS or normal: adjust the time and capped at `WriteRpcTimeout`
*Mix-versions compatibility*
The feature is available only in protocol V5.
*_Client-Server compatibility_*
| |Server V4|Server V5|
|Client V4|Good.|Good. The V4 client will not set the optional timeout. The V5
server uses the default value, Integer.MAX_VALUE|
|Client V5|Good. But the client acts just like a v4 one. |Good.|
_*Server-Server compatibility*_
| |Server V4 (Replica)|Server V5 (Replica)|
|Server V4 (Coordinator)|Good.|Good.|
|Server V5 (Coordinator)|Good. The V5 coordinator updates the expiration. The
V4 replica nodes honor it. |Good.|
*Integration with other components*
Full query logging: the optional timeout exists in QueryOptions. It is already
encoded into the log entry properly.
Audit logging: right now, a timed out query is already logged as
`REQUEST_FAILURE` with the exception message by the audit logger. Is it worthy
to add the additional timeout in nanoseconds?
> Make the Client API support passing down timeouts
> -
>
> Key: CASSANDRA-2848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2848
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client, Messaging/Internode
>Reporter: Chris Goffinet
>Assignee: Yifan Cai
>Priority: Low
> Labels: protocolv5
> Fix For: 4.0-beta
>
> Attachments: 2848-trunk-v2.txt, 2848-trunk.txt
>
>
> Having a max server RPC timeout is good for worst case, but many applications
> that have middleware in front of Cassandra, might have higher timeout
> requirements. In a fail fast environment, if my application starting at say
> the front-end, only
[jira] [Comment Edited] (CASSANDRA-15508) Failing jvm dtest: FailingRepairTest.testFailingMessage
[
https://issues.apache.org/jira/browse/CASSANDRA-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024628#comment-17024628
]
David Capwell edited comment on CASSANDRA-15508 at 1/27/20 8:08 PM:
ok think I fixed 3.11. I forgot to include the copy dtest jars bit into the
parallel Junit runner so no jars were found. Pushed a fix for this, waiting on
circle now.
Latest 3.11:
https://circleci.com/workflow-run/0440a3e8-bcc8-4a15-b99d-c06fe8aa078b
was (Author: dcapwell):
ok think I fixed 3.11. I forgot to include the copy dtest jars bit into the
parallel Junit runner so no jars were found. Pushed a fix for this, waiting on
circle now.
> Failing jvm dtest: FailingRepairTest.testFailingMessage
> ---
>
> Key: CASSANDRA-15508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15508
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Attachments: Screen Shot 2020-01-17 at 4.51.17 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems we can't run parameterized unit tests with {{ant testsome}}:
> {code}
> $ ant testsome
> -Dtest.name=org.apache.cassandra.distributed.test.FailingRepairTest
> -Dtest.methods=testFailingMessage
>
> [junit-timeout] Testcase:
> initializationError(org.junit.runner.manipulation.Filter):Caused an ERROR
> [junit-timeout] No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] java.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15508) Failing jvm dtest: FailingRepairTest.testFailingMessage
[
https://issues.apache.org/jira/browse/CASSANDRA-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024628#comment-17024628
]
David Capwell commented on CASSANDRA-15508:
---
ok think I fixed 3.11. I forgot to include the copy dtest jars bit into the
parallel Junit runner so no jars were found. Pushed a fix for this, waiting on
circle now.
> Failing jvm dtest: FailingRepairTest.testFailingMessage
> ---
>
> Key: CASSANDRA-15508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15508
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Attachments: Screen Shot 2020-01-17 at 4.51.17 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems we can't run parameterized unit tests with {{ant testsome}}:
> {code}
> $ ant testsome
> -Dtest.name=org.apache.cassandra.distributed.test.FailingRepairTest
> -Dtest.methods=testFailingMessage
>
> [junit-timeout] Testcase:
> initializationError(org.junit.runner.manipulation.Filter):Caused an ERROR
> [junit-timeout] No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] java.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15469) IndexInfo/ColumnIndex Refactors & Cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-15469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024603#comment-17024603
]
Dinesh Joshi commented on CASSANDRA-15469:
--
[~jrwest], we don't need to do anything very complex. I was looking through the
code and noticed that changing the {{column_index_cache_size_in_kb}} will
return different values if accessed through {{DatabaseDescriptor}} accessor
methods. This changes an underlying assumption. I am fine with copying the
value at object init and then keeping it around. That way objects that are
maintaining a cache continue to do so. They don't need to necessarily dump it
(or change the buffer size) if the operator changes the value to say {{0}}.
> IndexInfo/ColumnIndex Refactors & Cleanup
> -
>
> Key: CASSANDRA-15469
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15469
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Changes determined by audit of IndexInfo and ColumnIndex changes for
> Cassandra 4.0
--
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-15470) Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-15470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024601#comment-17024601
]
Dinesh Joshi commented on CASSANDRA-15470:
--
[~jrwest], I had to rename the methods as this patch actually surfaced issues
in unit tests that were introduced due to a naming issue. I think I'll open a
follow up ticket to do a bigger refactor to flesh out {{ByteUnit}}. WDYT?
> Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB
> & Bytes
> -
>
> Key: CASSANDRA-15470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15470
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jordan West
>Assignee: Mallika Kulkarni
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DatabaseDescriptor}} has several functions that convert between user
> supplied sizes in KB/MB and bytes. These are implemented without much
> consistency and, while unlikely, several have the potential to overflow since
> validation on the input is missing. Meanwhile, some widen the number to a
> long correctly. Options include: widening in all places or simply doing
> better validation on start up — currently only the lower bound of the valid
> range is checked for many of these fields.
> List of Affected {{DatabaseDescriptor}} Methods:
> * {{getColumnIndexSize}}
> * {{getColumnIndexCacheSize}}
> * {{getBatchSizeWarnThreshold}}
> * {{getNativeTransportFrameBlockSize}}
> * {{getRepairSessionSpaceInMegabytes}}
> * {{getNativeTransportMaxFrameSize}}
--
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-15508) Failing jvm dtest: FailingRepairTest.testFailingMessage
[
https://issues.apache.org/jira/browse/CASSANDRA-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024583#comment-17024583
]
David Capwell commented on CASSANDRA-15508:
---
3.11 had a test failure in jvm dtest
https://app.circleci.com/jobs/github/dcapwell/cassandra/393/tests
The test didn't fail in 3.11, but had the same error in a different test, and
had another error as well.
https://app.circleci.com/jobs/github/dcapwell/cassandra/381/tests
This looks flaky so will attempt to rerun to get a green build.
> Failing jvm dtest: FailingRepairTest.testFailingMessage
> ---
>
> Key: CASSANDRA-15508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15508
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Attachments: Screen Shot 2020-01-17 at 4.51.17 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems we can't run parameterized unit tests with {{ant testsome}}:
> {code}
> $ ant testsome
> -Dtest.name=org.apache.cassandra.distributed.test.FailingRepairTest
> -Dtest.methods=testFailingMessage
>
> [junit-timeout] Testcase:
> initializationError(org.junit.runner.manipulation.Filter):Caused an ERROR
> [junit-timeout] No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] java.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15502) In Tree Tooling with Java 11
[ https://issues.apache.org/jira/browse/CASSANDRA-15502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024582#comment-17024582 ] David Capwell commented on CASSANDRA-15502: --- I keep neglecting to do this... always context switch to something else... I started with a few commands, but barely made a dent. > In Tree Tooling with Java 11 > > > Key: CASSANDRA-15502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15502 > Project: Cassandra > Issue Type: Task > Components: Test/dtest, Test/fuzz, Tool/bulk load, Tool/cqlsh, > Tool/diff, Tool/fql, Tool/nodetool, Tool/sstable, Tool/stress >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-beta > > > This is to cover testing the various tools running on java 11. > The scope of this testing is manual testing and not automated, different > JIRAs should cover automation testing these tool. > The tools in question are: nodetool, sstableloader, sstablescrub, > sstableupgrade, sstableutil, sstableverify, fqltool, stress, auditlogviewer, > compaction-stress, sstabledump, sstableexpiredblockers, sstablemetadata, > sstableofflinerelevel, sstablesplit, and sstablerepairedset (many of these > may be tested already in dtest) -- 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-15508) Failing jvm dtest: FailingRepairTest.testFailingMessage
[
https://issues.apache.org/jira/browse/CASSANDRA-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024577#comment-17024577
]
David Capwell commented on CASSANDRA-15508:
---
pushed changes to 3.0 and 3.11 to also move the approval to top level;
3.0: https://circleci.com/workflow-run/79a284c3-3b71-4a8a-9f19-6a3ed6e0bebd
3.11: https://circleci.com/workflow-run/a0b6cb07-eef5-4758-b39f-bc605dfdad8c
Ill update once I start looking at the 3.11 failure
> Failing jvm dtest: FailingRepairTest.testFailingMessage
> ---
>
> Key: CASSANDRA-15508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15508
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Attachments: Screen Shot 2020-01-17 at 4.51.17 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems we can't run parameterized unit tests with {{ant testsome}}:
> {code}
> $ ant testsome
> -Dtest.name=org.apache.cassandra.distributed.test.FailingRepairTest
> -Dtest.methods=testFailingMessage
>
> [junit-timeout] Testcase:
> initializationError(org.junit.runner.manipulation.Filter):Caused an ERROR
> [junit-timeout] No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] java.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {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] [Comment Edited] (CASSANDRA-15519) Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at runtime
[
https://issues.apache.org/jira/browse/CASSANDRA-15519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024563#comment-17024563
]
Jordan West edited comment on CASSANDRA-15519 at 1/27/20 6:53 PM:
--
Totally understand the benefit of having things near each other but
unfortunately here the feature isn't implemented near that area (the CQL layer
is a clear dividing line between transport and execution). The feature itself
(the queue management) is per {{Server}} as implemented. Is there another
middle ground or recommended place that isn't {{StorageProxyMBean}} we could
use?
was (Author: jrwest):
Totally understand the benefit of having things near each other but
unfortunately here the feature isn't implemented near that area (the CQL layer
is a clear dividing line between transport and execution). The feature itself
(the queue management) is per Server as implemented. Is there another middle
ground or recommended place that isn't {{StorageProxyMBean}} we could use?
> Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at
> runtime
> -
>
> Key: CASSANDRA-15519
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15519
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Messaging/Client
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-15013 added configurable global and per endpoint limits on the
> number of in flight requests, measured in bytes. During times when the
> cluster is overloaded, it can be useful to change this setting without having
> to restart the Cassandra process. Changing the limits should affect all
> existing and new connections.
--
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-15519) Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at runtime
[
https://issues.apache.org/jira/browse/CASSANDRA-15519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024563#comment-17024563
]
Jordan West commented on CASSANDRA-15519:
-
Totally understand the benefit of having things near each other but
unfortunately here the feature isn't implemented near that area (the CQL layer
is a clear dividing line between transport and execution). The feature itself
(the queue management) is per Server as implemented. Is there another middle
ground or recommended place that isn't {{StorageProxyMBean}} we could use?
> Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at
> runtime
> -
>
> Key: CASSANDRA-15519
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15519
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Messaging/Client
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-15013 added configurable global and per endpoint limits on the
> number of in flight requests, measured in bytes. During times when the
> cluster is overloaded, it can be useful to change this setting without having
> to restart the Cassandra process. Changing the limits should affect all
> existing and new connections.
--
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-15508) Failing jvm dtest: FailingRepairTest.testFailingMessage
[
https://issues.apache.org/jira/browse/CASSANDRA-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024562#comment-17024562
]
David Capwell commented on CASSANDRA-15508:
---
Sorry, I get the comment now.
The patch I wrote for trunk moved the approval command to the top, but that was
lost when I rewrote for 3.0 and 3.11; ill add it back.
> Failing jvm dtest: FailingRepairTest.testFailingMessage
> ---
>
> Key: CASSANDRA-15508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15508
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Attachments: Screen Shot 2020-01-17 at 4.51.17 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems we can't run parameterized unit tests with {{ant testsome}}:
> {code}
> $ ant testsome
> -Dtest.name=org.apache.cassandra.distributed.test.FailingRepairTest
> -Dtest.methods=testFailingMessage
>
> [junit-timeout] Testcase:
> initializationError(org.junit.runner.manipulation.Filter):Caused an ERROR
> [junit-timeout] No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] java.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15508) Failing jvm dtest: FailingRepairTest.testFailingMessage
[
https://issues.apache.org/jira/browse/CASSANDRA-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024555#comment-17024555
]
David Capwell commented on CASSANDRA-15508:
---
bq. also the 3.0 and 3.11 workflows don't have start_jvm_upgrade_dtest in the
top level like trunk does?
3.0: https://circleci.com/workflow-run/1145e096-8b8b-4519-bd47-81655b6cedfe
3.0 w/ my patch:
https://circleci.com/workflow-run/0d06171e-3056-4976-b9db-c3e950e686bc
3.11: https://circleci.com/workflow-run/8988cc5c-736d-4d1b-b811-c9df5544cb9c
3.11 w/ my patch:
https://circleci.com/workflow-run/2da5d802-8a3c-42eb-9ab4-7e44fcf4a70b
the shape looks the same to me
What I saw when applying the patch was that I had to rewrite this for 2.2, 3.0,
and 3.11 since the patch couldn't cleanly apply; this implies to me there are
other differences but I have not looked into that.
Trying to look closer at the 3.11 failing test now.
> Failing jvm dtest: FailingRepairTest.testFailingMessage
> ---
>
> Key: CASSANDRA-15508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15508
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Attachments: Screen Shot 2020-01-17 at 4.51.17 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems we can't run parameterized unit tests with {{ant testsome}}:
> {code}
> $ ant testsome
> -Dtest.name=org.apache.cassandra.distributed.test.FailingRepairTest
> -Dtest.methods=testFailingMessage
>
> [junit-timeout] Testcase:
> initializationError(org.junit.runner.manipulation.Filter):Caused an ERROR
> [junit-timeout] No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] java.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15470) Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-15470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024554#comment-17024554
]
Jordan West commented on CASSANDRA-15470:
-
I'm generally fine with either the original patch I reviewed or the newer
version. I'm not sure it was necessary to do the renaming here (when other
functions don't follow that convention yet) and I think {{ByteUnit}} could be a
little more developed.
> Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB
> & Bytes
> -
>
> Key: CASSANDRA-15470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15470
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jordan West
>Assignee: Mallika Kulkarni
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DatabaseDescriptor}} has several functions that convert between user
> supplied sizes in KB/MB and bytes. These are implemented without much
> consistency and, while unlikely, several have the potential to overflow since
> validation on the input is missing. Meanwhile, some widen the number to a
> long correctly. Options include: widening in all places or simply doing
> better validation on start up — currently only the lower bound of the valid
> range is checked for many of these fields.
> List of Affected {{DatabaseDescriptor}} Methods:
> * {{getColumnIndexSize}}
> * {{getColumnIndexCacheSize}}
> * {{getBatchSizeWarnThreshold}}
> * {{getNativeTransportFrameBlockSize}}
> * {{getRepairSessionSpaceInMegabytes}}
> * {{getNativeTransportMaxFrameSize}}
--
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-15508) Failing jvm dtest: FailingRepairTest.testFailingMessage
[
https://issues.apache.org/jira/browse/CASSANDRA-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024550#comment-17024550
]
David Capwell commented on CASSANDRA-15508:
---
ill look closer
> Failing jvm dtest: FailingRepairTest.testFailingMessage
> ---
>
> Key: CASSANDRA-15508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15508
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Attachments: Screen Shot 2020-01-17 at 4.51.17 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems we can't run parameterized unit tests with {{ant testsome}}:
> {code}
> $ ant testsome
> -Dtest.name=org.apache.cassandra.distributed.test.FailingRepairTest
> -Dtest.methods=testFailingMessage
>
> [junit-timeout] Testcase:
> initializationError(org.junit.runner.manipulation.Filter):Caused an ERROR
> [junit-timeout] No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] java.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15524) Fix flakey test - org.apache.cassandra.distributed.test.MessageForwardingTest mutationsForwardedToAllReplicasTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024542#comment-17024542
]
David Capwell commented on CASSANDRA-15524:
---
bq. Wanted to ask what is expected to be fixed here? Do we want to update this
test because some functionality was changed? Or the test is behaving correctly
but a functionality has to be fixed?
The first thing is to classify; test issue or system issue? If the issue is
with the test then updating the test is enough. If the issue is with the
system itself, then we should figure out how to fix that.
[~jmeredithco] the CI builds are closer to the following command
{code}
$ ant testclasslist -Dtest.classlistfile=<( echo
"org/apache/cassandra/distributed/test/MessageForwardingTest.java" )
-Dtest.classlistprefix=distributed
{code}
I "feel" that it happens more frequently on java 11, but have not looked close
enough to the test history to confirm.
> Fix flakey test - org.apache.cassandra.distributed.test.MessageForwardingTest
> mutationsForwardedToAllReplicasTest
> -
>
> Key: CASSANDRA-15524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15524
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: /127.0.0.2 should have been randomized
> to forward messages
> at
> org.apache.cassandra.distributed.test.MessageForwardingTest.lambda$mutationsForwardedToAllReplicasTest$7(MessageForwardingTest.java:87)
> at java.base/java.util.HashMap.forEach(HashMap.java:1336)
> at
> org.apache.cassandra.distributed.test.MessageForwardingTest.mutationsForwardedToAllReplicasTest(MessageForwardingTest.java:87)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: Patch pipeline builds still need the separate declarative pipeline, to pass through the parameters to the build jobs.
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/master by this push:
new defad88 Patch pipeline builds still need the separate declarative
pipeline, to pass through the parameters to the build jobs.
defad88 is described below
commit defad885926ba4674deec8b7ef0a839ded42e396
Author: mck
AuthorDate: Sun Jan 26 12:31:35 2020 +0100
Patch pipeline builds still need the separate declarative pipeline, to pass
through the parameters to the build jobs.
---
jenkins-dsl/cassandra_job_dsl_seed.groovy | 58 +--
jenkins-dsl/cassandra_pipeline.groovy | 246 ++
2 files changed, 290 insertions(+), 14 deletions(-)
diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index c764e46..c876ebf 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -424,6 +424,46 @@ cassandraBranches.each {
/**
+ * Parameterized Artifacts
+ */
+job('Cassandra-devbranch-artifacts') {
+description(jobDescription)
+jdk(jdkLabel)
+label(slaveLabel)
+logRotator {
+numToKeep(25)
+artifactNumToKeep(1)
+}
+wrappers {
+timeout {
+noActivity(300)
+}
+}
+throttleConcurrentBuilds {
+categories(['Cassandra'])
+}
+parameters {
+stringParam('REPO', 'apache', 'The github user/org to clone cassandra
repo from')
+stringParam('BRANCH', 'trunk', 'The branch of cassandra to checkout')
+}
+scm {
+git {
+remote {
+url('https://github.com/${REPO}/cassandra.git')
+}
+branch('${BRANCH}')
+extensions {
+cleanAfterCheckout()
+}
+}
+}
+steps {
+buildDescription('', buildDescStr)
+shell("git clean -xdff ; git clone -b ${buildsBranch} ${buildsRepo}")
+}
+}
+
+/**
* Parameterized Dev Branch `ant test`
*/
testTargets.each {
@@ -628,20 +668,10 @@ pipelineJob('Cassandra-devbranch') {
stringParam('DOCKER_IMAGE', "${dtestDockerImage}", 'Docker image for
running dtests')
}
definition {
-cpsScm {
-scm {
-git {
-remote {
-url('https://github.com/${REPO}/cassandra.git')
-}
-branch('${BRANCH}')
-extensions {
-cleanAfterCheckout()
-}
-}
-}
-lightweight()
-scriptPath('.jenkins/Jenkinsfile')
+cps {
+// Cassandra-devbranch still needs custom Jenkinsfile because of
the parameters passed into the build jobs.
+script(readFileFromWorkspace('Cassandra-Job-DSL',
'jenkins-dsl/cassandra_pipeline.groovy'))
+sandbox()
}
}
}
diff --git a/jenkins-dsl/cassandra_pipeline.groovy
b/jenkins-dsl/cassandra_pipeline.groovy
new file mode 100644
index 000..0f37131
--- /dev/null
+++ b/jenkins-dsl/cassandra_pipeline.groovy
@@ -0,0 +1,246 @@
+// Cassandra-devbranch needs custom Jenkinsfile because of the parameters
passed into the build jobs.
+pipeline {
+ agent any
+ stages {
+ stage('Init') {
+steps {
+cleanWs()
+}
+ }
+ stage('Build') {
+steps {
+build job: "${env.JOB_NAME}-artifacts", parameters: [string(name:
'REPO', value: params.REPO), string(name: 'BRANCH', value: params.BRANCH)]
+}
+ }
+ stage('Test') {
+ parallel {
+stage('stress') {
+ steps {
+ warnError('Tests unstable') {
+ build job: "${env.JOB_NAME}-stress-test", parameters:
[string(name: 'REPO', value: params.REPO), string(name: 'BRANCH', value:
params.BRANCH)]
+ }
+ }
+ post {
+success {
+warnError('missing test xml files') {
+script {
+copyTestResults('stress-test')
+}
+}
+}
+unstable {
+warnError('missing test xml files') {
+script {
+copyTestResults('stress-test')
+}
+}
+}
+ }
+}
+stage('JVM DTests') {
+ steps {
+ warnError('Tests unstable') {
+build job: "${env.JOB_NAME}-test-jvm-dtest-forking",
parameters: [string(name: 'REPO', value: params.REPO), string(name: 'BRANCH',
value: params.BRANCH)]
+
[jira] [Comment Edited] (CASSANDRA-14740) BlockingReadRepair does not maintain monotonicity during range movements
[ https://issues.apache.org/jira/browse/CASSANDRA-14740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024495#comment-17024495 ] Benedict Elliott Smith edited comment on CASSANDRA-14740 at 1/27/20 4:55 PM: - Thanks, I've addressed your comments and pushed. I still need to figure out how to parse CircleCI results. was (Author: benedict): I've addressed your comments and pushed. I still need to figure out how to parse CircleCI results. > BlockingReadRepair does not maintain monotonicity during range movements > > > Key: CASSANDRA-14740 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14740 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Urgent > Labels: correctness > Fix For: 4.0, 4.0-beta > > > The BlockingReadRepair code introduced by CASSANDRA-10726 requires that each > of the queried nodes are written to, but pending nodes are not considered. > If there is a pending range movement, one of these writes may be ‘lost’ when > the range movement completes. -- 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-14740) BlockingReadRepair does not maintain monotonicity during range movements
[ https://issues.apache.org/jira/browse/CASSANDRA-14740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024495#comment-17024495 ] Benedict Elliott Smith commented on CASSANDRA-14740: I've addressed your comments and pushed. I still need to figure out how to parse CircleCI results. > BlockingReadRepair does not maintain monotonicity during range movements > > > Key: CASSANDRA-14740 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14740 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Urgent > Labels: correctness > Fix For: 4.0, 4.0-beta > > > The BlockingReadRepair code introduced by CASSANDRA-10726 requires that each > of the queried nodes are written to, but pending nodes are not considered. > If there is a pending range movement, one of these writes may be ‘lost’ when > the range movement completes. -- 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-15524) Fix flakey test - org.apache.cassandra.distributed.test.MessageForwardingTest mutationsForwardedToAllReplicasTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024465#comment-17024465
]
Jon Meredith commented on CASSANDRA-15524:
--
I'm happy to take a look at this as I added the functionality/test somewhat
recently. It runs reliably for me on my local machine (both from IDEA and
running {{ant test-jvm-dtest-some
-Dtest.name=org.apache.cassandra.distributed.test.MessageForwardingTest
-Dtest.methods=mutationsForwardedToAllReplicasTest}} ),
so I'll try and find some other places to look and track down the build logs.
> Fix flakey test - org.apache.cassandra.distributed.test.MessageForwardingTest
> mutationsForwardedToAllReplicasTest
> -
>
> Key: CASSANDRA-15524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15524
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: /127.0.0.2 should have been randomized
> to forward messages
> at
> org.apache.cassandra.distributed.test.MessageForwardingTest.lambda$mutationsForwardedToAllReplicasTest$7(MessageForwardingTest.java:87)
> at java.base/java.util.HashMap.forEach(HashMap.java:1336)
> at
> org.apache.cassandra.distributed.test.MessageForwardingTest.mutationsForwardedToAllReplicasTest(MessageForwardingTest.java:87)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.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-12995) update hppc dependency to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024402#comment-17024402 ] Ekaterina Dimitrova commented on CASSANDRA-12995: - [~gus] I agree with you. I am already looking at 0.8. New release should come with latest versions so I am gonna work on that. > update hppc dependency to 0.7 > - > > Key: CASSANDRA-12995 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12995 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Packaging >Reporter: Tomas Repik >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: easyfix > Fix For: 4.0 > > Attachments: cassandra-3.11.0-hppc.patch > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream > released even newer version 0.7.2. I attached a patch updating cassandra > sources to depend on the 0.7.1 hppc sources. It should be also compatible > with the newest upstream version. The only actual changes are the removal of > Open infix in class names. The issue was discussed in here: > https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. -- 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-12995) update hppc dependency to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024390#comment-17024390 ] Gus Heck commented on CASSANDRA-12995: -- If this makes it into 4 that would be great. This ticket requests 0.7.2, but I encourage you to bring the version of hppc as far forward as makes sense since 0.7.2 is already a point release behind. > update hppc dependency to 0.7 > - > > Key: CASSANDRA-12995 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12995 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Packaging >Reporter: Tomas Repik >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: easyfix > Fix For: 4.0 > > Attachments: cassandra-3.11.0-hppc.patch > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream > released even newer version 0.7.2. I attached a patch updating cassandra > sources to depend on the 0.7.1 hppc sources. It should be also compatible > with the newest upstream version. The only actual changes are the removal of > Open infix in class names. The issue was discussed in here: > https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. -- 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-15497) Implement node bootstrap in in-JVM tests
[ https://issues.apache.org/jira/browse/CASSANDRA-15497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15497: Reviewers: Marcus Eriksson, Alex Petrov (was: Alex Petrov, Marcus Eriksson) Marcus Eriksson, Alex Petrov Status: Review In Progress (was: Patch Available) > Implement node bootstrap in in-JVM tests > > > Key: CASSANDRA-15497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15497 > Project: Cassandra > Issue Type: New Feature > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > > Currently, we do not have an ability to add nodes to the running in-jvm > cluster, either by bootstrap or replacement process. We need to add an > ability to add nodes in inactive state, start them up, and bootstrap to test > streaming, range movements, and operations that occur during these processes. -- 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-15508) Failing jvm dtest: FailingRepairTest.testFailingMessage
[
https://issues.apache.org/jira/browse/CASSANDRA-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024205#comment-17024205
]
Marcus Eriksson commented on CASSANDRA-15508:
-
looks like the 3.11 in-jvm upgrade dtests fail with:
{{java.lang.RuntimeException: No v22 versions found}}
also the 3.0 and 3.11 workflows don't have {{start_jvm_upgrade_dtest}} in the
top level like trunk does?
> Failing jvm dtest: FailingRepairTest.testFailingMessage
> ---
>
> Key: CASSANDRA-15508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15508
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Attachments: Screen Shot 2020-01-17 at 4.51.17 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems we can't run parameterized unit tests with {{ant testsome}}:
> {code}
> $ ant testsome
> -Dtest.name=org.apache.cassandra.distributed.test.FailingRepairTest
> -Dtest.methods=testFailingMessage
>
> [junit-timeout] Testcase:
> initializationError(org.junit.runner.manipulation.Filter):Caused an ERROR
> [junit-timeout] No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] java.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@4d95d2a2
> [junit-timeout] at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {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-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Nair updated CASSANDRA-15529:
---
Impacts: (was: None)
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
>
> Hello Team,
> For the background of this problem, kindly refer this ticket
> https://issues.apache.org/jira/browse/CASSANDRA-15263
> ++
> It was proposed that after the upgrade of the cluster from 2.1.16 to 3.11.4,
> we should no longer be seeing any type of exceptions (WARN/ERROR).
> But even after a month of upgrade we still see the below exceptions
> *WARN [ReadStage-231]* 2020-01-23 02:29:11,137
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-231,5,main]: {}
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.4.jar:3.11.4]
>
> *and*
>
> *WARN [MutationStage-36]* 2020-01-21 19:31:03,343
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[MutationStage-36,5,main]: {}
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.4.jar:3.11.4] .
> *Problem:*
> If one of the node goes down, and we try to bring it up, the node hangs at a
> stage of reading Key-cache. Sometimes the node comes up after a long period
> of pause with the above *Mutation-stage* warnings. Other times , the node
> does not come up and we have to manually clear the Key-cache to bring up the
> node.
> Also,once the node is up we see lot of above *Read-Stage* warnings.
> In some cases like below , gossip is shutting down and when trying to bring
> up the node it is getting stuck:
> [StorageServiceShutdownHook] 2020-01-24 02:19:30,586 HintsService.java:209 -
> Paused hints dispatch
> INFO [HintsDispatcher:14410] 2020-01-24 02:19:30,593
> HintsDispatchExecutor.java:289 - Finished hinted handoff of file
> 594f065a-3134-4a39-b00d-b87b0e4625ff-1579831570632-1.hints to endpoint
> /10.177.56.125: 594f065a-3134-4a39-b00d-b87b0e4625ff, partially
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,623 Server.java:176 -
> Stop listening for CQL clients
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,624 Gossiper.java:1551
> - Announcing shutdown
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,625
> StorageService.java:2327 - Node ont-dce-cass-sal05-priv/10.103.56.25 state
> jump to shutdown
> INFO [HintsDispatcher:14411] 2020-01-24 02:19:30,682
> HintsDispatchExecutor.java:289 - Finished hinted handoff of file
> b224b069-5b16-42f9-971b-6ae8f8bbcf23-1579829423673-1.hints to endpoint
> /10.177.56.116: b224b069-5b16-42f9-971b-6ae8f8bbcf23, partially
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:32,629
> MessagingService.java:981 - Waiting for messaging service to quiesce
> INFO [ACCEPT-ont-dce-cass-sal05-priv/10.103.56.25] 2020-01-24 02:19:32,631
> MessagingService.java:1336 - MessagingService has terminated the accept()
> thread
> INFO [main] 2020-01-24 02:20:06,214 YamlConfigurationLoader.java:89 -
> Configuration location:
> file:/opt/cass/apache-cassandra-3.11.4/conf/cassandra.yamlWARN
> [MutationStage-12] 2020-01-24 02:24:57,608
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[MutationStage-12,5,main]: {}
> java.lang.AssertionError: nullat
> org.apache.cassandra.utils.memory.AbstractAllocator.clone(AbstractAllocator.java:35)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.db.RangeTombstoneList.clone(RangeTombstoneList.java:130)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.db.RangeTombstoneList.copy(RangeTombstoneList.java:119)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.db.MutableDeletionInfo.copy(MutableDeletionInfo.java:90)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.db.MutableDeletionInfo.copy(MutableDeletionInfo.java:33)
>
[jira] [Updated] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Nair updated CASSANDRA-15529:
---
Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear
Impact(13164)
Complexity: Challenging
Discovered By: User Report
Platform: OpenJDK,Linux (was: All)
Severity: Critical
Since Version: 3.11.4
Labels: 3.11.4 Upgrade (was: )
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 3.11.4, Upgrade
>
> Hello Team,
> For the background of this problem, kindly refer this ticket
> https://issues.apache.org/jira/browse/CASSANDRA-15263
> ++
> It was proposed that after the upgrade of the cluster from 2.1.16 to 3.11.4,
> we should no longer be seeing any type of exceptions (WARN/ERROR).
> But even after a month of upgrade we still see the below exceptions
> *WARN [ReadStage-231]* 2020-01-23 02:29:11,137
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-231,5,main]: {}
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.4.jar:3.11.4]
>
> *and*
>
> *WARN [MutationStage-36]* 2020-01-21 19:31:03,343
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[MutationStage-36,5,main]: {}
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.4.jar:3.11.4] .
> *Problem:*
> If one of the node goes down, and we try to bring it up, the node hangs at a
> stage of reading Key-cache. Sometimes the node comes up after a long period
> of pause with the above *Mutation-stage* warnings. Other times , the node
> does not come up and we have to manually clear the Key-cache to bring up the
> node.
> Also,once the node is up we see lot of above *Read-Stage* warnings.
> In some cases like below , gossip is shutting down and when trying to bring
> up the node it is getting stuck:
> [StorageServiceShutdownHook] 2020-01-24 02:19:30,586 HintsService.java:209 -
> Paused hints dispatch
> INFO [HintsDispatcher:14410] 2020-01-24 02:19:30,593
> HintsDispatchExecutor.java:289 - Finished hinted handoff of file
> 594f065a-3134-4a39-b00d-b87b0e4625ff-1579831570632-1.hints to endpoint
> /10.177.56.125: 594f065a-3134-4a39-b00d-b87b0e4625ff, partially
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,623 Server.java:176 -
> Stop listening for CQL clients
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,624 Gossiper.java:1551
> - Announcing shutdown
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,625
> StorageService.java:2327 - Node ont-dce-cass-sal05-priv/10.103.56.25 state
> jump to shutdown
> INFO [HintsDispatcher:14411] 2020-01-24 02:19:30,682
> HintsDispatchExecutor.java:289 - Finished hinted handoff of file
> b224b069-5b16-42f9-971b-6ae8f8bbcf23-1579829423673-1.hints to endpoint
> /10.177.56.116: b224b069-5b16-42f9-971b-6ae8f8bbcf23, partially
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:32,629
> MessagingService.java:981 - Waiting for messaging service to quiesce
> INFO [ACCEPT-ont-dce-cass-sal05-priv/10.103.56.25] 2020-01-24 02:19:32,631
> MessagingService.java:1336 - MessagingService has terminated the accept()
> thread
> INFO [main] 2020-01-24 02:20:06,214 YamlConfigurationLoader.java:89 -
> Configuration location:
> file:/opt/cass/apache-cassandra-3.11.4/conf/cassandra.yamlWARN
> [MutationStage-12] 2020-01-24 02:24:57,608
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[MutationStage-12,5,main]: {}
> java.lang.AssertionError: nullat
> org.apache.cassandra.utils.memory.AbstractAllocator.clone(AbstractAllocator.java:35)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.db.RangeTombstoneList.clone(RangeTombstoneList.java:130)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.db.RangeTombstoneList.copy(RangeTombstoneList.java:119)
>
[jira] [Updated] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Nair updated CASSANDRA-15529:
---
Labels: 2.1.16 3.11.4 (was: 3.11.4 Upgrade)
> AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16
> to 3.11.4
> -
>
> Key: CASSANDRA-15529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Pooja Nair
>Priority: Urgent
> Labels: 2.1.16, 3.11.4
>
> Hello Team,
> For the background of this problem, kindly refer this ticket
> https://issues.apache.org/jira/browse/CASSANDRA-15263
> ++
> It was proposed that after the upgrade of the cluster from 2.1.16 to 3.11.4,
> we should no longer be seeing any type of exceptions (WARN/ERROR).
> But even after a month of upgrade we still see the below exceptions
> *WARN [ReadStage-231]* 2020-01-23 02:29:11,137
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-231,5,main]: {}
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.4.jar:3.11.4]
>
> *and*
>
> *WARN [MutationStage-36]* 2020-01-21 19:31:03,343
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[MutationStage-36,5,main]: {}
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.4.jar:3.11.4] .
> *Problem:*
> If one of the node goes down, and we try to bring it up, the node hangs at a
> stage of reading Key-cache. Sometimes the node comes up after a long period
> of pause with the above *Mutation-stage* warnings. Other times , the node
> does not come up and we have to manually clear the Key-cache to bring up the
> node.
> Also,once the node is up we see lot of above *Read-Stage* warnings.
> In some cases like below , gossip is shutting down and when trying to bring
> up the node it is getting stuck:
> [StorageServiceShutdownHook] 2020-01-24 02:19:30,586 HintsService.java:209 -
> Paused hints dispatch
> INFO [HintsDispatcher:14410] 2020-01-24 02:19:30,593
> HintsDispatchExecutor.java:289 - Finished hinted handoff of file
> 594f065a-3134-4a39-b00d-b87b0e4625ff-1579831570632-1.hints to endpoint
> /10.177.56.125: 594f065a-3134-4a39-b00d-b87b0e4625ff, partially
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,623 Server.java:176 -
> Stop listening for CQL clients
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,624 Gossiper.java:1551
> - Announcing shutdown
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,625
> StorageService.java:2327 - Node ont-dce-cass-sal05-priv/10.103.56.25 state
> jump to shutdown
> INFO [HintsDispatcher:14411] 2020-01-24 02:19:30,682
> HintsDispatchExecutor.java:289 - Finished hinted handoff of file
> b224b069-5b16-42f9-971b-6ae8f8bbcf23-1579829423673-1.hints to endpoint
> /10.177.56.116: b224b069-5b16-42f9-971b-6ae8f8bbcf23, partially
> INFO [StorageServiceShutdownHook] 2020-01-24 02:19:32,629
> MessagingService.java:981 - Waiting for messaging service to quiesce
> INFO [ACCEPT-ont-dce-cass-sal05-priv/10.103.56.25] 2020-01-24 02:19:32,631
> MessagingService.java:1336 - MessagingService has terminated the accept()
> thread
> INFO [main] 2020-01-24 02:20:06,214 YamlConfigurationLoader.java:89 -
> Configuration location:
> file:/opt/cass/apache-cassandra-3.11.4/conf/cassandra.yamlWARN
> [MutationStage-12] 2020-01-24 02:24:57,608
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[MutationStage-12,5,main]: {}
> java.lang.AssertionError: nullat
> org.apache.cassandra.utils.memory.AbstractAllocator.clone(AbstractAllocator.java:35)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.db.RangeTombstoneList.clone(RangeTombstoneList.java:130)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.db.RangeTombstoneList.copy(RangeTombstoneList.java:119)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.db.MutableDeletionInfo.copy(MutableDeletionInfo.java:90)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
>
[jira] [Created] (CASSANDRA-15529) AbstractLocalAwareExecutorService.java exceptions after upgrade from 2.1.16 to 3.11.4
Pooja Nair created CASSANDRA-15529:
--
Summary: AbstractLocalAwareExecutorService.java exceptions after
upgrade from 2.1.16 to 3.11.4
Key: CASSANDRA-15529
URL: https://issues.apache.org/jira/browse/CASSANDRA-15529
Project: Cassandra
Issue Type: Bug
Components: Cluster/Schema
Reporter: Pooja Nair
Hello Team,
For the background of this problem, kindly refer this ticket
https://issues.apache.org/jira/browse/CASSANDRA-15263
++
It was proposed that after the upgrade of the cluster from 2.1.16 to 3.11.4, we
should no longer be seeing any type of exceptions (WARN/ERROR).
But even after a month of upgrade we still see the below exceptions
*WARN [ReadStage-231]* 2020-01-23 02:29:11,137
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-231,5,main]: {}
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
[apache-cassandra-3.11.4.jar:3.11.4]
*and*
*WARN [MutationStage-36]* 2020-01-21 19:31:03,343
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[MutationStage-36,5,main]: {}
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
[apache-cassandra-3.11.4.jar:3.11.4] .
*Problem:*
If one of the node goes down, and we try to bring it up, the node hangs at a
stage of reading Key-cache. Sometimes the node comes up after a long period of
pause with the above *Mutation-stage* warnings. Other times , the node does not
come up and we have to manually clear the Key-cache to bring up the node.
Also,once the node is up we see lot of above *Read-Stage* warnings.
In some cases like below , gossip is shutting down and when trying to bring up
the node it is getting stuck:
[StorageServiceShutdownHook] 2020-01-24 02:19:30,586 HintsService.java:209 -
Paused hints dispatch
INFO [HintsDispatcher:14410] 2020-01-24 02:19:30,593
HintsDispatchExecutor.java:289 - Finished hinted handoff of file
594f065a-3134-4a39-b00d-b87b0e4625ff-1579831570632-1.hints to endpoint
/10.177.56.125: 594f065a-3134-4a39-b00d-b87b0e4625ff, partially
INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,623 Server.java:176 -
Stop listening for CQL clients
INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,624 Gossiper.java:1551 -
Announcing shutdown
INFO [StorageServiceShutdownHook] 2020-01-24 02:19:30,625
StorageService.java:2327 - Node ont-dce-cass-sal05-priv/10.103.56.25 state jump
to shutdown
INFO [HintsDispatcher:14411] 2020-01-24 02:19:30,682
HintsDispatchExecutor.java:289 - Finished hinted handoff of file
b224b069-5b16-42f9-971b-6ae8f8bbcf23-1579829423673-1.hints to endpoint
/10.177.56.116: b224b069-5b16-42f9-971b-6ae8f8bbcf23, partially
INFO [StorageServiceShutdownHook] 2020-01-24 02:19:32,629
MessagingService.java:981 - Waiting for messaging service to quiesce
INFO [ACCEPT-ont-dce-cass-sal05-priv/10.103.56.25] 2020-01-24 02:19:32,631
MessagingService.java:1336 - MessagingService has terminated the accept() thread
INFO [main] 2020-01-24 02:20:06,214 YamlConfigurationLoader.java:89 -
Configuration location:
file:/opt/cass/apache-cassandra-3.11.4/conf/cassandra.yamlWARN
[MutationStage-12] 2020-01-24 02:24:57,608
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[MutationStage-12,5,main]: {}
java.lang.AssertionError: nullat
org.apache.cassandra.utils.memory.AbstractAllocator.clone(AbstractAllocator.java:35)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.RangeTombstoneList.clone(RangeTombstoneList.java:130)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.RangeTombstoneList.copy(RangeTombstoneList.java:119)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.MutableDeletionInfo.copy(MutableDeletionInfo.java:90)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.MutableDeletionInfo.copy(MutableDeletionInfo.java:33)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(AtomicBTreePartition.java:141)
~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.db.Memtable.put(Memtable.java:282)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1352)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
