[cassandra] branch trunk updated (b617690 -> 244d4c2)
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 b617690 Use immutable map for Read/WriteFailure exception and fix flaky test new b490847 Fix test.distributed.timeout in CircleCI new f2c9b4c Merge branch 'cassandra-2.2' into cassandra-3.0 new 8699366 Merge branch 'cassandra-3.0' into cassandra-3.11 new 244d4c2 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: .circleci/config-2_1.yml| 7 - .circleci/config-2_1.yml.high_res.patch | 2 +- .circleci/config.yml| 55 + .circleci/config.yml.HIGHRES| 44 +- .circleci/config.yml.LOWRES | 42 + 5 files changed, 129 insertions(+), 21 deletions(-) - 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 (bbe09d4 -> 8699366)
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 bbe09d4 Merge branch 'cassandra-3.0' into cassandra-3.11 new b490847 Fix test.distributed.timeout in CircleCI new f2c9b4c Merge branch 'cassandra-2.2' into cassandra-3.0 new 8699366 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: .circleci/config-2_1.yml | 7 ++- .circleci/config.yml | 28 .circleci/config.yml.HIGHRES | 28 .circleci/config.yml.LOWRES | 28 4 files changed, 78 insertions(+), 13 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-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 8699366f761a5b2baea6d2ff4e331c359588f787 Merge: bbe09d4 f2c9b4c Author: Mick Semb Wever AuthorDate: Fri Mar 27 12:18:48 2020 +0100 Merge branch 'cassandra-3.0' into cassandra-3.11 .circleci/config-2_1.yml | 7 ++- .circleci/config.yml | 28 .circleci/config.yml.HIGHRES | 28 .circleci/config.yml.LOWRES | 28 4 files changed, 78 insertions(+), 13 deletions(-) - 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 (4815ae7 -> f2c9b4c)
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 4815ae7 Merge branch 'cassandra-2.2' into cassandra-3.0 new b490847 Fix test.distributed.timeout in CircleCI new f2c9b4c 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: .circleci/config-2_1.yml | 7 ++- .circleci/config.yml | 28 .circleci/config.yml.HIGHRES | 28 .circleci/config.yml.LOWRES | 28 4 files changed, 78 insertions(+), 13 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: Fix test.distributed.timeout in CircleCI
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 b490847 Fix test.distributed.timeout in CircleCI
b490847 is described below
commit b49084733792d9a24b205008ed4da870acf0b670
Author: David Capwell
AuthorDate: Tue Mar 24 17:43:50 2020 -0700
Fix test.distributed.timeout in CircleCI
patch by David Capwell; reviewed by Mick Semb Wever for CASSANDRA-15649
---
.circleci/config-2_1.yml | 7 ++-
.circleci/config.yml | 21 ++---
.circleci/config.yml.HIGHRES | 21 ++---
.circleci/config.yml.LOWRES | 21 ++---
4 files changed, 60 insertions(+), 10 deletions(-)
diff --git a/.circleci/config-2_1.yml b/.circleci/config-2_1.yml
index 3a1eff5..e90ef4a 100644
--- a/.circleci/config-2_1.yml
+++ b/.circleci/config-2_1.yml
@@ -354,10 +354,15 @@ commands:
# Please note that we run `clean` and therefore rebuild the project,
as we can't run tests on Java 8 in case
# based on Java 11 builds.
command: |
+ set -x
export PATH=$JAVA_HOME/bin:$PATH
time mv ~/cassandra /tmp
cd /tmp/cassandra
- ant <>
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=<>
+ test_timeout=$(grep
'name="test.<>.timeout"' build.xml | awk -F'"'
'{print $4}' || true)
+ if [ -z "$test_timeout" ]; then
+test_timeout=$(grep 'name="test.timeout"' build.xml | awk -F'"'
'{print $4}')
+ fi
+ ant <> -Dtest.timeout="$test_timeout"
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=<>
no_output_timeout: <>
- store_test_results:
path: /tmp/cassandra/build/test/output/
diff --git a/.circleci/config.yml b/.circleci/config.yml
index ae582af..d5efe4f 100644
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@ -129,10 +129,15 @@ jobs:
- run:
name: Run Unit Tests (testclasslist)
command: |
+ set -x
export PATH=$JAVA_HOME/bin:$PATH
time mv ~/cassandra /tmp
cd /tmp/cassandra
- ant testclasslist
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=unit
+ test_timeout=$(grep 'name="test.unit.timeout"' build.xml | awk -F'"'
'{print $4}' || true)
+ if [ -z "$test_timeout" ]; then
+test_timeout=$(grep 'name="test.timeout"' build.xml | awk -F'"'
'{print $4}')
+ fi
+ ant testclasslist -Dtest.timeout="$test_timeout"
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=unit
no_output_timeout: 15m
- store_test_results:
path: /tmp/cassandra/build/test/output/
@@ -213,10 +218,15 @@ jobs:
- run:
name: Run Unit Tests (testclasslist)
command: |
+ set -x
export PATH=$JAVA_HOME/bin:$PATH
time mv ~/cassandra /tmp
cd /tmp/cassandra
- ant testclasslist
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=distributed
+ test_timeout=$(grep 'name="test.distributed.timeout"' build.xml |
awk -F'"' '{print $4}' || true)
+ if [ -z "$test_timeout" ]; then
+test_timeout=$(grep 'name="test.timeout"' build.xml | awk -F'"'
'{print $4}')
+ fi
+ ant testclasslist -Dtest.timeout="$test_timeout"
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=distributed
no_output_timeout: 15m
- store_test_results:
path: /tmp/cassandra/build/test/output/
@@ -340,10 +350,15 @@ jobs:
- run:
name: Run Unit Tests (testclasslist-compression)
command: |
+ set -x
export PATH=$JAVA_HOME/bin:$PATH
time mv ~/cassandra /tmp
cd /tmp/cassandra
- ant testclasslist-compression
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=unit
+ test_timeout=$(grep 'name="test.unit.timeout"' build.xml | awk -F'"'
'{print $4}' || true)
+ if [ -z "$test_timeout" ]; then
+test_timeout=$(grep 'name="test.timeout"' build.xml | awk -F'"'
'{print $4}')
+ fi
+ ant testclasslist-compression -Dtest.timeout="$test_timeout"
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=unit
no_output_timeout: 15m
- store_test_results:
path: /tmp/cassandra/build/test/output/
diff --git a/.circleci/config.yml.HIGHRES b/.circleci/config.yml.HIGHRES
index e5ed274..77a396d 100644
--- a/.circleci/config.yml.HIGHRES
+++ b/.circleci/config.yml.HIGHRES
@@ -129,10 +129,15 @@
[jira] [Created] (CASSANDRA-15667) StreamResultFuture check for completeness is inconsistent, leading to races
Sergio Bossa created CASSANDRA-15667:
Summary: StreamResultFuture check for completeness is
inconsistent, leading to races
Key: CASSANDRA-15667
URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
Project: Cassandra
Issue Type: Bug
Components: Legacy/Streaming and Messaging
Reporter: Sergio Bossa
{{StreamResultFuture#maybeComplete()}} uses
{{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
completed, but then accesses each session state via
{{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the former
relies on the actual {{StreamSession}} state, while the latter on the
{{SessionInfo}} state, and the two are concurrently updated with no
coordination whatsoever.
This leads to races, i.e. apparent in some dtest spurious failures, such as
{{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc [~e.dimitrova].
--
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-14754) Add verification of state machine in StreamSession
[
https://issues.apache.org/jira/browse/CASSANDRA-14754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068579#comment-17068579
]
Sergio Bossa commented on CASSANDRA-14754:
--
Thanks [~jasonstack]. Also see CASSANDRA-15667.
> Add verification of state machine in StreamSession
> --
>
> Key: CASSANDRA-14754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14754
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Streaming and Messaging
>Reporter: Jason Brown
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.x
>
>
> {{StreamSession}} contains an implicit state machine, but we have no
> verification of the safety of the transitions between states. For example, we
> have no checks to ensure we cannot leave the final states (COMPLETED, FAILED).
> I propose we add some program logic in {{StreamSession}}, tests, and
> documentation to ensure the correctness of the state transitions.
--
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-15659) Better support of Python 3 for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-15659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068506#comment-17068506 ] Stefan Miklosovic commented on CASSANDRA-15659: --- [~yukim] That sounds good! Thanks a lot. > Better support of Python 3 for cqlsh > > > Key: CASSANDRA-15659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15659 > Project: Cassandra > Issue Type: Task > Components: Tool/cqlsh >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-alpha > > > From mailing list: > [https://lists.apache.org/thread.html/r377099b632c62b641e4feef5b738084fc5369b0c7157fae867853597%40%3Cdev.cassandra.apache.org%3E] > > As of today (24/3/2020) and current trunk, there is Python 3.6 supported (1) > but there is not any 3.6 version ootb in Debian for example. E.g. Buster has > Python 3.7 and other (recent) releases have version 2.7. This means that if > one wants to use Python 3 in Debian, he has to use 3.6 but it is not in the > repository so he has to download / compile / install it on his own. > There should be some sane Python 3 version supported which is as well present > in Debian repository (or requirement to run with 3.6 should be relaxed) . > (1) > [https://github.com/apache/cassandra/blob/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79/bin/cqlsh#L57-L65] -- 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-15650) Fix flaky test org.apache.cassandra.distributed.test.*RepairCoordinatorFastTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15650:
---
Status: Patch Available (was: Review In Progress)
> Fix flaky test
> org.apache.cassandra.distributed.test.*RepairCoordinatorFastTest
> ---
>
> Key: CASSANDRA-15650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15650
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Test failure:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/177/workflows/3dff37a5-9bf4-40e2-8d5b-f127b416dc79/jobs/862
> {code}
> [junit-timeout] Testcase:
> onlyCoordinator[SEQUENTIAL/true](org.apache.cassandra.distributed.test.FullRepairCoordinatorFastTest):
> FAILED
> [junit-timeout] nodetool command repair was successful but not expected to
> be. Actual: 0
> [junit-timeout] junit.framework.AssertionFailedError: nodetool command repair
> was successful but not expected to be. Actual: 0
> [junit-timeout] at
> org.apache.cassandra.distributed.api.NodeToolResult$Asserts.failure(NodeToolResult.java:76)
> [junit-timeout] at
> org.apache.cassandra.distributed.test.RepairCoordinatorFast.onlyCoordinator(RepairCoordinatorFast.java:255)
> [junit-timeout] at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [junit-timeout] at java.lang.Thread.run(Thread.java:748)
> {code}
> [Circle CI
> LOWER|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorTestFlaky]
--
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-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 f2c9b4c1f3580ce6e0567ba129dc5fe489ef29ca
Merge: 4815ae7 b490847
Author: Mick Semb Wever
AuthorDate: Fri Mar 27 12:16:18 2020 +0100
Merge branch 'cassandra-2.2' into cassandra-3.0
.circleci/config-2_1.yml | 7 ++-
.circleci/config.yml | 28
.circleci/config.yml.HIGHRES | 28
.circleci/config.yml.LOWRES | 28
4 files changed, 78 insertions(+), 13 deletions(-)
diff --cc .circleci/config-2_1.yml
index 6b59a4f,e90ef4a..f2c4f50
--- a/.circleci/config-2_1.yml
+++ b/.circleci/config-2_1.yml
@@@ -441,10 -358,11 +442,14 @@@ commands
export PATH=$JAVA_HOME/bin:$PATH
time mv ~/cassandra /tmp
cd /tmp/cassandra
+ if [ -d ~/dtest_jars ]; then
+cp ~/dtest_jars/dtest* /tmp/cassandra/build/
+ fi
- ant <>
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=<>
+ test_timeout=$(grep
'name="test.<>.timeout"' build.xml | awk -F'"'
'{print $4}' || true)
+ if [ -z "$test_timeout" ]; then
+ test_timeout=$(grep 'name="test.timeout"' build.xml | awk -F'"'
'{print $4}')
+ fi
+ ant <> -Dtest.timeout="$test_timeout"
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=<>
no_output_timeout: <>
- store_test_results:
path: /tmp/cassandra/build/test/output/
diff --cc .circleci/config.yml
index 817d726,d5efe4f..3c62b4a
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@@ -1,92 -1,5 +1,97 @@@
version: 2
jobs:
+ j8_jvm_upgrade_dtests:
+docker:
+- image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306
+resource_class: medium
+working_directory: ~/
+shell: /bin/bash -eo pipefail -l
+parallelism: 1
+steps:
+- attach_workspace:
+at: /home/cassandra
+- run:
+name: Determine distributed Tests to Run
+command: |
+ # reminder: this code (along with all the steps) is independently
executed on every circle container
+ # so the goal here is to get the circleci script to return the
tests *this* container will run
+ # which we do via the `circleci` cli tool.
+
+ rm -fr ~/cassandra-dtest/upgrade_tests
+ echo "***java tests***"
+
+ # get all of our unit test filenames
+ set -eo pipefail && circleci tests glob
"$HOME/cassandra/test/distributed/**/*.java" > /tmp/all_java_unit_tests.txt
+
+ # split up the unit tests into groups based on the number of
containers we have
+ set -eo pipefail && circleci tests split --split-by=timings
--timings-type=filename --index=${CIRCLE_NODE_INDEX}
--total=${CIRCLE_NODE_TOTAL} /tmp/all_java_unit_tests.txt >
/tmp/java_tests_${CIRCLE_NODE_INDEX}.txt
+ set -eo pipefail && cat /tmp/java_tests_${CIRCLE_NODE_INDEX}.txt |
sed "s;^/home/cassandra/cassandra/test/distributed/;;g" | grep "Test\.java$" |
grep upgrade > /tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
+ echo "** /tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt"
+ cat /tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
+no_output_timeout: 15m
+- run:
+name: Log Environment Information
+command: |
+ echo '*** id ***'
+ id
+ echo '*** cat /proc/cpuinfo ***'
+ cat /proc/cpuinfo
+ echo '*** free -m ***'
+ free -m
+ echo '*** df -m ***'
+ df -m
+ echo '*** ifconfig -a ***'
+ ifconfig -a
+ echo '*** uname -a ***'
+ uname -a
+ echo '*** mount ***'
+ mount
+ echo '*** env ***'
+ env
+ echo '*** java ***'
+ which java
+ java -version
+- run:
+name: Run Unit Tests (testclasslist)
+command: |
++ set -x
+ export PATH=$JAVA_HOME/bin:$PATH
+ time mv ~/cassandra /tmp
+ cd /tmp/cassandra
+ if [ -d ~/dtest_jars ]; then
+cp ~/dtest_jars/dtest* /tmp/cassandra/build/
+ fi
- ant testclasslist
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=distributed
++ test_timeout=$(grep 'name="test.distributed.timeout"' build.xml |
awk -F'"' '{print $4}' || true)
++ if [ -z "$test_timeout" ]; then
++test_timeout=$(grep 'name="test.timeout"' build.xml | awk -F'"'
'{print $4}')
++ fi
++ ant testclasslist -Dtest.timeout="$test_timeout"
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=distributed
+
[jira] [Updated] (CASSANDRA-15649) test.distributed.timeout no longer respected in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-15649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15649: --- Fix Version/s: 3.11.7 3.0.21 2.2.17 Since Version: 2.2.16 Source Control Link: https://github.com/apache/cassandra/commit/b49084733792d9a24b205008ed4da870acf0b670 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as b49084733792d9a24b205008ed4da870acf0b670 > test.distributed.timeout no longer respected in CircleCI > > > Key: CASSANDRA-15649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15649 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > Attachments: Screen Shot 2020-03-26 at 1.21.34 PM.png, Screen Shot > 2020-03-26 at 1.26.30 PM.png, Screen Shot 2020-03-26 at 1.27.02 PM.png, > Screen Shot 2020-03-26 at 1.29.21 PM.png, Screen Shot 2020-03-26 at 1.29.35 > PM.png, Screen Shot 2020-03-26 at 1.29.57 PM.png, Screen Shot 2020-03-26 at > 1.31.22 PM.png, Screen Shot 2020-03-26 at 1.31.37 PM.png, Screen Shot > 2020-03-26 at 1.31.56 PM.png, Screen Shot 2020-03-26 at 1.32.31 PM.png, > Screen Shot 2020-03-26 at 1.33.20 PM.png, Screen Shot 2020-03-26 at 1.33.28 > PM.png, Screen Shot 2020-03-26 at 1.33.44 PM.png > > Time Spent: 1h > Remaining Estimate: 0h > > After switching jvm dtest over testclasslist (CASSANDRA-15508) we no longer > respect the dtest timeout and instead use the unit test timeout (4m vs 6m). > This does not impact Jenkins as I made sure to check that before calling > testclasslist; though this does impact 2.2, 3.0, and 3.11 as well. > ||Config||Trunk||3.11||3.0||2.2|| > |LOWER||[Circle > CI|https://circleci.com/workflow-run/04f7fbe2-1919-4da0-bf72-ba41b41c3072]| > [Circle > CI|https://circleci.com/workflow-run/69c64062-80f5-4d08-8ab0-dbe88ce7b236] | > [Circle > CI|https://circleci.com/workflow-run/499d2fbe-a8c1-4a27-9430-a9ebb40aad53] | > [Circle > CI|https://circleci.com/workflow-run/fedbd5b8-683d-4c59-a9f6-3aad5a6ba41d] | > |HIGHER| [Circle > CI|https://circleci.com/workflow-run/036bbad1-541a-49dc-a567-cef2300fa847] | > TBD | TBD | TBD | > CI Failures were flaky tests, below are their links > * CASSANDRA-15630 -- 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-15667) StreamResultFuture check for completeness is inconsistent, leading to races
[
https://issues.apache.org/jira/browse/CASSANDRA-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergio Bossa updated CASSANDRA-15667:
-
Fix Version/s: 4.0
> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamResultFuture#maybeComplete()}} uses
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
> completed, but then accesses each session state via
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the
> former relies on the actual {{StreamSession}} state, while the latter on the
> {{SessionInfo}} state, and the two are concurrently updated with no
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc
> [~e.dimitrova].
--
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-15661) Improve logging by using more appropriate levels
[ https://issues.apache.org/jira/browse/CASSANDRA-15661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068580#comment-17068580 ] Alexander Dejanovski commented on CASSANDRA-15661: -- [~rustyrazorblade], I'm overall super happy to get more loggings back in system.log. Having all of what's happening in flushes and compactions at debug level made my life as an ops much harder over the past years. I added a few comments on the PR regarding some that may not be fit for INFO level. They look more like ways to actually debug some implementation details around repair. Let me know what you think. > Improve logging by using more appropriate levels > - > > Key: CASSANDRA-15661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15661 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > There are a number of log statements using logging levels that are a bit too > conservative. For example: > * Flushing memtables is currently at debug. This is a relatively rare event > that is important enough to be INFO > * When compaction finishes we log the progress at debug > * Different steps in incremental repair are logged as debug, should be INFO > * when reaching connection limits in ConnectionLimitHandler.java we log at > warn rather than error. Since this is a client disconnect it’s more than a > warning, we’re taking action and disconnecting. -- 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-15659) Better support of Python 3 for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-15659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068341#comment-17068341 ] Yuki Morishita commented on CASSANDRA-15659: Hi, I filed a few python 3 related tickets, and I'd like to work to improve supports for more recent version of python 3. My suggestion is to make this ticket as an umbrella for all the improvements we will make for better support of python 3. I will link to the tickets as a starter. > Better support of Python 3 for cqlsh > > > Key: CASSANDRA-15659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15659 > Project: Cassandra > Issue Type: Task > Components: Tool/cqlsh >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-alpha > > > From mailing list: > [https://lists.apache.org/thread.html/r377099b632c62b641e4feef5b738084fc5369b0c7157fae867853597%40%3Cdev.cassandra.apache.org%3E] > > As of today (24/3/2020) and current trunk, there is Python 3.6 supported (1) > but there is not any 3.6 version ootb in Debian for example. E.g. Buster has > Python 3.7 and other (recent) releases have version 2.7. This means that if > one wants to use Python 3 in Debian, he has to use 3.6 but it is not in the > repository so he has to download / compile / install it on his own. > There should be some sane Python 3 version supported which is as well present > in Debian repository (or requirement to run with 3.6 should be relaxed) . > (1) > [https://github.com/apache/cassandra/blob/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79/bin/cqlsh#L57-L65] -- 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-15572) `object of type 'NoneType' has no len()` error in cqlsh with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-15572:
---
Parent: CASSANDRA-15659
Workflow: Cassandra Default Workflow (was: Cassandra Bug Workflow)
Issue Type: Sub-task (was: Bug)
> `object of type 'NoneType' has no len()` error in cqlsh with python 3
> -
>
> Key: CASSANDRA-15572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15572
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/cqlsh
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
>
> Looks like in Python 3, webbrowser._tryorder can be NoneType and throw error
> like below:
> {code}
> Traceback (most recent call last):
> File ".\bin\cqlsh.py", line 99, in
> if len(webbrowser._tryorder) == 0:
> TypeError: object of type 'NoneType' has no len()
> {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-15661) Improve logging by using more appropriate levels
[ https://issues.apache.org/jira/browse/CASSANDRA-15661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068385#comment-17068385 ] Alexander Dejanovski commented on CASSANDRA-15661: -- Starting the review on this ticket. > Improve logging by using more appropriate levels > - > > Key: CASSANDRA-15661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15661 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > There are a number of log statements using logging levels that are a bit too > conservative. For example: > * Flushing memtables is currently at debug. This is a relatively rare event > that is important enough to be INFO > * When compaction finishes we log the progress at debug > * Different steps in incremental repair are logged as debug, should be INFO > * when reaching connection limits in ConnectionLimitHandler.java we log at > warn rather than error. Since this is a client disconnect it’s more than a > warning, we’re taking action and disconnecting. -- 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-15573) Python 3.8 fails to execute cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-15573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-15573:
---
Parent: CASSANDRA-15659
Workflow: Cassandra Default Workflow (was: Cassandra Bug Workflow)
Issue Type: Sub-task (was: Bug)
> Python 3.8 fails to execute cqlsh
> -
>
> Key: CASSANDRA-15573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15573
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/cqlsh
>Reporter: Yuki Morishita
>Priority: Normal
>
> Python 3.8 renamed sre_parse.Pattern to sre_parse.State (see
> https://bugs.python.org/issue34681 and corresponding pull request
> https://github.com/python/cpython/pull/9310)
> So when executing cqlsh with Python 3.8, it throws error:
> {code}
> Traceback (most recent call last):
> File ".\bin\cqlsh.py", line 175, in
> from cqlshlib import cql3handling, cqlhandling, pylexotron, sslhandling,
> cqlshhandling
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\cql3handling.py", line 19,
> in
> from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\cqlhandling.py", line 23,
> in
> from cqlshlib import pylexotron, util
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\pylexotron.py", line 342,
> in
> class ParsingRuleSet:
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\pylexotron.py", line 343,
> in ParsingRuleSet
> RuleSpecScanner = SaferScanner([
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\saferscanner.py", line 74,
> in __init__
> s = re.sre_parse.Pattern()
> AttributeError: module 'sre_parse' has no attribute 'Pattern'
> {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-14801) calculatePendingRanges no longer safe for multiple adjacent range movements
[
https://issues.apache.org/jira/browse/CASSANDRA-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov updated CASSANDRA-14801:
-
Test and Documentation Plan:
*
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701]
adds tests that reproduce both bugs.
*
[bb36cd|https://github.com/Ge/cassandra/commit/bb36cd09c164840ad9ab3231f1039c443f8f040c]
fixes the newly discovered bug ({{test1Leave1Move}} in
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701]).
There, the failure happens because for the same pending range we can include 2
replicas with the same endpoint and different ranges (violation of
{{PendingRangeMaps Conflict.DUPLICATE}} policy). This happens because right now
we include in {{PendingRangeMaps}} the entire new replica after leave for
leave-affected ranges and only the pending part of it for move-affected ranges.
This commit marks as pending only the missing part of the new replica.
*
[a33b03|https://github.com/Ge/cassandra/commit/a33b032cd75044db3475505cd32e6afd6f98ad40]
solves the original issue. Without this commit {{getPendingRanges}} can fail
if the same replica covers more than 1 pending range. I think that this is a
valid situation. Consider {{testLeave2}} in
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701].
In this case replica {{Full(127.0.0.1:7012,(-9,0])}} covers 2 ranges -
{{(-9,-4]}} and {{(-4,0]}}. If we run the same test against 3.11 {{(-9, 0]}} is
represented as {{{(-9, -4], (-4, 0]}}} and that possible representation would
not trigger the bug in 4.0. However, I think that we should not base safety of
{{getPendingRanges}} execution on the way a particular
{{AbstractReplicationStrategy}} represents a range and we should allow
duplicate entries while building pending {{RangesAtEndpoint}}.
was:
I reproduced the bug using simple [randomized
test|https://gist.github.com/Ge/f59dc5dedaf6501bb31d79b068244213] that
creates a cluster of N nodes and adds, moves, and removes nodes from it. I also
found another bug where {{TokenMetadata#calculatePendingRanges}} fails during
move-affected replica calculation.
Patch that addresses both problems ([link to
PR|https://github.com/apache/cassandra/pull/495]):
*
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701]
adds tests that reproduce both bugs.
*
[bb36cd|https://github.com/Ge/cassandra/commit/bb36cd09c164840ad9ab3231f1039c443f8f040c]
fixes the newly discovered bug ({{test1Leave1Move}} in
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701]).
There, the failure happens because for the same pending range we can include 2
replicas with the same endpoint and different ranges (violation of
{{PendingRangeMaps Conflict.DUPLICATE}} policy). This happens because right now
we include in {{PendingRangeMaps}} the entire new replica after leave for
leave-affected ranges and only the pending part of it for move-affected ranges.
This commit marks as pending only the missing part of the new replica.
*
[a33b03|https://github.com/Ge/cassandra/commit/a33b032cd75044db3475505cd32e6afd6f98ad40]
solves the original issue. Without this commit {{getPendingRanges}} can fail
if the same replica covers more than 1 pending range. I think that this is a
valid situation. Consider {{testLeave2}} in
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701].
In this case replica {{Full(127.0.0.1:7012,(-9,0])}} covers 2 ranges -
{{(-9,-4]}} and {{(-4,0]}}. If we run the same test against 3.11 {{(-9, 0]}} is
represented as {{\{(-9, -4], (-4, 0]\}}} and that possible representation would
not trigger the bug in 4.0. However, I think that we should not base safety of
{{getPendingRanges}} execution on the way a particular
{{AbstractReplicationStrategy}} represents a range and we should allow
duplicate entries while building pending {{RangesAtEndpoint}}.
With these changes, the randomized test hasn't failed after running for a
while. As I mentioned, it is a very simplistic test, so any suggestions for
improvement are welcome. I haven't included it in the PR, as it seems to be a
good candidate to become flaky. Maybe it is worth adding as a {{long}} test?
> calculatePendingRanges no longer safe for multiple adjacent range movements
> ---
>
> Key: CASSANDRA-14801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14801
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Distributed Metadata
>Reporter: Benedict Elliott Smith
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
[jira] [Updated] (CASSANDRA-14801) calculatePendingRanges no longer safe for multiple adjacent range movements
[
https://issues.apache.org/jira/browse/CASSANDRA-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov updated CASSANDRA-14801:
-
Test and Documentation Plan:
I reproduced the bug using simple [randomized
test|https://gist.github.com/Ge/f59dc5dedaf6501bb31d79b068244213] that
creates a cluster of N nodes and adds, moves, and removes nodes from it. I also
found another bug where {{TokenMetadata#calculatePendingRanges}} fails during
move-affected replica calculation.
Patch that addresses both problems ([link to
PR|https://github.com/apache/cassandra/pull/495]):
*
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701]
adds tests that reproduce both bugs.
*
[bb36cd|https://github.com/Ge/cassandra/commit/bb36cd09c164840ad9ab3231f1039c443f8f040c]
fixes the newly discovered bug ({{test1Leave1Move}} in
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701]).
There, the failure happens because for the same pending range we can include 2
replicas with the same endpoint and different ranges (violation of
{{PendingRangeMaps Conflict.DUPLICATE}} policy). This happens because right now
we include in {{PendingRangeMaps}} the entire new replica after leave for
leave-affected ranges and only the pending part of it for move-affected ranges.
This commit marks as pending only the missing part of the new replica.
*
[a33b03|https://github.com/Ge/cassandra/commit/a33b032cd75044db3475505cd32e6afd6f98ad40]
solves the original issue. Without this commit {{getPendingRanges}} can fail
if the same replica covers more than 1 pending range. I think that this is a
valid situation. Consider {{testLeave2}} in
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701].
In this case replica {{Full(127.0.0.1:7012,(-9,0])}} covers 2 ranges -
{{(-9,-4]}} and {{(-4,0]}}. If we run the same test against 3.11 {{(-9, 0]}} is
represented as {{\{(-9, -4], (-4, 0]\}}} and that possible representation would
not trigger the bug in 4.0. However, I think that we should not base safety of
{{getPendingRanges}} execution on the way a particular
{{AbstractReplicationStrategy}} represents a range and we should allow
duplicate entries while building pending {{RangesAtEndpoint}}.
With these changes, the randomized test hasn't failed after running for a
while. As I mentioned, it is a very simplistic test, so any suggestions for
improvement are welcome. I haven't included it in the PR, as it seems to be a
good candidate to become flaky. Maybe it is worth adding as a {{long}} test?
Status: Patch Available (was: In Progress)
> calculatePendingRanges no longer safe for multiple adjacent range movements
> ---
>
> Key: CASSANDRA-14801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14801
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Distributed Metadata
>Reporter: Benedict Elliott Smith
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Correctness depended upon the narrowing to a {{Set}},
> which we no longer do - we maintain a collection of all {{Replica}}. Our
> {{RangesAtEndpoint}} collection built by {{getPendingRanges}} can as a result
> contain the same endpoint multiple times; and our {{EndpointsForToken}}
> obtained by {{TokenMetadata.pendingEndpointsFor}} may fail to be constructed,
> resulting in cluster-wide failures for writes to the affected token ranges
> for the duration of the range movement.
--
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-15032) Adjust transient replication keyspace replication options to be more friendly to naive clients
[
https://issues.apache.org/jira/browse/CASSANDRA-15032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068785#comment-17068785
]
Alan Boudreault commented on CASSANDRA-15032:
-
That was a good idea. Datastax drivers are currently adding the parsing fix so
this might not be required anymore.
> Adjust transient replication keyspace replication options to be more friendly
> to naive clients
> --
>
> Key: CASSANDRA-15032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15032
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Transient Replication
>Reporter: Andy Tolbert
>Priority: Normal
>
> To specify the number of transient replicas, replication options are
> specified like:
> {code}
> ALTER KEYSPACE foo WITH REPLICATION = {'class' : 'NetworkTopologyStrategy',
> 'DC1' : '3/1'};
> ALTER KEYSPACE foo WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor' : '3/1'}
> {code}
> It occurred to me that existing client drivers that parse keyspace options
> may not handle this gracefully.
> For example, the datastax java driver tries to parse {{3/1}} as a number and
> fails. In this case, the parsing error is not fatal, its just that the
> metadata for that keyspace in the driver is incomplete, and things like token
> aware routing can't be utilized.
> It is possible that other libraries may not handle this as well.
> As an alternative, I propose adding a separate option like:
> {{'transient_replicas': 1}}. {{replication_factor}} would represent the
> total number of replicas (full and transient) in this case. Something similar
> could be done for the NTS case, but might be slightly clumsy to express.
> This would allow existing client libraries to continue working, and while
> things like routing may be suboptimal (i.e. driver won't know to
> differentiate between replicas and transient replicas), at least parsing
> won't fail in possibly fatal ways.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15670) Transient Replication: unable to insert data when the keyspace is configured with the SimpleStrategy
Alan Boudreault created CASSANDRA-15670:
---
Summary: Transient Replication: unable to insert data when the
keyspace is configured with the SimpleStrategy
Key: CASSANDRA-15670
URL: https://issues.apache.org/jira/browse/CASSANDRA-15670
Project: Cassandra
Issue Type: Bug
Components: Feature/Transient Replication
Reporter: Alan Boudreault
An error is thrown then trying to insert data with the transient replication +
SimpleStrategy configured.
Test case:
{code:java}
CREATE KEYSPACE test_tr WITH replication = {'class': 'SimpleStrategy',
'replication_factor': '3/1'};
CREATE TABLE test_tr.users (id int PRIMARY KEY, username text) with read_repair
='NONE';
INSERT INTO test_tr.users (id, username) VALUES (1, 'alan');{code}
traceback:
{code:java}
ERROR [Native-Transport-Requests-8] 2020-03-27 10:27:17,188
ErrorMessage.java:450 - Unexpected exception during request
java.lang.ClassCastException: org.apache.cassandra.locator.SimpleStrategy
cannot be cast to org.apache.cassandra.locator.NetworkTopologyStrategy
at
org.apache.cassandra.db.ConsistencyLevel.eachQuorumForRead(ConsistencyLevel.java:103)
at
org.apache.cassandra.db.ConsistencyLevel.eachQuorumForWrite(ConsistencyLevel.java:112)
at
org.apache.cassandra.locator.ReplicaPlans$2.select(ReplicaPlans.java:409)
at
org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:353)
at
org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:348)
at
org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:341)
at
org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:330)
at
org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1171)
at
org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:713)
at
org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:951)
at
org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:475)
at
org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:453)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:233)
at
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:108)
at
org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
at
org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
at
org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
{code}
-->
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L103
--
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-15670) Transient Replication: unable to insert data when the keyspace is configured with the SimpleStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Boudreault updated CASSANDRA-15670:
Fix Version/s: 4.0-rc
> Transient Replication: unable to insert data when the keyspace is configured
> with the SimpleStrategy
>
>
> Key: CASSANDRA-15670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15670
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Transient Replication
>Reporter: Alan Boudreault
>Priority: Normal
> Fix For: 4.0-rc
>
>
> An error is thrown then trying to insert data with the transient replication
> + SimpleStrategy configured.
> Test case:
> {code:java}
> CREATE KEYSPACE test_tr WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '3/1'};
> CREATE TABLE test_tr.users (id int PRIMARY KEY, username text) with
> read_repair ='NONE';
> INSERT INTO test_tr.users (id, username) VALUES (1, 'alan');{code}
>
> traceback:
> {code:java}
> ERROR [Native-Transport-Requests-8] 2020-03-27 10:27:17,188
> ErrorMessage.java:450 - Unexpected exception during request
> java.lang.ClassCastException: org.apache.cassandra.locator.SimpleStrategy
> cannot be cast to org.apache.cassandra.locator.NetworkTopologyStrategy
> at
> org.apache.cassandra.db.ConsistencyLevel.eachQuorumForRead(ConsistencyLevel.java:103)
> at
> org.apache.cassandra.db.ConsistencyLevel.eachQuorumForWrite(ConsistencyLevel.java:112)
> at
> org.apache.cassandra.locator.ReplicaPlans$2.select(ReplicaPlans.java:409)
> at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:353)
> at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:348)
> at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:341)
> at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:330)
> at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1171)
> at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:713)
> at
> org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:951)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:475)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:453)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
> at
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247)
> at
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:233)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:108)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
> -->
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L103
--
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-14801) calculatePendingRanges no longer safe for multiple adjacent range movements
[
https://issues.apache.org/jira/browse/CASSANDRA-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CASSANDRA-14801:
---
Labels: pull-request-available (was: )
> calculatePendingRanges no longer safe for multiple adjacent range movements
> ---
>
> Key: CASSANDRA-14801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14801
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Distributed Metadata
>Reporter: Benedict Elliott Smith
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
>
> Correctness depended upon the narrowing to a {{Set}},
> which we no longer do - we maintain a collection of all {{Replica}}. Our
> {{RangesAtEndpoint}} collection built by {{getPendingRanges}} can as a result
> contain the same endpoint multiple times; and our {{EndpointsForToken}}
> obtained by {{TokenMetadata.pendingEndpointsFor}} may fail to be constructed,
> resulting in cluster-wide failures for writes to the affected token ranges
> for the duration of the range movement.
--
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-14801) calculatePendingRanges no longer safe for multiple adjacent range movements
[
https://issues.apache.org/jira/browse/CASSANDRA-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068746#comment-17068746
]
Aleksandr Sorokoumov commented on CASSANDRA-14801:
--
I reproduced the bug using simple [randomized
test|https://gist.github.com/Ge/f59dc5dedaf6501bb31d79b068244213] that
creates a cluster of N nodes and adds, moves, and removes nodes from it. I also
found another bug where {{TokenMetadata#calculatePendingRanges}} fails during
move-affected replica calculation.
Patch that addresses both problems ([link to
PR|https://github.com/apache/cassandra/pull/495]):
*
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701]
adds tests that reproduce both bugs.
*
[bb36cd|https://github.com/Ge/cassandra/commit/bb36cd09c164840ad9ab3231f1039c443f8f040c]
fixes the newly discovered bug ({{test1Leave1Move}} in
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701]).
There, the failure happens because for the same pending range we can include 2
replicas with the same endpoint and different ranges (violation of
{{PendingRangeMaps Conflict.DUPLICATE}} policy). This happens because right now
we include in {{PendingRangeMaps}} the entire new replica after leave for
leave-affected ranges and only the pending part of it for move-affected ranges.
This commit marks as pending only the missing part of the new replica.
*
[a33b03|https://github.com/Ge/cassandra/commit/a33b032cd75044db3475505cd32e6afd6f98ad40]
solves the original issue. Without this commit {{getPendingRanges}} can fail
if the same replica covers more than 1 pending range. I think that this is a
valid situation. Consider {{testLeave2}} in
[a534b2|https://github.com/Ge/cassandra/commit/a534b2be9a653fb0cdda75043c0b79e481ca1701].
In this case replica {{Full(127.0.0.1:7012,(-9,0])}} covers 2 ranges -
{{(-9,-4]}} and {{(-4,0]}}. If we run the same test against 3.11 {{(-9, 0]}} is
represented as {{\{(-9, -4], (-4, 0]\}}} and that possible representation would
not trigger the bug in 4.0. However, I think that we should not base safety of
{{getPendingRanges}} execution on the way a particular
{{AbstractReplicationStrategy}} represents a range and we should allow
duplicate entries while building pending {{RangesAtEndpoint}}.
With these changes, the randomized test hasn't failed after running for a
while. As I mentioned, it is a very simplistic test, so any suggestions for
improvement are welcome. I haven't included it in the PR, as it seems to be a
good candidate to become flaky. Maybe it is worth adding as a {{long}} test?
> calculatePendingRanges no longer safe for multiple adjacent range movements
> ---
>
> Key: CASSANDRA-14801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14801
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Distributed Metadata
>Reporter: Benedict Elliott Smith
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Correctness depended upon the narrowing to a {{Set}},
> which we no longer do - we maintain a collection of all {{Replica}}. Our
> {{RangesAtEndpoint}} collection built by {{getPendingRanges}} can as a result
> contain the same endpoint multiple times; and our {{EndpointsForToken}}
> obtained by {{TokenMetadata.pendingEndpointsFor}} may fail to be constructed,
> resulting in cluster-wide failures for writes to the affected token ranges
> for the duration of the range movement.
--
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-15659) Better support of Python 3 for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-15659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068799#comment-17068799 ] Ekaterina Dimitrova commented on CASSANDRA-15659: - Hi [~yukim] and [~stefan.miklosovic]. I will link this one to CASSANDRA-15586 as it is definitely one of the issues which should be tested and found there. If you have also other related findings, please, feel free to link them too. Thank you both! > Better support of Python 3 for cqlsh > > > Key: CASSANDRA-15659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15659 > Project: Cassandra > Issue Type: Task > Components: Tool/cqlsh >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-alpha > > > From mailing list: > [https://lists.apache.org/thread.html/r377099b632c62b641e4feef5b738084fc5369b0c7157fae867853597%40%3Cdev.cassandra.apache.org%3E] > > As of today (24/3/2020) and current trunk, there is Python 3.6 supported (1) > but there is not any 3.6 version ootb in Debian for example. E.g. Buster has > Python 3.7 and other (recent) releases have version 2.7. This means that if > one wants to use Python 3 in Debian, he has to use 3.6 but it is not in the > repository so he has to download / compile / install it on his own. > There should be some sane Python 3 version supported which is as well present > in Debian repository (or requirement to run with 3.6 should be relaxed) . > (1) > [https://github.com/apache/cassandra/blob/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79/bin/cqlsh#L57-L65] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15668) Jenkins 'Cassandra' label applied to the declarative pipeline
Michael Semb Wever created CASSANDRA-15668:
--
Summary: Jenkins 'Cassandra' label applied to the declarative
pipeline
Key: CASSANDRA-15668
URL: https://issues.apache.org/jira/browse/CASSANDRA-15668
Project: Cassandra
Issue Type: Task
Components: Build, Test/unit
Reporter: Michael Semb Wever
Assignee: Michael Semb Wever
On the new ci-cassandra.apache.org infrastructure agents are siloed to projects.
The declarative pipeline in the 2.2, 3.0, 3.11, and trunk branches do not
restrict the builds to agents with the 'cassandra' label. Because these agents
will not run jobs that don't specify this label, the pipeline task only ever
runs on unlabelled agents, of which there are very few (and likely shouldn't
exist because of misconfiguration).
Example of the failure to run the pipeline tasks is
{noformat}
[Pipeline] Start of Pipeline
[Pipeline] node
Still waiting to schedule task
'cassandra10' is reserved for jobs with matching label expression;
'cassandra11' is reserved for jobs with matching label expression;
'cassandra12' is reserved for jobs with matching label expression;
'cassandra13' is reserved for jobs with matching label expression;
'cassandra14' is reserved for jobs with matching label expression;
'cassandra15' is reserved for jobs with matching label expression;
'cassandra16' is reserved for jobs with matching label expression; 'cassandra1'
is reserved for jobs with matching label expression; 'cassandra2' is reserved
for jobs with matching label expression; 'cassandra3' is reserved for jobs with
matching label expression; 'cassandra4' is reserved for jobs with matching
label expression; 'cassandra5' is reserved for jobs with matching label
expression; 'cassandra6' is reserved for jobs with matching label expression;
'cassandra7' is reserved for jobs with matching label expression; 'cassandra8'
is reserved for jobs with matching label expression; 'cassandra9' is reserved
for jobs with matching label expression
{noformat}
Along with this change, we can improve the name of the
{{*-test-jvm-dtest-forking}} stages.
--
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-15668) Jenkins 'Cassandra' label applied to the declarative pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-15668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15668:
---
Change Category: Performance
Complexity: Low Hanging Fruit
Status: Open (was: Triage Needed)
> Jenkins 'Cassandra' label applied to the declarative pipeline
> --
>
> Key: CASSANDRA-15668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15668
> Project: Cassandra
> Issue Type: Task
> Components: Build, Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> On the new ci-cassandra.apache.org infrastructure agents are siloed to
> projects.
> The declarative pipeline in the 2.2, 3.0, 3.11, and trunk branches do not
> restrict the builds to agents with the 'cassandra' label. Because these
> agents will not run jobs that don't specify this label, the pipeline task
> only ever runs on unlabelled agents, of which there are very few (and likely
> shouldn't exist because of misconfiguration).
> Example of the failure to run the pipeline tasks is
> {noformat}
> [Pipeline] Start of Pipeline
> [Pipeline] node
> Still waiting to schedule task
> 'cassandra10' is reserved for jobs with matching label expression;
> 'cassandra11' is reserved for jobs with matching label expression;
> 'cassandra12' is reserved for jobs with matching label expression;
> 'cassandra13' is reserved for jobs with matching label expression;
> 'cassandra14' is reserved for jobs with matching label expression;
> 'cassandra15' is reserved for jobs with matching label expression;
> 'cassandra16' is reserved for jobs with matching label expression;
> 'cassandra1' is reserved for jobs with matching label expression;
> 'cassandra2' is reserved for jobs with matching label expression;
> 'cassandra3' is reserved for jobs with matching label expression;
> 'cassandra4' is reserved for jobs with matching label expression;
> 'cassandra5' is reserved for jobs with matching label expression;
> 'cassandra6' is reserved for jobs with matching label expression;
> 'cassandra7' is reserved for jobs with matching label expression;
> 'cassandra8' is reserved for jobs with matching label expression;
> 'cassandra9' is reserved for jobs with matching label expression
> {noformat}
> Along with this change, we can improve the name of the
> {{*-test-jvm-dtest-forking}} stages.
--
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-15668) Jenkins 'Cassandra' label applied to the declarative pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-15668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15668:
---
Change Category: Semantic (was: Performance)
> Jenkins 'Cassandra' label applied to the declarative pipeline
> --
>
> Key: CASSANDRA-15668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15668
> Project: Cassandra
> Issue Type: Task
> Components: Build, Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> On the new ci-cassandra.apache.org infrastructure agents are siloed to
> projects.
> The declarative pipeline in the 2.2, 3.0, 3.11, and trunk branches do not
> restrict the builds to agents with the 'cassandra' label. Because these
> agents will not run jobs that don't specify this label, the pipeline task
> only ever runs on unlabelled agents, of which there are very few (and likely
> shouldn't exist because of misconfiguration).
> Example of the failure to run the pipeline tasks is
> {noformat}
> [Pipeline] Start of Pipeline
> [Pipeline] node
> Still waiting to schedule task
> 'cassandra10' is reserved for jobs with matching label expression;
> 'cassandra11' is reserved for jobs with matching label expression;
> 'cassandra12' is reserved for jobs with matching label expression;
> 'cassandra13' is reserved for jobs with matching label expression;
> 'cassandra14' is reserved for jobs with matching label expression;
> 'cassandra15' is reserved for jobs with matching label expression;
> 'cassandra16' is reserved for jobs with matching label expression;
> 'cassandra1' is reserved for jobs with matching label expression;
> 'cassandra2' is reserved for jobs with matching label expression;
> 'cassandra3' is reserved for jobs with matching label expression;
> 'cassandra4' is reserved for jobs with matching label expression;
> 'cassandra5' is reserved for jobs with matching label expression;
> 'cassandra6' is reserved for jobs with matching label expression;
> 'cassandra7' is reserved for jobs with matching label expression;
> 'cassandra8' is reserved for jobs with matching label expression;
> 'cassandra9' is reserved for jobs with matching label expression
> {noformat}
> Along with this change, we can improve the name of the
> {{*-test-jvm-dtest-forking}} stages.
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergio Bossa updated CASSANDRA-15375:
-
Reviewers: Sergio Bossa, Sergio Bossa (was: Sergio Bossa)
Sergio Bossa, Sergio Bossa (was: Sergio Bossa)
Status: Review In Progress (was: Patch Available)
[~benedict], apologies for this late review. I've added some comments to your
commit here:
https://github.com/belliottsmith/cassandra/commit/3584b4305ab87f836fdc94d4d5b28bd102642ccb
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergio Bossa updated CASSANDRA-15375:
-
Fix Version/s: 4.0
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
> Fix For: 4.0
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergio Bossa updated CASSANDRA-15375:
-
Reviewers: Sergio Bossa
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15667) StreamResultFuture check for completeness is inconsistent, leading to races
[
https://issues.apache.org/jira/browse/CASSANDRA-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-15667:
--
Assignee: Benjamin Lerer
> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamResultFuture#maybeComplete()}} uses
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
> completed, but then accesses each session state via
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the
> former relies on the actual {{StreamSession}} state, while the latter on the
> {{SessionInfo}} state, and the two are concurrently updated with no
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc
> [~e.dimitrova].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15669) LeveledCompactionStrategy compact last level throw an ArrayIndexOutOfBoundsException
sunhaihong created CASSANDRA-15669: -- Summary: LeveledCompactionStrategy compact last level throw an ArrayIndexOutOfBoundsException Key: CASSANDRA-15669 URL: https://issues.apache.org/jira/browse/CASSANDRA-15669 Project: Cassandra Issue Type: Bug Reporter: sunhaihong Assignee: sunhaihong Attachments: cfs_compaction_info.png, error_info.png cassandra will throw an ArrayIndexOutOfBoundsException when compact last level. My test is as follows： # Create a table with LeveledCompactionStrategy and its params are 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', 'min_threshold': '4', 'sstable_size_in_mb': '2'（fanout_size and sstable_size_in_mb are too small just to make it easier to reproduce the problem）; # Insert data into the table by stress; # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 sstables(this level score bigger than 1.001) I tested it on cassandra version 3.11.3 & 4.0-alpha3. The exception all happened. -- 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-15668) Jenkins 'Cassandra' label applied to the declarative pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-15668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15668:
---
Test and Documentation Plan: testing on local jenkins install
Status: Patch Available (was: In Progress)
> Jenkins 'Cassandra' label applied to the declarative pipeline
> --
>
> Key: CASSANDRA-15668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15668
> Project: Cassandra
> Issue Type: Task
> Components: Build, Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> On the new ci-cassandra.apache.org infrastructure agents are siloed to
> projects.
> The declarative pipeline in the 2.2, 3.0, 3.11, and trunk branches do not
> restrict the builds to agents with the 'cassandra' label. Because these
> agents will not run jobs that don't specify this label, the pipeline task
> only ever runs on unlabelled agents, of which there are very few (and likely
> shouldn't exist because of misconfiguration).
> Example of the failure to run the pipeline tasks is
> {noformat}
> [Pipeline] Start of Pipeline
> [Pipeline] node
> Still waiting to schedule task
> 'cassandra10' is reserved for jobs with matching label expression;
> 'cassandra11' is reserved for jobs with matching label expression;
> 'cassandra12' is reserved for jobs with matching label expression;
> 'cassandra13' is reserved for jobs with matching label expression;
> 'cassandra14' is reserved for jobs with matching label expression;
> 'cassandra15' is reserved for jobs with matching label expression;
> 'cassandra16' is reserved for jobs with matching label expression;
> 'cassandra1' is reserved for jobs with matching label expression;
> 'cassandra2' is reserved for jobs with matching label expression;
> 'cassandra3' is reserved for jobs with matching label expression;
> 'cassandra4' is reserved for jobs with matching label expression;
> 'cassandra5' is reserved for jobs with matching label expression;
> 'cassandra6' is reserved for jobs with matching label expression;
> 'cassandra7' is reserved for jobs with matching label expression;
> 'cassandra8' is reserved for jobs with matching label expression;
> 'cassandra9' is reserved for jobs with matching label expression
> {noformat}
> Along with this change, we can improve the name of the
> {{*-test-jvm-dtest-forking}} stages.
--
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-15651) Jenkins tests to use testclasslist where possible (like CircleCI)
[ https://issues.apache.org/jira/browse/CASSANDRA-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15651: --- Status: Patch Available (was: In Progress) > Jenkins tests to use testclasslist where possible (like CircleCI) > - > > Key: CASSANDRA-15651 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15651 > Project: Cassandra > Issue Type: Task > Components: Build, Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > > Following up on CASSANDRA-15639 > make all the jenkins test jobs run in the same manner. > This standards the approach across test jobs and to CircleCI, and will make > it easier to parallelise test runs later on. -- 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-15651) Jenkins tests to use testclasslist where possible (like CircleCI)
[ https://issues.apache.org/jira/browse/CASSANDRA-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068733#comment-17068733 ] Michael Semb Wever commented on CASSANDRA-15651: Fix is [here|https://github.com/apache/cassandra-builds/commit/dcf8bef5a0f272ed95a8d2851e532cd26adb6b8e], if you have a chance to review again. (It is what you found, that tests were just not running.) > Jenkins tests to use testclasslist where possible (like CircleCI) > - > > Key: CASSANDRA-15651 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15651 > Project: Cassandra > Issue Type: Task > Components: Build, Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > > Following up on CASSANDRA-15639 > make all the jenkins test jobs run in the same manner. > This standards the approach across test jobs and to CircleCI, and will make > it easier to parallelise test runs later on. -- 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-15666) Race condition when completing stream sessions
[
https://issues.apache.org/jira/browse/CASSANDRA-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068591#comment-17068591
]
ZhaoYang commented on CASSANDRA-15666:
--
{quote}4) At this point, if this was the only file to stream, both nodes are
ready to close the session via maybeCompleted(), but:
a) Node A will call it twice from both the IO thread and the thread at #1,
closing the session and its channels.
b) Node B will attempt to send a CompleteMessage, but will fail because the
session has been closed in the meantime.
{quote}
This can be reproduced by delaying {{maybeComplete}} in {{prepareAsync}} until
requests/transfers are empty at follower side.
{quote}I believe the best fix would be to modify the message exchange so that:
1) Only the "follower" is allowed to send the CompleteMessage.
2) Only the "initiator" is allowed to close the session and its channels after
receiving the CompleteMessage.
{quote}
Above points will definitely make streaming state easier to reason. But they
may not be sufficient, it's still possible to send 2 CompleteMessage by
follower when {{maybeComplete()}} in {{prepareAsync()}} is delayed and race
with {{maybeComplete()}} in {{taskCompleted()}}.
1) Follower sends {{PrepareSynAckMessage}} from the {{prepareAsync()}} thread
and {{maybeComplete()}} is delayed.
2) Initiator receives it and starts streaming.
3) Follower receives the streamed files and sends {{ReceivedMessage}}.
4) Follower receives all streamed files and triggers {{maybeComplete()}} in
{{taskCompleted}}
5) Follower will send 2 {{CompleteMessage}} because of step 1) and step 4)
I think we also need to enhance synchronization on state transition and
sending CompleteMessage. WDYT?
> Race condition when completing stream sessions
> --
>
> Key: CASSANDRA-15666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15666
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: ZhaoYang
>Priority: Normal
>
> {{StreamSession#prepareAsync()}} executes, as the name implies,
> asynchronously from the IO thread: this opens up for race conditions between
> the sending of the {{PrepareSynAckMessage}} and the call to
> {{StreamSession#maybeCompleted()}}. I.e., the following could happen:
> 1) Node A sends {{PrepareSynAckMessage}} from the {{prepareAsync()}} thread.
> 2) Node B receives it and starts streaming.
> 3) Node A receives the streamed file and sends {{ReceivedMessage}}.
> 4) At this point, if this was the only file to stream, both nodes are ready
> to close the session via {{maybeCompleted()}}, but:
> a) Node A will call it twice from both the IO thread and the thread at #1,
> closing the session and its channels.
> b) Node B will attempt to send a {{CompleteMessage}}, but will fail because
> the session has been closed in the meantime.
> There are other subtle variations of the pattern above, depending on the
> order of concurrently sent/received messages.
> I believe the best fix would be to modify the message exchange so that:
> 1) Only the "follower" is allowed to send the {{CompleteMessage}}.
> 2) Only the "initiator" is allowed to close the session and its channels
> after receiving the {{CompleteMessage}}.
> By doing so, the message exchange logic would be easier to reason about,
> which is overall a win anyway.
--
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-15668) Jenkins 'Cassandra' label applied to the declarative pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-15668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15668:
---
Fix Version/s: 4.x
3.11.x
3.0.x
2.2.x
> Jenkins 'Cassandra' label applied to the declarative pipeline
> --
>
> Key: CASSANDRA-15668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15668
> Project: Cassandra
> Issue Type: Task
> Components: Build, Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> On the new ci-cassandra.apache.org infrastructure agents are siloed to
> projects.
> The declarative pipeline in the 2.2, 3.0, 3.11, and trunk branches do not
> restrict the builds to agents with the 'cassandra' label. Because these
> agents will not run jobs that don't specify this label, the pipeline task
> only ever runs on unlabelled agents, of which there are very few (and likely
> shouldn't exist because of misconfiguration).
> Example of the failure to run the pipeline tasks is
> {noformat}
> [Pipeline] Start of Pipeline
> [Pipeline] node
> Still waiting to schedule task
> 'cassandra10' is reserved for jobs with matching label expression;
> 'cassandra11' is reserved for jobs with matching label expression;
> 'cassandra12' is reserved for jobs with matching label expression;
> 'cassandra13' is reserved for jobs with matching label expression;
> 'cassandra14' is reserved for jobs with matching label expression;
> 'cassandra15' is reserved for jobs with matching label expression;
> 'cassandra16' is reserved for jobs with matching label expression;
> 'cassandra1' is reserved for jobs with matching label expression;
> 'cassandra2' is reserved for jobs with matching label expression;
> 'cassandra3' is reserved for jobs with matching label expression;
> 'cassandra4' is reserved for jobs with matching label expression;
> 'cassandra5' is reserved for jobs with matching label expression;
> 'cassandra6' is reserved for jobs with matching label expression;
> 'cassandra7' is reserved for jobs with matching label expression;
> 'cassandra8' is reserved for jobs with matching label expression;
> 'cassandra9' is reserved for jobs with matching label expression
> {noformat}
> Along with this change, we can improve the name of the
> {{*-test-jvm-dtest-forking}} stages.
--
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-15651) Jenkins tests to use testclasslist where possible (like CircleCI)
[ https://issues.apache.org/jira/browse/CASSANDRA-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068602#comment-17068602 ] Michael Semb Wever commented on CASSANDRA-15651: Some discussion on this breakage in slack [here|https://the-asf.slack.com/archives/CK23JSY2K/p1585248163058400]. > Jenkins tests to use testclasslist where possible (like CircleCI) > - > > Key: CASSANDRA-15651 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15651 > Project: Cassandra > Issue Type: Task > Components: Build, Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > > Following up on CASSANDRA-15639 > make all the jenkins test jobs run in the same manner. > This standards the approach across test jobs and to CircleCI, and will make > it easier to parallelise test runs later on. -- 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-15668) Jenkins 'Cassandra' label applied to the declarative pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-15668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068641#comment-17068641
]
Michael Semb Wever commented on CASSANDRA-15668:
Cassandra patch at
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/cassandra-2.2_15668
Cassandra-builds patch at
https://github.com/apache/cassandra-builds/compare/master...thelastpickle:mck/15668
> Jenkins 'Cassandra' label applied to the declarative pipeline
> --
>
> Key: CASSANDRA-15668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15668
> Project: Cassandra
> Issue Type: Task
> Components: Build, Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> On the new ci-cassandra.apache.org infrastructure agents are siloed to
> projects.
> The declarative pipeline in the 2.2, 3.0, 3.11, and trunk branches do not
> restrict the builds to agents with the 'cassandra' label. Because these
> agents will not run jobs that don't specify this label, the pipeline task
> only ever runs on unlabelled agents, of which there are very few (and likely
> shouldn't exist because of misconfiguration).
> Example of the failure to run the pipeline tasks is
> {noformat}
> [Pipeline] Start of Pipeline
> [Pipeline] node
> Still waiting to schedule task
> 'cassandra10' is reserved for jobs with matching label expression;
> 'cassandra11' is reserved for jobs with matching label expression;
> 'cassandra12' is reserved for jobs with matching label expression;
> 'cassandra13' is reserved for jobs with matching label expression;
> 'cassandra14' is reserved for jobs with matching label expression;
> 'cassandra15' is reserved for jobs with matching label expression;
> 'cassandra16' is reserved for jobs with matching label expression;
> 'cassandra1' is reserved for jobs with matching label expression;
> 'cassandra2' is reserved for jobs with matching label expression;
> 'cassandra3' is reserved for jobs with matching label expression;
> 'cassandra4' is reserved for jobs with matching label expression;
> 'cassandra5' is reserved for jobs with matching label expression;
> 'cassandra6' is reserved for jobs with matching label expression;
> 'cassandra7' is reserved for jobs with matching label expression;
> 'cassandra8' is reserved for jobs with matching label expression;
> 'cassandra9' is reserved for jobs with matching label expression
> {noformat}
> Along with this change, we can improve the name of the
> {{*-test-jvm-dtest-forking}} stages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov reassigned CASSANDRA-15663:
Assignee: Aleksandr Sorokoumov
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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-15666) Race condition when completing stream sessions
[
https://issues.apache.org/jira/browse/CASSANDRA-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068663#comment-17068663
]
Sergio Bossa commented on CASSANDRA-15666:
--
bq. it's still possible to send 2 CompleteMessage by follower when
maybeComplete() in prepareAsync() is delayed and race with maybeComplete() in
taskCompleted().
Correct. I agree the overall thread safety of {{StreamSession}} should be fixed.
> Race condition when completing stream sessions
> --
>
> Key: CASSANDRA-15666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15666
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: ZhaoYang
>Priority: Normal
>
> {{StreamSession#prepareAsync()}} executes, as the name implies,
> asynchronously from the IO thread: this opens up for race conditions between
> the sending of the {{PrepareSynAckMessage}} and the call to
> {{StreamSession#maybeCompleted()}}. I.e., the following could happen:
> 1) Node A sends {{PrepareSynAckMessage}} from the {{prepareAsync()}} thread.
> 2) Node B receives it and starts streaming.
> 3) Node A receives the streamed file and sends {{ReceivedMessage}}.
> 4) At this point, if this was the only file to stream, both nodes are ready
> to close the session via {{maybeCompleted()}}, but:
> a) Node A will call it twice from both the IO thread and the thread at #1,
> closing the session and its channels.
> b) Node B will attempt to send a {{CompleteMessage}}, but will fail because
> the session has been closed in the meantime.
> There are other subtle variations of the pattern above, depending on the
> order of concurrently sent/received messages.
> I believe the best fix would be to modify the message exchange so that:
> 1) Only the "follower" is allowed to send the {{CompleteMessage}}.
> 2) Only the "initiator" is allowed to close the session and its channels
> after receiving the {{CompleteMessage}}.
> By doing so, the message exchange logic would be easier to reason about,
> which is overall a win anyway.
--
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-15618) add docs for production recommendations
[ https://issues.apache.org/jira/browse/CASSANDRA-15618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17069011#comment-17069011 ] Jordan West commented on CASSANDRA-15618: - Thanks [~rustyrazorblade]. Great to have a doc for this. I appreciate the the cleanup in the compaction docs as well even if it was a bit separate. Comments on the new doc below: Read ahead: * While the section mentions it, a bit more attention could be paid to the small reads case. The intro text primarily focuses on hot data set size and small reads is mentioned only in the 4KB justification. * A table like the token count section could be a nice way to present the recommended defaults * The last sentence of the intro paragraph says “available RAM is greater than the amount of data on disk”. Should this say “available RAM is greater than the hot dataset”? Compression: * With zStd now included do we want to make a recommendation on the algorithm to choose? Cc/ [~djoshi] Compaction: * This section could use some links since the recommendation is to read up on the strategies Encryption: * Consider explaining why you its painful to switch later to drive this point home. Also consider a call out or some emphasis. Racks and Snitch: * Consider emphasizing (bold/italic/callout) the first paragraph * “On prem” -> “on-premise” * Code highlighting of Ec2Snitch > add docs for production recommendations > --- > > Key: CASSANDRA-15618 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15618 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We have some inline comments in our yaml, but I think it would be helpful if > we had a more lengthy section in the docs detailing the settings people > should be using in production. Some of these are unrelated to the yaml > itself (like reducing read ahead), and putting them in the YAML doesn’t make > much sense. There are also other settings (like compression chunk length) > that don’t fit there. Let’s add a page under getting started called > Production Recommendations. -- 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-15618) add docs for production recommendations
[ https://issues.apache.org/jira/browse/CASSANDRA-15618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17069017#comment-17069017 ] Jon Haddad commented on CASSANDRA-15618: Thanks [~jrwest], I'll get the patch updated with your feedback. > add docs for production recommendations > --- > > Key: CASSANDRA-15618 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15618 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We have some inline comments in our yaml, but I think it would be helpful if > we had a more lengthy section in the docs detailing the settings people > should be using in production. Some of these are unrelated to the yaml > itself (like reducing read ahead), and putting them in the YAML doesn’t make > much sense. There are also other settings (like compression chunk length) > that don’t fit there. Let’s add a page under getting started called > Production Recommendations. -- 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-15668) Jenkins 'Cassandra' label applied to the declarative pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-15668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15668:
---
Fix Version/s: (was: 4.x)
4.0-alpha
> Jenkins 'Cassandra' label applied to the declarative pipeline
> --
>
> Key: CASSANDRA-15668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15668
> Project: Cassandra
> Issue Type: Task
> Components: Build, Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-alpha
>
>
> On the new ci-cassandra.apache.org infrastructure agents are siloed to
> projects.
> The declarative pipeline in the 2.2, 3.0, 3.11, and trunk branches do not
> restrict the builds to agents with the 'cassandra' label. Because these
> agents will not run jobs that don't specify this label, the pipeline task
> only ever runs on unlabelled agents, of which there are very few (and likely
> shouldn't exist because of misconfiguration).
> Example of the failure to run the pipeline tasks is
> {noformat}
> [Pipeline] Start of Pipeline
> [Pipeline] node
> Still waiting to schedule task
> 'cassandra10' is reserved for jobs with matching label expression;
> 'cassandra11' is reserved for jobs with matching label expression;
> 'cassandra12' is reserved for jobs with matching label expression;
> 'cassandra13' is reserved for jobs with matching label expression;
> 'cassandra14' is reserved for jobs with matching label expression;
> 'cassandra15' is reserved for jobs with matching label expression;
> 'cassandra16' is reserved for jobs with matching label expression;
> 'cassandra1' is reserved for jobs with matching label expression;
> 'cassandra2' is reserved for jobs with matching label expression;
> 'cassandra3' is reserved for jobs with matching label expression;
> 'cassandra4' is reserved for jobs with matching label expression;
> 'cassandra5' is reserved for jobs with matching label expression;
> 'cassandra6' is reserved for jobs with matching label expression;
> 'cassandra7' is reserved for jobs with matching label expression;
> 'cassandra8' is reserved for jobs with matching label expression;
> 'cassandra9' is reserved for jobs with matching label expression
> {noformat}
> Along with this change, we can improve the name of the
> {{*-test-jvm-dtest-forking}} stages.
--
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-15673) Explore providing additional option to skip CI run on intermediate commits/WIP branches in the circleci/config.yml
[ https://issues.apache.org/jira/browse/CASSANDRA-15673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15673: Change Category: Operability Complexity: Low Hanging Fruit Component/s: Test/unit Fix Version/s: 4.0 Status: Open (was: Triage Needed) > Explore providing additional option to skip CI run on intermediate > commits/WIP branches in the circleci/config.yml > --- > > Key: CASSANDRA-15673 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15673 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0 > > > Explore the options mentioned on the ML list. > Vote any potential patch on the mail list -- 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-15618) add docs for production recommendations
[ https://issues.apache.org/jira/browse/CASSANDRA-15618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17069098#comment-17069098 ] Jon Haddad commented on CASSANDRA-15618: Pushed up changes based on your feedback. I didn't list zstandard yet, mostly because we don't have documentation about it. I'll expand the compression section the same way I did the compression docs in a follow up JIRA. > add docs for production recommendations > --- > > Key: CASSANDRA-15618 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15618 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We have some inline comments in our yaml, but I think it would be helpful if > we had a more lengthy section in the docs detailing the settings people > should be using in production. Some of these are unrelated to the yaml > itself (like reducing read ahead), and putting them in the YAML doesn’t make > much sense. There are also other settings (like compression chunk length) > that don’t fit there. Let’s add a page under getting started called > Production Recommendations. -- 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 (244d4c2 -> 0934730)
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git.
from 244d4c2 Merge branch 'cassandra-3.11' into trunk
new 1f72cc6 Extract in-jvm-dtest API
new c2cfebf Merge branch 'cassandra-2.2' into cassandra-3.0
new a7820d1 Merge branch 'cassandra-3.0' into cassandra-3.11
new 0934730 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 | 2 +
.../org/apache/cassandra/distributed/Cluster.java | 28 +-
.../cassandra/distributed/UpgradeableCluster.java | 31 +-
.../apache/cassandra/distributed/api/Feature.java | 24 --
.../apache/cassandra/distributed/api/ICluster.java | 36 ---
.../cassandra/distributed/api/ICoordinator.java| 40 ---
.../cassandra/distributed/api/IInstance.java | 73 -
.../cassandra/distributed/api/IInstanceConfig.java | 60
.../distributed/api/IIsolatedExecutor.java | 126
.../apache/cassandra/distributed/api/IListen.java | 28 --
.../apache/cassandra/distributed/api/IMessage.java | 38 ---
.../cassandra/distributed/api/IMessageFilters.java | 100 ---
.../distributed/impl/AbstractCluster.java | 319 +++--
.../cassandra/distributed/impl/Coordinator.java| 31 +-
.../impl/DelegatingInvokableInstance.java | 10 +-
.../distributed/impl/DistributedTestSnitch.java| 31 +-
.../distributed/impl/IInvokableInstance.java | 67 -
.../distributed/impl/IUpgradeableInstance.java | 28 --
.../cassandra/distributed/impl/Instance.java | 111 ---
.../distributed/impl/InstanceClassLoader.java | 142 -
.../cassandra/distributed/impl/InstanceConfig.java | 100 ---
.../distributed/impl/IsolatedExecutor.java | 4 +
.../cassandra/distributed/impl/MessageFilters.java | 195 -
.../cassandra/distributed/impl/MessageImpl.java| 10 +-
.../distributed/impl/NetworkTopology.java | 137 -
.../cassandra/distributed/impl/TracingUtil.java| 2 +-
.../cassandra/distributed/impl/Versions.java | 213 --
.../distributed/shared}/RepairResult.java | 16 +-
.../cassandra/distributed/test/BootstrapTest.java | 50 ++--
.../cassandra/distributed/test/CasWriteTest.java | 34 +--
.../distributed/test/DistributedRepairUtils.java | 4 +-
.../distributed/test/DistributedTestBase.java | 173 ---
.../distributed/{impl => test}/ExecUtil.java | 2 +-
.../distributed/test/FailingRepairTest.java| 26 +-
.../distributed/test/GossipSettlesTest.java| 16 +-
.../distributed/test/LargeColumnTest.java | 37 +--
.../distributed/test/MessageFiltersTest.java | 24 +-
.../distributed/test/MessageForwardingTest.java| 34 +--
.../distributed/test/NativeProtocolTest.java | 49 ++--
.../distributed/test/NetworkTopologyTest.java | 40 ++-
.../cassandra/distributed/test/NodeToolTest.java | 6 +-
.../distributed/test/PreviewRepairTest.java| 36 +--
.../test/QueryReplayerEndToEndTest.java| 13 +-
.../cassandra/distributed/test/ReadRepairTest.java | 22 +-
.../distributed/test/RepairCoordinatorBase.java| 2 +-
.../test/RepairCoordinatorFailingMessageTest.java | 2 +-
.../distributed/test/RepairCoordinatorFast.java| 2 +-
.../distributed/test/RepairCoordinatorSlow.java| 1 -
.../distributed/test/RepairDigestTrackingTest.java | 9 +-
.../cassandra/distributed/test/RepairTest.java | 42 +--
.../distributed/test/ResourceLeakTest.java | 22 +-
.../distributed/test/SimpleReadWriteTest.java | 50 ++--
.../cassandra/distributed/test/StreamingTest.java | 4 +-
.../{GossipSettlesTest.java => TestBaseImpl.java} | 34 ++-
.../upgrade/MixedModeReadRepairTest.java | 21 +-
.../cassandra/distributed/upgrade/UpgradeTest.java | 41 ++-
.../distributed/upgrade/UpgradeTestBase.java | 19 +-
.../CassandraIsolatedJunit4ClassRunner.java| 6 +-
.../apache/cassandra/LogbackStatusListener.java| 2 +-
.../config/DatabaseDescriptorRefTest.java | 4 +-
60 files changed, 616 insertions(+), 2213 deletions(-)
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/Feature.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/ICluster.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/ICoordinator.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IInstance.java
delete mode 100644
[cassandra] 01/01: Merge branch 'cassandra-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit c2cfebf44f93af061131d73e4dcbf2a9ff582fe8
Merge: f2c9b4c 1f72cc6
Author: Alex Petrov
AuthorDate: Fri Mar 27 19:04:38 2020 +0100
Merge branch 'cassandra-2.2' into cassandra-3.0
build.xml | 5 +
src/java/org/apache/cassandra/net/MessageOut.java | 1 +
.../org/apache/cassandra/net/MessagingService.java | 2 +-
src/java/org/apache/cassandra/tools/NodeProbe.java | 11 +
src/java/org/apache/cassandra/tools/NodeTool.java | 4 +-
.../org/apache/cassandra/distributed/Cluster.java | 32 +-
.../cassandra/distributed/UpgradeableCluster.java | 32 +-
.../apache/cassandra/distributed/api/Feature.java | 24 --
.../cassandra/distributed/api/ICoordinator.java| 36 --
.../cassandra/distributed/api/IInstance.java | 57
.../cassandra/distributed/api/IInstanceConfig.java | 60
.../distributed/api/IIsolatedExecutor.java | 126 ---
.../apache/cassandra/distributed/api/IListen.java | 28 --
.../apache/cassandra/distributed/api/IMessage.java | 37 --
.../cassandra/distributed/api/IMessageFilters.java | 56
.../distributed/impl/AbstractCluster.java | 373 +
.../cassandra/distributed/impl/Coordinator.java| 56 ++--
.../impl/DelegatingInvokableInstance.java | 11 +-
.../distributed/impl/DistributedTestSnitch.java| 31 +-
.../distributed/impl/IInvokableInstance.java | 67
.../distributed/impl/IUpgradeableInstance.java | 1 +
.../cassandra/distributed/impl/Instance.java | 272 ---
.../distributed/impl/InstanceClassLoader.java | 130 ---
.../cassandra/distributed/impl/InstanceConfig.java | 98 +++---
.../cassandra/distributed/impl/InstanceKiller.java | 50 +++
.../distributed/impl/IsolatedExecutor.java | 4 +
.../apache/cassandra/distributed/impl/Listen.java | 1 -
.../cassandra/distributed/impl/MessageFilters.java | 168 --
.../impl/{Message.java => MessageImpl.java}| 27 +-
.../distributed/impl/NetworkTopology.java | 137
.../apache/cassandra/distributed/impl/RowUtil.java | 1 +
.../cassandra/distributed/impl/TracingUtil.java| 2 +-
.../cassandra/distributed/impl/Versions.java | 190 ---
.../mock/nodetool/InternalNodeProbe.java | 33 +-
.../mock/nodetool/InternalNodeProbeFactory.java| 11 +-
.../cassandra/distributed/test/BootstrapTest.java | 50 +--
.../test/DistributedReadWritePathTest.java | 300 -
.../distributed/test/DistributedTestBase.java | 166 -
.../distributed/test/GossipSettlesTest.java| 16 +-
.../cassandra/distributed/test/GossipTest.java | 4 +-
.../distributed/test/MessageFiltersTest.java | 85 +++--
.../distributed/test/MessageForwardingTest.java| 10 +-
.../distributed/test/NativeProtocolTest.java | 49 +--
.../distributed/test/NetworkTopologyTest.java | 40 ++-
.../cassandra/distributed/test/NodeToolTest.java | 2 +-
.../distributed/test/ResourceLeakTest.java | 13 +-
.../SharedClusterTestBase.java}| 38 ++-
.../distributed/test/SimpleReadWriteTest.java | 276 +++
.../cassandra/distributed/test/TestBaseImpl.java | 47 +++
.../upgrade/CompactStorage2to3UpgradeTest.java | 33 +-
.../upgrade/MixedModeReadRepairTest.java | 8 +-
.../cassandra/distributed/upgrade/UpgradeTest.java | 57 ++--
.../distributed/upgrade/UpgradeTestBase.java | 21 +-
.../apache/cassandra/LogbackStatusListener.java| 2 +-
54 files changed, 1170 insertions(+), 2221 deletions(-)
diff --cc build.xml
index a40cb7d,ed9c1a2..2527883
--- a/build.xml
+++ b/build.xml
@@@ -520,7 -534,19 +524,8 @@@
artifactId="cassandra-parent"
version="${version}"/>
+
-
-
-
-
-
-
-
-
-
-
diff --cc src/java/org/apache/cassandra/net/MessageOut.java
index ce190cb,1e291c2..09ff63b
--- a/src/java/org/apache/cassandra/net/MessageOut.java
+++ b/src/java/org/apache/cassandra/net/MessageOut.java
@@@ -30,6 -30,6 +30,7 @@@ import org.apache.cassandra.concurrent.
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.db.TypeSizes;
import org.apache.cassandra.io.IVersionedSerializer;
++import org.apache.cassandra.io.util.DataOutputBuffer;
import org.apache.cassandra.io.util.DataOutputPlus;
import org.apache.cassandra.tracing.Tracing;
import org.apache.cassandra.utils.FBUtilities;
diff --cc
test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
index 55dbee1,05c8af8..82c06da
---
[cassandra] branch cassandra-3.11 updated (8699366 -> a7820d1)
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a change to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git.
from 8699366 Merge branch 'cassandra-3.0' into cassandra-3.11
new 1f72cc6 Extract in-jvm-dtest API
new c2cfebf Merge branch 'cassandra-2.2' into cassandra-3.0
new a7820d1 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 | 6 +
src/java/org/apache/cassandra/net/MessageOut.java | 26 +-
src/java/org/apache/cassandra/tools/NodeProbe.java | 11 +
src/java/org/apache/cassandra/tools/NodeTool.java | 4 +-
.../org/apache/cassandra/distributed/Cluster.java | 32 +-
.../cassandra/distributed/UpgradeableCluster.java | 32 +-
.../apache/cassandra/distributed/api/Feature.java | 24 --
.../apache/cassandra/distributed/api/ICluster.java | 36 --
.../cassandra/distributed/api/ICoordinator.java| 36 --
.../cassandra/distributed/api/IInstance.java | 57
.../cassandra/distributed/api/IInstanceConfig.java | 60
.../distributed/api/IIsolatedExecutor.java | 126 ---
.../apache/cassandra/distributed/api/IListen.java | 28 --
.../apache/cassandra/distributed/api/IMessage.java | 37 --
.../cassandra/distributed/api/IMessageFilters.java | 56 ---
.../distributed/impl/AbstractCluster.java | 374 +
.../cassandra/distributed/impl/Coordinator.java| 56 +--
.../impl/DelegatingInvokableInstance.java | 11 +-
.../distributed/impl/DistributedTestSnitch.java| 31 +-
.../distributed/impl/IInvokableInstance.java | 67
.../distributed/impl/IUpgradeableInstance.java | 1 +
.../cassandra/distributed/impl/Instance.java | 247 +++---
.../distributed/impl/InstanceClassLoader.java | 130 ---
.../cassandra/distributed/impl/InstanceConfig.java | 98 +++---
.../distributed/impl/InstanceKiller.java} | 48 +--
.../distributed/impl/IsolatedExecutor.java | 4 +
.../apache/cassandra/distributed/impl/Listen.java | 1 -
.../cassandra/distributed/impl/MessageFilters.java | 165 -
.../impl/{Message.java => MessageImpl.java}| 27 +-
.../distributed/impl/NetworkTopology.java | 137
.../apache/cassandra/distributed/impl/RowUtil.java | 1 +
.../cassandra/distributed/impl/TracingUtil.java| 2 +-
.../cassandra/distributed/impl/Versions.java | 190 ---
.../mock/nodetool/InternalNodeProbe.java | 36 +-
.../mock/nodetool/InternalNodeProbeFactory.java| 11 +-
.../cassandra/distributed/test/BootstrapTest.java | 50 +--
.../test/DistributedReadWritePathTest.java | 300 -
.../distributed/test/DistributedTestBase.java | 166 -
.../distributed/test/GossipSettlesTest.java| 16 +-
.../cassandra/distributed/test/GossipTest.java | 4 +-
.../distributed/test/MessageFiltersTest.java | 87 +++--
.../distributed/test/MessageForwardingTest.java| 10 +-
.../distributed/test/NativeProtocolTest.java | 49 +--
.../distributed/test/NetworkTopologyTest.java | 40 ++-
.../cassandra/distributed/test/NodeToolTest.java | 2 +-
.../distributed/test/ResourceLeakTest.java | 12 +-
...SettlesTest.java => SharedClusterTestBase.java} | 32 +-
.../distributed/test/SimpleReadWriteTest.java | 276 +++
.../cassandra/distributed/test/TestBaseImpl.java | 47 +++
.../upgrade/CompactStorage2to3UpgradeTest.java | 33 +-
.../upgrade/MixedModeReadRepairTest.java | 8 +-
.../cassandra/distributed/upgrade/UpgradeTest.java | 57 ++--
.../distributed/upgrade/UpgradeTestBase.java | 21 +-
.../apache/cassandra/LogbackStatusListener.java| 2 +-
54 files changed, 1127 insertions(+), 2293 deletions(-)
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/Feature.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/ICluster.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/ICoordinator.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IInstance.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IInstanceConfig.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IIsolatedExecutor.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IListen.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IMessage.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IMessageFilters.java
delete mode 100644
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit a7820d103956ae72ffbb90f39fe6f2452658a708
Merge: 8699366 c2cfebf
Author: Alex Petrov
AuthorDate: Fri Mar 27 19:08:31 2020 +0100
Merge branch 'cassandra-3.0' into cassandra-3.11
build.xml | 6 +
src/java/org/apache/cassandra/net/MessageOut.java | 26 +-
src/java/org/apache/cassandra/tools/NodeProbe.java | 11 +
src/java/org/apache/cassandra/tools/NodeTool.java | 4 +-
.../org/apache/cassandra/distributed/Cluster.java | 32 +-
.../cassandra/distributed/UpgradeableCluster.java | 32 +-
.../apache/cassandra/distributed/api/Feature.java | 24 --
.../cassandra/distributed/api/ICoordinator.java| 36 --
.../cassandra/distributed/api/IInstance.java | 57
.../cassandra/distributed/api/IInstanceConfig.java | 60
.../distributed/api/IIsolatedExecutor.java | 126 ---
.../apache/cassandra/distributed/api/IListen.java | 28 --
.../apache/cassandra/distributed/api/IMessage.java | 37 --
.../cassandra/distributed/api/IMessageFilters.java | 56 ---
.../distributed/impl/AbstractCluster.java | 374 +
.../cassandra/distributed/impl/Coordinator.java| 56 +--
.../impl/DelegatingInvokableInstance.java | 11 +-
.../distributed/impl/DistributedTestSnitch.java| 31 +-
.../distributed/impl/IInvokableInstance.java | 67
.../distributed/impl/IUpgradeableInstance.java | 1 +
.../cassandra/distributed/impl/Instance.java | 247 +++---
.../distributed/impl/InstanceClassLoader.java | 130 ---
.../cassandra/distributed/impl/InstanceConfig.java | 98 +++---
.../cassandra/distributed/impl/InstanceKiller.java | 50 +++
.../distributed/impl/IsolatedExecutor.java | 4 +
.../apache/cassandra/distributed/impl/Listen.java | 1 -
.../cassandra/distributed/impl/MessageFilters.java | 165 -
.../impl/{Message.java => MessageImpl.java}| 27 +-
.../distributed/impl/NetworkTopology.java | 137
.../apache/cassandra/distributed/impl/RowUtil.java | 1 +
.../cassandra/distributed/impl/TracingUtil.java| 2 +-
.../cassandra/distributed/impl/Versions.java | 190 ---
.../mock/nodetool/InternalNodeProbe.java | 36 +-
.../mock/nodetool/InternalNodeProbeFactory.java| 11 +-
.../cassandra/distributed/test/BootstrapTest.java | 50 +--
.../test/DistributedReadWritePathTest.java | 300 -
.../distributed/test/DistributedTestBase.java | 166 -
.../distributed/test/GossipSettlesTest.java| 16 +-
.../cassandra/distributed/test/GossipTest.java | 4 +-
.../distributed/test/MessageFiltersTest.java | 87 +++--
.../distributed/test/MessageForwardingTest.java| 10 +-
.../distributed/test/NativeProtocolTest.java | 49 +--
.../distributed/test/NetworkTopologyTest.java | 40 ++-
.../cassandra/distributed/test/NodeToolTest.java | 2 +-
.../distributed/test/ResourceLeakTest.java | 12 +-
.../SharedClusterTestBase.java}| 38 ++-
.../distributed/test/SimpleReadWriteTest.java | 276 +++
.../cassandra/distributed/test/TestBaseImpl.java | 47 +++
.../upgrade/CompactStorage2to3UpgradeTest.java | 33 +-
.../upgrade/MixedModeReadRepairTest.java | 8 +-
.../cassandra/distributed/upgrade/UpgradeTest.java | 57 ++--
.../distributed/upgrade/UpgradeTestBase.java | 21 +-
.../apache/cassandra/LogbackStatusListener.java| 2 +-
53 files changed, 1167 insertions(+), 2225 deletions(-)
diff --cc build.xml
index 400a707,2527883..161150a
--- a/build.xml
+++ b/build.xml
@@@ -561,13 -524,8 +565,15 @@@
artifactId="cassandra-parent"
version="${version}"/>
+
-
++
+
+
+
+
+
+
+
diff --cc src/java/org/apache/cassandra/net/MessageOut.java
index 4f41ee5,09ff63b..1d1dd49
--- a/src/java/org/apache/cassandra/net/MessageOut.java
+++ b/src/java/org/apache/cassandra/net/MessageOut.java
@@@ -102,6 -108,6 +102,28 @@@ public class MessageOut void serialize(DataOutputPlus out,
++ InetAddress from,
++ MessagingService.Verb verb,
++ Map parameters,
++ T payload,
++ int version) throws IOException
++{
++IVersionedSerializer serializer = (IVersionedSerializer)
MessagingService.instance().verbSerializers.get(verb);
++serialize(out, from, verb, parameters, payload, serializer, version);
++}
++
++public static void
[cassandra] branch cassandra-3.0 updated (f2c9b4c -> c2cfebf)
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a change to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git.
from f2c9b4c Merge branch 'cassandra-2.2' into cassandra-3.0
new 1f72cc6 Extract in-jvm-dtest API
new c2cfebf 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 | 5 +
src/java/org/apache/cassandra/net/MessageOut.java | 1 +
.../org/apache/cassandra/net/MessagingService.java | 2 +-
src/java/org/apache/cassandra/tools/NodeProbe.java | 11 +
src/java/org/apache/cassandra/tools/NodeTool.java | 4 +-
.../org/apache/cassandra/distributed/Cluster.java | 32 +-
.../cassandra/distributed/UpgradeableCluster.java | 32 +-
.../apache/cassandra/distributed/api/Feature.java | 24 --
.../apache/cassandra/distributed/api/ICluster.java | 36 --
.../cassandra/distributed/api/ICoordinator.java| 36 --
.../cassandra/distributed/api/IInstance.java | 57
.../cassandra/distributed/api/IInstanceConfig.java | 60
.../distributed/api/IIsolatedExecutor.java | 126 ---
.../apache/cassandra/distributed/api/IListen.java | 28 --
.../apache/cassandra/distributed/api/IMessage.java | 37 --
.../cassandra/distributed/api/IMessageFilters.java | 56
.../distributed/impl/AbstractCluster.java | 373 +
.../cassandra/distributed/impl/Coordinator.java| 56 ++--
.../impl/DelegatingInvokableInstance.java | 11 +-
.../distributed/impl/DistributedTestSnitch.java| 31 +-
.../distributed/impl/IInvokableInstance.java | 67
.../distributed/impl/IUpgradeableInstance.java | 1 +
.../cassandra/distributed/impl/Instance.java | 272 ---
.../distributed/impl/InstanceClassLoader.java | 130 ---
.../cassandra/distributed/impl/InstanceConfig.java | 98 +++---
.../distributed/impl/InstanceKiller.java} | 38 +--
.../distributed/impl/IsolatedExecutor.java | 4 +
.../apache/cassandra/distributed/impl/Listen.java | 1 -
.../cassandra/distributed/impl/MessageFilters.java | 168 --
.../impl/{Message.java => MessageImpl.java}| 27 +-
.../distributed/impl/NetworkTopology.java | 137
.../apache/cassandra/distributed/impl/RowUtil.java | 1 +
.../cassandra/distributed/impl/TracingUtil.java| 2 +-
.../cassandra/distributed/impl/Versions.java | 190 ---
.../mock/nodetool/InternalNodeProbe.java | 33 +-
.../mock/nodetool/InternalNodeProbeFactory.java| 11 +-
.../cassandra/distributed/test/BootstrapTest.java | 50 +--
.../test/DistributedReadWritePathTest.java | 300 -
.../distributed/test/DistributedTestBase.java | 166 -
.../distributed/test/GossipSettlesTest.java| 16 +-
.../cassandra/distributed/test/GossipTest.java | 4 +-
.../distributed/test/MessageFiltersTest.java | 85 +++--
.../distributed/test/MessageForwardingTest.java| 10 +-
.../distributed/test/NativeProtocolTest.java | 49 +--
.../distributed/test/NetworkTopologyTest.java | 40 ++-
.../cassandra/distributed/test/NodeToolTest.java | 2 +-
.../distributed/test/ResourceLeakTest.java | 13 +-
...SettlesTest.java => SharedClusterTestBase.java} | 32 +-
.../distributed/test/SimpleReadWriteTest.java | 276 +++
.../cassandra/distributed/test/TestBaseImpl.java | 47 +++
.../upgrade/CompactStorage2to3UpgradeTest.java | 33 +-
.../upgrade/MixedModeReadRepairTest.java | 8 +-
.../cassandra/distributed/upgrade/UpgradeTest.java | 57 ++--
.../distributed/upgrade/UpgradeTestBase.java | 21 +-
.../apache/cassandra/LogbackStatusListener.java| 2 +-
55 files changed, 1133 insertions(+), 2276 deletions(-)
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/Feature.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/ICluster.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/ICoordinator.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IInstance.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IInstanceConfig.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IIsolatedExecutor.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IListen.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IMessage.java
delete mode 100644
test/distributed/org/apache/cassandra/distributed/api/IMessageFilters.java
delete mode 100644
[jira] [Assigned] (CASSANDRA-15673) Explore providing additional option to skip CI run on intermediate commits/WIP branches in the circleci/config.yml
[ https://issues.apache.org/jira/browse/CASSANDRA-15673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-15673: --- Assignee: Ekaterina Dimitrova > Explore providing additional option to skip CI run on intermediate > commits/WIP branches in the circleci/config.yml > --- > > Key: CASSANDRA-15673 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15673 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0 > > > Explore the options mentioned on the ML list. > Vote any potential patch on the mail list -- 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-15651) Jenkins tests to use testclasslist where possible (like CircleCI)
[ https://issues.apache.org/jira/browse/CASSANDRA-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068972#comment-17068972 ] David Capwell commented on CASSANDRA-15651: --- Doh! I missed that during review =( https://github.com/apache/cassandra-builds/commit/dcf8bef5a0f272ed95a8d2851e532cd26adb6b8e#diff-91876f5f158ec50dab9a70cc06c06922R51. This is actually there, at the end of the command. I didn't see jvm-dtest having issue, was just the new ones. I retested burn and long (I felt they were quick but I didn't validate why last time...) and confirm they are picking up the tests now. +1 but should fix the jvm-dtest double arg comment. > Jenkins tests to use testclasslist where possible (like CircleCI) > - > > Key: CASSANDRA-15651 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15651 > Project: Cassandra > Issue Type: Task > Components: Build, Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > > Following up on CASSANDRA-15639 > make all the jenkins test jobs run in the same manner. > This standards the approach across test jobs and to CircleCI, and will make > it easier to parallelise test runs later on. -- 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-15661) Improve logging by using more appropriate levels
[ https://issues.apache.org/jira/browse/CASSANDRA-15661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068977#comment-17068977 ] Jon Haddad commented on CASSANDRA-15661: Thanks for the quick review Alex! For a little context - generally what I'm trying to do here is put the right logging in place so people are able to properly diagnose a cluster's behavior with regard to correctness and data loss after a problem has occurred, when they're running the stock config. There were a few cases in the last several years I could have used the additional logging. None of what was added will significantly increase the log traffic, but every one of the messages has significant value, in my opinion. I replied to each of the comments in the PR. Thanks agin for reviewing so quickly. > Improve logging by using more appropriate levels > - > > Key: CASSANDRA-15661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15661 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > There are a number of log statements using logging levels that are a bit too > conservative. For example: > * Flushing memtables is currently at debug. This is a relatively rare event > that is important enough to be INFO > * When compaction finishes we log the progress at debug > * Different steps in incremental repair are logged as debug, should be INFO > * when reaching connection limits in ConnectionLimitHandler.java we log at > warn rather than error. Since this is a client disconnect it’s more than a > warning, we’re taking action and disconnecting. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15673) Explore providing additional option to skip CI run on intermediate commits/WIP branches in the circleci/config.yml
Ekaterina Dimitrova created CASSANDRA-15673: --- Summary: Explore providing additional option to skip CI run on intermediate commits/WIP branches in the circleci/config.yml Key: CASSANDRA-15673 URL: https://issues.apache.org/jira/browse/CASSANDRA-15673 Project: Cassandra Issue Type: Improvement Reporter: Ekaterina Dimitrova Explore the options mentioned on the ML list. Vote any potential patch on the mail list -- 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-15651) Jenkins tests to use testclasslist where possible (like CircleCI)
[ https://issues.apache.org/jira/browse/CASSANDRA-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17069055#comment-17069055 ] Michael Semb Wever commented on CASSANDRA-15651: bq. https://github.com/apache/cassandra-builds/commit/dcf8bef5a0f272ed95a8d2851e532cd26adb6b8e#diff-91876f5f158ec50dab9a70cc06c06922R51. This is actually there, at the end of the command. I didn't see jvm-dtest having issue, was just the new ones. Thanks. Fixed. > Jenkins tests to use testclasslist where possible (like CircleCI) > - > > Key: CASSANDRA-15651 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15651 > Project: Cassandra > Issue Type: Task > Components: Build, Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > > Following up on CASSANDRA-15639 > make all the jenkins test jobs run in the same manner. > This standards the approach across test jobs and to CircleCI, and will make > it easier to parallelise test runs later on. -- 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-15651) Jenkins tests to use testclasslist where possible (like CircleCI)
[ https://issues.apache.org/jira/browse/CASSANDRA-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15651: -- Reviewers: David Capwell, David Capwell (was: David Capwell) David Capwell, David Capwell (was: David Capwell) Status: Review In Progress (was: Patch Available) > Jenkins tests to use testclasslist where possible (like CircleCI) > - > > Key: CASSANDRA-15651 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15651 > Project: Cassandra > Issue Type: Task > Components: Build, Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > > Following up on CASSANDRA-15639 > make all the jenkins test jobs run in the same manner. > This standards the approach across test jobs and to CircleCI, and will make > it easier to parallelise test runs later on. -- 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-15651) Jenkins tests to use testclasslist where possible (like CircleCI)
[ https://issues.apache.org/jira/browse/CASSANDRA-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15651: --- Status: Ready to Commit (was: Review In Progress) > Jenkins tests to use testclasslist where possible (like CircleCI) > - > > Key: CASSANDRA-15651 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15651 > Project: Cassandra > Issue Type: Task > Components: Build, Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > > Following up on CASSANDRA-15639 > make all the jenkins test jobs run in the same manner. > This standards the approach across test jobs and to CircleCI, and will make > it easier to parallelise test runs later on. -- 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-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15539: Status: Ready to Commit (was: Review In Progress) > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 13h 20m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- 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-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068962#comment-17068962 ] Alex Petrov commented on CASSANDRA-15539: - Thank you for reviews! Committed to 2.2 with [1f72cc6197187abac5b1f70a19589dd4883e8d98|https://github.com/apache/cassandra/commit/1f72cc6197187abac5b1f70a19589dd4883e8d98] and merged up to [3.0|https://github.com/apache/cassandra/commit/c2cfebf44f93af061131d73e4dcbf2a9ff582fe8], [3.11|https://github.com/apache/cassandra/commit/a7820d103956ae72ffbb90f39fe6f2452658a708] and [trunk|https://github.com/apache/cassandra/commit/0934730c2b89b2cc3cb430e4f60fc15b67af7e9f]. Code for dtest-api now lives under https://github.com/apache/cassandra-in-jvm-dtest-api > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 13h 20m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- 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-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15539: Fix Version/s: 4.0 3.11.7 3.0.21 2.2.17 Source Control Link: https://github.com/apache/cassandra/commit/1f72cc6197187abac5b1f70a19589dd4883e8d98 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0 > > Time Spent: 13h 20m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- 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-15669) LeveledCompactionStrategy compact last level throw an ArrayIndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/CASSANDRA-15669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sunhaihong updated CASSANDRA-15669: --- Description: Cassandra will throw an ArrayIndexOutOfBoundsException when compact last level. My test is as follows： # Create a table with LeveledCompactionStrategy and its params are 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', 'min_threshold': '4', 'sstable_size_in_mb': '2'（fanout_size and sstable_size_in_mb are too small just to make it easier to reproduce the problem）; # Insert data into the table by stress; # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 sstables(this level score bigger than 1.001) ERROR [CompactionExecutor:4] 2020-03-28 08:59:00,990 CassandraDaemon.java:442 - Exception in thread Thread[CompactionExecutor:4,1,main] java.lang.ArrayIndexOutOfBoundsException: 9 at org.apache.cassandra.db.compaction.LeveledManifest.getLevel(LeveledManifest.java:814) at org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:746) at org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:398) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:131) at org.apache.cassandra.db.compaction.CompactionStrategyHolder.lambda$getBackgroundTaskSuppliers$0(CompactionStrategyHolder.java:109) at org.apache.cassandra.db.compaction.AbstractStrategyHolder$TaskSupplier.getTask(AbstractStrategyHolder.java:66) at org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:214) at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:289) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) at java.util.concurrent.FutureTask.run(FutureTask.java) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) I tested it on cassandra version 3.11.3 & 4.0-alpha3. The exception all happened. once it triggers, level1- leveln compaction no longer works, level0 is still valid was: Cassandra will throw an ArrayIndexOutOfBoundsException when compact last level. My test is as follows： # Create a table with LeveledCompactionStrategy and its params are 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', 'min_threshold': '4', 'sstable_size_in_mb': '2'（fanout_size and sstable_size_in_mb are too small just to make it easier to reproduce the problem）; # Insert data into the table by stress; # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 sstables(this level score bigger than 1.001) ERROR [CompactionExecutor:4] 2020-03-28 08:59:00,990 CassandraDaemon.java:442 - Exception in thread Thread[CompactionExecutor:4,1,main] java.lang.ArrayIndexOutOfBoundsException: 9 at org.apache.cassandra.db.compaction.LeveledManifest.getLevel(LeveledManifest.java:814) at org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:746) at org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:398) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:131) at org.apache.cassandra.db.compaction.CompactionStrategyHolder.lambda$getBackgroundTaskSuppliers$0(CompactionStrategyHolder.java:109) at org.apache.cassandra.db.compaction.AbstractStrategyHolder$TaskSupplier.getTask(AbstractStrategyHolder.java:66) at org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:214) at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:289) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) at java.util.concurrent.FutureTask.run(FutureTask.java) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) I tested it on cassandra version 3.11.3 & 4.0-alpha3. The exception all happened. once it triggers, compaction no longer works > LeveledCompactionStrategy compact last level throw an > ArrayIndexOutOfBoundsException >
[jira] [Commented] (CASSANDRA-15674) liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted
[ https://issues.apache.org/jira/browse/CASSANDRA-15674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17069158#comment-17069158 ] David Capwell commented on CASSANDRA-15674: --- Prototyping and I see that the reason for the transaction is to swap SSTableReaders into the view. Summary is a local disk thing but we store it in-memory; the swap will replace in-memory with the new summary. The issue remains that we mutate in-place so roll back doesn't happen. > liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if > IndexSummaryRedistribution gets interrupted > - > > Key: CASSANDRA-15674 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15674 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > IndexSummaryRedistribution is a compaction task and as such extends Holder > and supports cancelation by throwing a CompactionInterruptedException. The > issue is that IndexSummaryRedistribution tries to use transactions, but > mutates the sstable in-place; transaction is unable to roll back. > This would be fine (only updates summary) if it wasn’t for the fact the task > attempts to also mutate the two metrics liveDiskSpaceUsed and > totalDiskSpaceUsed, since these can’t be rolled back any cancelation could > corrupt these metrics. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15669) LeveledCompactionStrategy compact last level throw an ArrayIndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/CASSANDRA-15669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sunhaihong updated CASSANDRA-15669: --- Description: Cassandra will throw an ArrayIndexOutOfBoundsException when compact last level. My test is as follows： # Create a table with LeveledCompactionStrategy and its params are 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', 'min_threshold': '4', 'sstable_size_in_mb': '2'（fanout_size and sstable_size_in_mb are too small just to make it easier to reproduce the problem）; # Insert data into the table by stress; # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 sstables(this level score bigger than 1.001) ERROR [CompactionExecutor:4] 2020-03-28 08:59:00,990 CassandraDaemon.java:442 - Exception in thread Thread[CompactionExecutor:4,1,main] java.lang.ArrayIndexOutOfBoundsException: 9 at org.apache.cassandra.db.compaction.LeveledManifest.getLevel(LeveledManifest.java:814) at org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:746) at org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:398) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:131) at org.apache.cassandra.db.compaction.CompactionStrategyHolder.lambda$getBackgroundTaskSuppliers$0(CompactionStrategyHolder.java:109) at org.apache.cassandra.db.compaction.AbstractStrategyHolder$TaskSupplier.getTask(AbstractStrategyHolder.java:66) at org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:214) at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:289) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) at java.util.concurrent.FutureTask.run(FutureTask.java) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) I tested it on cassandra version 3.11.3 & 4.0-alpha3. The exception all happened. once it triggers, compaction no longer works was: Cassandra will throw an ArrayIndexOutOfBoundsException when compact last level. My test is as follows： # Create a table with LeveledCompactionStrategy and its params are 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', 'min_threshold': '4', 'sstable_size_in_mb': '2'（fanout_size and sstable_size_in_mb are too small just to make it easier to reproduce the problem）; # Insert data into the table by stress; # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 sstables(this level score bigger than 1.001) ERROR [CompactionExecutor:4] 2020-03-28 08:59:00,990 CassandraDaemon.java:442 - Exception in thread Thread[CompactionExecutor:4,1,main] java.lang.ArrayIndexOutOfBoundsException: 9 at org.apache.cassandra.db.compaction.LeveledManifest.getLevel(LeveledManifest.java:814) at org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:746) at org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:398) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:131) at org.apache.cassandra.db.compaction.CompactionStrategyHolder.lambda$getBackgroundTaskSuppliers$0(CompactionStrategyHolder.java:109) at org.apache.cassandra.db.compaction.AbstractStrategyHolder$TaskSupplier.getTask(AbstractStrategyHolder.java:66) at org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:214) at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:289) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) at java.util.concurrent.FutureTask.run(FutureTask.java) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) I tested it on cassandra version 3.11.3 & 4.0-alpha3. The exception all happened. > LeveledCompactionStrategy compact last level throw an > ArrayIndexOutOfBoundsException > > > Key: CASSANDRA-15669 > URL:
[jira] [Created] (CASSANDRA-15674) liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted
David Capwell created CASSANDRA-15674: - Summary: liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted Key: CASSANDRA-15674 URL: https://issues.apache.org/jira/browse/CASSANDRA-15674 Project: Cassandra Issue Type: Bug Components: Local/Compaction, Observability/Metrics Reporter: David Capwell Assignee: David Capwell IndexSummaryRedistribution is a compaction task and as such extends Holder and supports cancelation by throwing a CompactionInterruptedException. The issue is that IndexSummaryRedistribution tries to use transactions, but mutates the sstable in-place; transaction is unable to roll back. This would be fine (only updates summary) if it wasn’t for the fact the task attempts to also mutate the two metrics liveDiskSpaceUsed and totalDiskSpaceUsed, since these can’t be rolled back any cancelation could corrupt these metrics. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15674) liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted
[ https://issues.apache.org/jira/browse/CASSANDRA-15674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15674: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable Corruption / Loss(12986) Complexity: Normal Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if > IndexSummaryRedistribution gets interrupted > - > > Key: CASSANDRA-15674 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15674 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > IndexSummaryRedistribution is a compaction task and as such extends Holder > and supports cancelation by throwing a CompactionInterruptedException. The > issue is that IndexSummaryRedistribution tries to use transactions, but > mutates the sstable in-place; transaction is unable to roll back. > This would be fine (only updates summary) if it wasn’t for the fact the task > attempts to also mutate the two metrics liveDiskSpaceUsed and > totalDiskSpaceUsed, since these can’t be rolled back any cancelation could > corrupt these metrics. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15618) add docs for production recommendations
[
https://issues.apache.org/jira/browse/CASSANDRA-15618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Haddad updated CASSANDRA-15618:
---
Test and Documentation Plan:
To build the sphinx docs and preview locally:
{noformat}
cd docs
export SKIP_NODETOOL=1 # don't build the nodetool docs
docker-compose build build-docs
docker-compose run build-docs
{noformat}
was:
To build the sphinx docs and preview locally:
{noformat}
cd docs
docker-compose build build-docs
docker-compose run build-docs
{noformat}
> add docs for production recommendations
> ---
>
> Key: CASSANDRA-15618
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15618
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have some inline comments in our yaml, but I think it would be helpful if
> we had a more lengthy section in the docs detailing the settings people
> should be using in production. Some of these are unrelated to the yaml
> itself (like reducing read ahead), and putting them in the YAML doesn’t make
> much sense. There are also other settings (like compression chunk length)
> that don’t fit there. Let’s add a page under getting started called
> Production Recommendations.
--
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-15669) LeveledCompactionStrategy compact last level throw an ArrayIndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/CASSANDRA-15669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sunhaihong updated CASSANDRA-15669: --- Description: Cassandra will throw an ArrayIndexOutOfBoundsException when compact last level. My test is as follows： # Create a table with LeveledCompactionStrategy and its params are 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', 'min_threshold': '4', 'sstable_size_in_mb': '2'（fanout_size and sstable_size_in_mb are too small just to make it easier to reproduce the problem）; # Insert data into the table by stress; # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 sstables(this level score bigger than 1.001) ERROR [CompactionExecutor:4] 2020-03-28 08:59:00,990 CassandraDaemon.java:442 - Exception in thread Thread[CompactionExecutor:4,1,main] java.lang.ArrayIndexOutOfBoundsException: 9 at org.apache.cassandra.db.compaction.LeveledManifest.getLevel(LeveledManifest.java:814) at org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:746) at org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:398) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:131) at org.apache.cassandra.db.compaction.CompactionStrategyHolder.lambda$getBackgroundTaskSuppliers$0(CompactionStrategyHolder.java:109) at org.apache.cassandra.db.compaction.AbstractStrategyHolder$TaskSupplier.getTask(AbstractStrategyHolder.java:66) at org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:214) at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:289) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) at java.util.concurrent.FutureTask.run(FutureTask.java) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) I tested it on cassandra version 3.11.3 & 4.0-alpha3. The exception all happened. was: cassandra will throw an ArrayIndexOutOfBoundsException when compact last level. My test is as follows： # Create a table with LeveledCompactionStrategy and its params are 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', 'min_threshold': '4', 'sstable_size_in_mb': '2'（fanout_size and sstable_size_in_mb are too small just to make it easier to reproduce the problem）; # Insert data into the table by stress; # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 sstables(this level score bigger than 1.001) I tested it on cassandra version 3.11.3 & 4.0-alpha3. The exception all happened. > LeveledCompactionStrategy compact last level throw an > ArrayIndexOutOfBoundsException > > > Key: CASSANDRA-15669 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15669 > Project: Cassandra > Issue Type: Bug >Reporter: sunhaihong >Assignee: sunhaihong >Priority: Normal > Attachments: cfs_compaction_info.png, error_info.png > > > Cassandra will throw an ArrayIndexOutOfBoundsException when compact last > level. > My test is as follows： > # Create a table with LeveledCompactionStrategy and its params are > 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', > 'min_threshold': '4', 'sstable_size_in_mb': '2'（fanout_size and > sstable_size_in_mb are too small just to make it easier to reproduce the > problem）; > # Insert data into the table by stress; > # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 > sstables(this level score bigger than 1.001) > ERROR [CompactionExecutor:4] 2020-03-28 08:59:00,990 CassandraDaemon.java:442 > - Exception in thread Thread[CompactionExecutor:4,1,main] > java.lang.ArrayIndexOutOfBoundsException: 9 > at > org.apache.cassandra.db.compaction.LeveledManifest.getLevel(LeveledManifest.java:814) > at > org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:746) > at > org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:398) > at > org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:131) > at > org.apache.cassandra.db.compaction.CompactionStrategyHolder.lambda$getBackgroundTaskSuppliers$0(CompactionStrategyHolder.java:109) > at >
[jira] [Created] (CASSANDRA-15671) Testcase: testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): FAILED
Ekaterina Dimitrova created CASSANDRA-15671: --- Summary: Testcase: testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): FAILED Key: CASSANDRA-15671 URL: https://issues.apache.org/jira/browse/CASSANDRA-15671 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova The following test failure was observed: [junit-timeout] Testcase: testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): FAILED [junit-timeout] expected:<4> but was:<5> [junit-timeout] junit.framework.AssertionFailedError: expected:<4> but was:<5> [junit-timeout] at org.apache.cassandra.db.compaction.CancelCompactionsTest.testSubrangeCompaction(CancelCompactionsTest.java:190) Java 8 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15672) Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec
Ekaterina Dimitrova created CASSANDRA-15672: --- Summary: Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec Key: CASSANDRA-15672 URL: https://issues.apache.org/jira/browse/CASSANDRA-15672 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova The following failure was observed: Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec [junit-timeout] [junit-timeout] Testcase: testMockedMessagingPrepareFailureP1(org.apache.cassandra.repair.consistent.CoordinatorMessagingTest): FAILED [junit-timeout] null [junit-timeout] junit.framework.AssertionFailedError [junit-timeout] at org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailure(CoordinatorMessagingTest.java:206) [junit-timeout] at org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailureP1(CoordinatorMessagingTest.java:154) [junit-timeout] [junit-timeout] Seen on Java8 -- 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-15671) Testcase: testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): FAILED
[ https://issues.apache.org/jira/browse/CASSANDRA-15671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15671: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: Test/unit Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Testcase: > testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): >FAILED > -- > > Key: CASSANDRA-15671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15671 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Priority: Normal > > The following test failure was observed: > [junit-timeout] Testcase: > testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): >FAILED > [junit-timeout] expected:<4> but was:<5> > [junit-timeout] junit.framework.AssertionFailedError: expected:<4> but was:<5> > [junit-timeout] at > org.apache.cassandra.db.compaction.CancelCompactionsTest.testSubrangeCompaction(CancelCompactionsTest.java:190) > Java 8 -- 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-15672) Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec
[ https://issues.apache.org/jira/browse/CASSANDRA-15672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15672: Fix Version/s: 4.0 > Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest > Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec > - > > Key: CASSANDRA-15672 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15672 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-beta > > > The following failure was observed: > Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest > Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec > [junit-timeout] > [junit-timeout] Testcase: > testMockedMessagingPrepareFailureP1(org.apache.cassandra.repair.consistent.CoordinatorMessagingTest): >FAILED > [junit-timeout] null > [junit-timeout] junit.framework.AssertionFailedError > [junit-timeout] at > org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailure(CoordinatorMessagingTest.java:206) > [junit-timeout] at > org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailureP1(CoordinatorMessagingTest.java:154) > [junit-timeout] > [junit-timeout] > Seen on Java8 -- 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-15671) Testcase: testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): FAILED
[ https://issues.apache.org/jira/browse/CASSANDRA-15671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15671: Fix Version/s: 4.0-beta 4.0 > Testcase: > testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): >FAILED > -- > > Key: CASSANDRA-15671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15671 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0, 4.0-beta > > > The following test failure was observed: > [junit-timeout] Testcase: > testSubrangeCompaction(org.apache.cassandra.db.compaction.CancelCompactionsTest): >FAILED > [junit-timeout] expected:<4> but was:<5> > [junit-timeout] junit.framework.AssertionFailedError: expected:<4> but was:<5> > [junit-timeout] at > org.apache.cassandra.db.compaction.CancelCompactionsTest.testSubrangeCompaction(CancelCompactionsTest.java:190) > Java 8 -- 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-15672) Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec
[ https://issues.apache.org/jira/browse/CASSANDRA-15672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15672: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: Test/unit Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest > Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec > - > > Key: CASSANDRA-15672 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15672 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Priority: Normal > > The following failure was observed: > Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest > Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec > [junit-timeout] > [junit-timeout] Testcase: > testMockedMessagingPrepareFailureP1(org.apache.cassandra.repair.consistent.CoordinatorMessagingTest): >FAILED > [junit-timeout] null > [junit-timeout] junit.framework.AssertionFailedError > [junit-timeout] at > org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailure(CoordinatorMessagingTest.java:206) > [junit-timeout] at > org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailureP1(CoordinatorMessagingTest.java:154) > [junit-timeout] > [junit-timeout] > Seen on Java8 -- 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-15672) Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec
[ https://issues.apache.org/jira/browse/CASSANDRA-15672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15672: Fix Version/s: 4.0-beta > Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest > Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec > - > > Key: CASSANDRA-15672 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15672 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-beta > > > The following failure was observed: > Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest > Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec > [junit-timeout] > [junit-timeout] Testcase: > testMockedMessagingPrepareFailureP1(org.apache.cassandra.repair.consistent.CoordinatorMessagingTest): >FAILED > [junit-timeout] null > [junit-timeout] junit.framework.AssertionFailedError > [junit-timeout] at > org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailure(CoordinatorMessagingTest.java:206) > [junit-timeout] at > org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailureP1(CoordinatorMessagingTest.java:154) > [junit-timeout] > [junit-timeout] > Seen on Java8 -- 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-15668) Jenkins 'Cassandra' label applied to the declarative pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-15668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068872#comment-17068872
]
David Capwell commented on CASSANDRA-15668:
---
LGTM +1
> Jenkins 'Cassandra' label applied to the declarative pipeline
> --
>
> Key: CASSANDRA-15668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15668
> Project: Cassandra
> Issue Type: Task
> Components: Build, Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> On the new ci-cassandra.apache.org infrastructure agents are siloed to
> projects.
> The declarative pipeline in the 2.2, 3.0, 3.11, and trunk branches do not
> restrict the builds to agents with the 'cassandra' label. Because these
> agents will not run jobs that don't specify this label, the pipeline task
> only ever runs on unlabelled agents, of which there are very few (and likely
> shouldn't exist because of misconfiguration).
> Example of the failure to run the pipeline tasks is
> {noformat}
> [Pipeline] Start of Pipeline
> [Pipeline] node
> Still waiting to schedule task
> 'cassandra10' is reserved for jobs with matching label expression;
> 'cassandra11' is reserved for jobs with matching label expression;
> 'cassandra12' is reserved for jobs with matching label expression;
> 'cassandra13' is reserved for jobs with matching label expression;
> 'cassandra14' is reserved for jobs with matching label expression;
> 'cassandra15' is reserved for jobs with matching label expression;
> 'cassandra16' is reserved for jobs with matching label expression;
> 'cassandra1' is reserved for jobs with matching label expression;
> 'cassandra2' is reserved for jobs with matching label expression;
> 'cassandra3' is reserved for jobs with matching label expression;
> 'cassandra4' is reserved for jobs with matching label expression;
> 'cassandra5' is reserved for jobs with matching label expression;
> 'cassandra6' is reserved for jobs with matching label expression;
> 'cassandra7' is reserved for jobs with matching label expression;
> 'cassandra8' is reserved for jobs with matching label expression;
> 'cassandra9' is reserved for jobs with matching label expression
> {noformat}
> Along with this change, we can improve the name of the
> {{*-test-jvm-dtest-forking}} stages.
--
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-15668) Jenkins 'Cassandra' label applied to the declarative pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-15668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15668:
--
Reviewers: David Capwell, David Capwell (was: David Capwell)
David Capwell, David Capwell
Status: Review In Progress (was: Patch Available)
verified the name in cassandra and Cassandra-build is exhaustive (relied on
grep). Also verified the label matches in cassandra-build
{code}
def slaveLabel = 'cassandra'
if(binding.hasVariable("CASSANDRA_SLAVE_LABEL")) {
slaveLabel = "${CASSANDRA_SLAVE_LABEL}"
}
...
job('Cassandra-template-artifacts') {
disabled(true)
description(jobDescription)
jdk(jdkLabel)
label(slaveLabel)
{code}
> Jenkins 'Cassandra' label applied to the declarative pipeline
> --
>
> Key: CASSANDRA-15668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15668
> Project: Cassandra
> Issue Type: Task
> Components: Build, Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> On the new ci-cassandra.apache.org infrastructure agents are siloed to
> projects.
> The declarative pipeline in the 2.2, 3.0, 3.11, and trunk branches do not
> restrict the builds to agents with the 'cassandra' label. Because these
> agents will not run jobs that don't specify this label, the pipeline task
> only ever runs on unlabelled agents, of which there are very few (and likely
> shouldn't exist because of misconfiguration).
> Example of the failure to run the pipeline tasks is
> {noformat}
> [Pipeline] Start of Pipeline
> [Pipeline] node
> Still waiting to schedule task
> 'cassandra10' is reserved for jobs with matching label expression;
> 'cassandra11' is reserved for jobs with matching label expression;
> 'cassandra12' is reserved for jobs with matching label expression;
> 'cassandra13' is reserved for jobs with matching label expression;
> 'cassandra14' is reserved for jobs with matching label expression;
> 'cassandra15' is reserved for jobs with matching label expression;
> 'cassandra16' is reserved for jobs with matching label expression;
> 'cassandra1' is reserved for jobs with matching label expression;
> 'cassandra2' is reserved for jobs with matching label expression;
> 'cassandra3' is reserved for jobs with matching label expression;
> 'cassandra4' is reserved for jobs with matching label expression;
> 'cassandra5' is reserved for jobs with matching label expression;
> 'cassandra6' is reserved for jobs with matching label expression;
> 'cassandra7' is reserved for jobs with matching label expression;
> 'cassandra8' is reserved for jobs with matching label expression;
> 'cassandra9' is reserved for jobs with matching label expression
> {noformat}
> Along with this change, we can improve the name of the
> {{*-test-jvm-dtest-forking}} stages.
--
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-15668) Jenkins 'Cassandra' label applied to the declarative pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-15668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068872#comment-17068872
]
David Capwell edited comment on CASSANDRA-15668 at 3/27/20, 4:51 PM:
-
LGTM +1
note: didn't test the Jenkins file change
was (Author: dcapwell):
LGTM +1
> Jenkins 'Cassandra' label applied to the declarative pipeline
> --
>
> Key: CASSANDRA-15668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15668
> Project: Cassandra
> Issue Type: Task
> Components: Build, Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> On the new ci-cassandra.apache.org infrastructure agents are siloed to
> projects.
> The declarative pipeline in the 2.2, 3.0, 3.11, and trunk branches do not
> restrict the builds to agents with the 'cassandra' label. Because these
> agents will not run jobs that don't specify this label, the pipeline task
> only ever runs on unlabelled agents, of which there are very few (and likely
> shouldn't exist because of misconfiguration).
> Example of the failure to run the pipeline tasks is
> {noformat}
> [Pipeline] Start of Pipeline
> [Pipeline] node
> Still waiting to schedule task
> 'cassandra10' is reserved for jobs with matching label expression;
> 'cassandra11' is reserved for jobs with matching label expression;
> 'cassandra12' is reserved for jobs with matching label expression;
> 'cassandra13' is reserved for jobs with matching label expression;
> 'cassandra14' is reserved for jobs with matching label expression;
> 'cassandra15' is reserved for jobs with matching label expression;
> 'cassandra16' is reserved for jobs with matching label expression;
> 'cassandra1' is reserved for jobs with matching label expression;
> 'cassandra2' is reserved for jobs with matching label expression;
> 'cassandra3' is reserved for jobs with matching label expression;
> 'cassandra4' is reserved for jobs with matching label expression;
> 'cassandra5' is reserved for jobs with matching label expression;
> 'cassandra6' is reserved for jobs with matching label expression;
> 'cassandra7' is reserved for jobs with matching label expression;
> 'cassandra8' is reserved for jobs with matching label expression;
> 'cassandra9' is reserved for jobs with matching label expression
> {noformat}
> Along with this change, we can improve the name of the
> {{*-test-jvm-dtest-forking}} stages.
--
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-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068858#comment-17068858 ] David Capwell commented on CASSANDRA-15539: --- +1 with feedback. There are a few things I want reverted and [~ifesdjeen] promised to do on-commit, so I trust he will =) There are things I want to have improved, but I am fine holding off and tacking in other JIRAs. > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 13h 20m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- 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-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15539: -- Reviewers: David Capwell, Dinesh Joshi, David Capwell (was: David Capwell, Dinesh Joshi) David Capwell, Dinesh Joshi, David Capwell (was: David Capwell, Dinesh Joshi) Status: Review In Progress (was: Patch Available) > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 13h 20m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- 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-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15539: -- Status: Patch Available (was: In Progress) > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 13h 20m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- 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-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15539: -- Status: In Progress (was: Changes Suggested) > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 13h 20m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- 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
