[jira] [Comment Edited] (CASSANDRA-16688) CircleCI - python dtests failing because of ccm issue
[
https://issues.apache.org/jira/browse/CASSANDRA-16688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349570#comment-17349570
]
Ekaterina Dimitrova edited comment on CASSANDRA-16688 at 5/22/21, 12:21 AM:
Unfortunately, it turned out the ninja fix solved only the issue for 4.0 and
trunk. I will work on full permanent solution on Monday. In the meanwhile,
Jenkins works properly. The ninja fix for 4.0 and trunk was committed.
was (Author: e.dimitrova):
Unfortunately, it turned out the ninja fix solved only the issue for 4.0 and
trunk. I will work on full permanent solution on Monday. In the meanwhile,
Jenkins works properly.
> CircleCI - python dtests failing because of ccm issue
> -
>
> Key: CASSANDRA-16688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16688
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Circle CI fails to run dtests.
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/483/workflows/e9a5f84e-e465-40e6-92f4-08e8632edf47/jobs/4315]
> {code:java}
> Obtaining ccm from git+
> [https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
> (from -r /home/cassandra/cassandra-dtest/requirements.txt (line 9))
> Updating ./env3.6/src/ccm clone (to revision cassandra-test)
> Running command git fetch -q --tags
> WARNING: Discarding git+
> [https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
> . Command errored out with exit status 1: git fetch -q --tags Check the logs
> for full command output.
> ERROR: Could not find a version that satisfies the requirement ccm
> (unavailable)
> ERROR: No matching distribution found for ccm (unavailable)
> WARNING: You are using pip version 21.0.1; however, version 21.1.1 is
> available.
> {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-16688) CircleCI - python dtests failing because of ccm issue
[
https://issues.apache.org/jira/browse/CASSANDRA-16688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349570#comment-17349570
]
Ekaterina Dimitrova commented on CASSANDRA-16688:
-
Unfortunately, it turned out the ninja fix solved only the issue for 4.0 and
trunk. I will work on full permanent solution on Monday. In the meanwhile,
Jenkins works properly.
> CircleCI - python dtests failing because of ccm issue
> -
>
> Key: CASSANDRA-16688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16688
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Circle CI fails to run dtests.
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/483/workflows/e9a5f84e-e465-40e6-92f4-08e8632edf47/jobs/4315]
> {code:java}
> Obtaining ccm from git+
> [https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
> (from -r /home/cassandra/cassandra-dtest/requirements.txt (line 9))
> Updating ./env3.6/src/ccm clone (to revision cassandra-test)
> Running command git fetch -q --tags
> WARNING: Discarding git+
> [https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
> . Command errored out with exit status 1: git fetch -q --tags Check the logs
> for full command output.
> ERROR: Could not find a version that satisfies the requirement ccm
> (unavailable)
> ERROR: No matching distribution found for ccm (unavailable)
> WARNING: You are using pip version 21.0.1; however, version 21.1.1 is
> available.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (1936f8e -> 36b1402)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 1936f8e ninja fix: temporary circle ccm fix add 1816f30 ninja fix: temporary circle ccm fix new 36b1402 Merge branch 'cassandra-4.0' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - 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-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 36b140288f57c7d01d59444ce81c3c919a312766 Merge: 1936f8e 1816f30 Author: Ekaterina Dimitrova AuthorDate: Fri May 21 20:17:47 2021 -0400 Merge branch 'cassandra-4.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated: ninja fix: temporary circle ccm fix
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-4.0 by this push: new 1816f30 ninja fix: temporary circle ccm fix 1816f30 is described below commit 1816f3020603e47a2cb6bde605b3c91277a1a6d9 Author: Ekaterina Dimitrova AuthorDate: Fri May 21 18:48:34 2021 -0400 ninja fix: temporary circle ccm fix --- .circleci/config-2_1.yml | 1 + .circleci/config.yml | 19 +++ .circleci/config.yml.HIGHRES | 19 +++ .circleci/config.yml.LOWRES | 19 +++ .circleci/config.yml.MIDRES | 19 +++ 5 files changed, 77 insertions(+) diff --git a/.circleci/config-2_1.yml b/.circleci/config-2_1.yml index 429ca79..a6d1e41 100644 --- a/.circleci/config-2_1.yml +++ b/.circleci/config-2_1.yml @@ -902,6 +902,7 @@ commands: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt build_cassandra: steps: diff --git a/.circleci/config.yml b/.circleci/config.yml index 822f246..a529f20 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -134,6 +134,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -325,6 +326,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -413,6 +415,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -502,6 +505,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -613,6 +617,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -724,6 +729,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -982,6 +988,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -1070,6 +1077,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/
[cassandra] branch trunk updated: ninja fix: temporary circle ccm fix
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 1936f8e ninja fix: temporary circle ccm fix 1936f8e is described below commit 1936f8e6fba986222a00c2183fcda8b899bf82b4 Author: Ekaterina Dimitrova AuthorDate: Fri May 21 18:48:34 2021 -0400 ninja fix: temporary circle ccm fix --- .circleci/config-2_1.yml | 1 + .circleci/config.yml | 19 +++ .circleci/config.yml.HIGHRES | 19 +++ .circleci/config.yml.LOWRES | 19 +++ .circleci/config.yml.MIDRES | 19 +++ 5 files changed, 77 insertions(+) diff --git a/.circleci/config-2_1.yml b/.circleci/config-2_1.yml index 429ca79..a6d1e41 100644 --- a/.circleci/config-2_1.yml +++ b/.circleci/config-2_1.yml @@ -902,6 +902,7 @@ commands: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt build_cassandra: steps: diff --git a/.circleci/config.yml b/.circleci/config.yml index 822f246..a529f20 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -134,6 +134,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -325,6 +326,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -413,6 +415,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -502,6 +505,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -613,6 +617,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -724,6 +729,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -982,6 +988,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandra-test;g' ~/cassandra-dtest/requirements.txt - run: name: Configure virtualenv and python Dependencies command: | @@ -1070,6 +1077,7 @@ jobs: name: Clone Cassandra dtest Repository (via git) command: | git clone --single-branch --branch $DTEST_BRANCH --depth 1 $DTEST_REPO ~/cassandra-dtest + sed -i 's;https://github.com/riptano/ccm.git@cassandra-test;git://github.com/riptano/ccm.git@cassandr
[jira] [Commented] (CASSANDRA-16683) StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown
[
https://issues.apache.org/jira/browse/CASSANDRA-16683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349567#comment-17349567
]
David Capwell commented on CASSANDRA-16683:
---
Python dtests were failing in the automation as CASSANDRA-16688 is impacting
them. When I manually tweak the builds they end up passing, so went ahead and
merged.
> StandaloneVerifier does not fail when unable to verify SSTables, it only
> fails if Corruption is thrown
> --
>
> Key: CASSANDRA-16683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16683
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python, Tool/sstable
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> offline_tools_test.py::TestOfflineTools::test_sstableverify has the following
> check
> {code}
>try:
>(out, error, rc) = node1.run_sstableverify("keyspace1",
> "standard1", options=['-v'])
>except ToolError as e:
># Process sstableverify output to normalize paths in string to
> Python casing as above
>error = re.sub("(?<=Corrupted: ).*", lambda match:
> os.path.normcase(match.group(0)), str(e))
>assert re.search("Corrupted: " + sstable1, error)
>assert e.exit_status == 1, str(e.exit_status)
> {code}
> This checks if the corrupt log is present IFF ToolError is thrown, but does
> not validate that the error is actually thrown. I tried calling the same
> logic before the try to validate and see that it does not fail. If we fix
> the test to check for error we also see that the log that is returned to the
> user does not match 2.2’s behavior but instead returns different logic as
> digest validation throws IOException, which we do not convert to a
> CorruptSSTableException (which is the message the test checks for).
> This also shows another big issue, that when the digest fails verify passes
--
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-16683) StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown
[
https://issues.apache.org/jira/browse/CASSANDRA-16683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349566#comment-17349566
]
David Capwell commented on CASSANDRA-16683:
---
dtest commit:
https://github.com/apache/cassandra-dtest/commit/dfeb14d53ecda8868293af0234c3955df07fd1cc
> StandaloneVerifier does not fail when unable to verify SSTables, it only
> fails if Corruption is thrown
> --
>
> Key: CASSANDRA-16683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16683
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python, Tool/sstable
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> offline_tools_test.py::TestOfflineTools::test_sstableverify has the following
> check
> {code}
>try:
>(out, error, rc) = node1.run_sstableverify("keyspace1",
> "standard1", options=['-v'])
>except ToolError as e:
># Process sstableverify output to normalize paths in string to
> Python casing as above
>error = re.sub("(?<=Corrupted: ).*", lambda match:
> os.path.normcase(match.group(0)), str(e))
>assert re.search("Corrupted: " + sstable1, error)
>assert e.exit_status == 1, str(e.exit_status)
> {code}
> This checks if the corrupt log is present IFF ToolError is thrown, but does
> not validate that the error is actually thrown. I tried calling the same
> logic before the try to validate and see that it does not fail. If we fix
> the test to check for error we also see that the log that is returned to the
> user does not match 2.2’s behavior but instead returns different logic as
> digest validation throws IOException, which we do not convert to a
> CorruptSSTableException (which is the message the test checks for).
> This also shows another big issue, that when the digest fails verify passes
--
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-16683) StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown
[
https://issues.apache.org/jira/browse/CASSANDRA-16683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16683:
--
Fix Version/s: (was: 4.0-rc)
(was: 3.11.x)
(was: 3.0.x)
4.0-rc2
3.11.11
3.0.25
Since Version: 2.2.0
Source Control Link:
https://github.com/apache/cassandra/commit/79e3669796430413287d4e6c256fc0bf1a7e5f30
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> StandaloneVerifier does not fail when unable to verify SSTables, it only
> fails if Corruption is thrown
> --
>
> Key: CASSANDRA-16683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16683
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python, Tool/sstable
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> offline_tools_test.py::TestOfflineTools::test_sstableverify has the following
> check
> {code}
>try:
>(out, error, rc) = node1.run_sstableverify("keyspace1",
> "standard1", options=['-v'])
>except ToolError as e:
># Process sstableverify output to normalize paths in string to
> Python casing as above
>error = re.sub("(?<=Corrupted: ).*", lambda match:
> os.path.normcase(match.group(0)), str(e))
>assert re.search("Corrupted: " + sstable1, error)
>assert e.exit_status == 1, str(e.exit_status)
> {code}
> This checks if the corrupt log is present IFF ToolError is thrown, but does
> not validate that the error is actually thrown. I tried calling the same
> logic before the try to validate and see that it does not fail. If we fix
> the test to check for error we also see that the log that is returned to the
> user does not match 2.2’s behavior but instead returns different logic as
> digest validation throws IOException, which we do not convert to a
> CorruptSSTableException (which is the message the test checks for).
> This also shows another big issue, that when the digest fails verify passes
--
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-dtest] branch trunk updated: StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new dfeb14d StandaloneVerifier does not fail when unable to verify
SSTables, it only fails if Corruption is thrown
dfeb14d is described below
commit dfeb14d53ecda8868293af0234c3955df07fd1cc
Author: David Capwell
AuthorDate: Fri May 21 15:50:06 2021 -0700
StandaloneVerifier does not fail when unable to verify SSTables, it only
fails if Corruption is thrown
patch by David Capwell; reviewed by Marcus Eriksson for CASSANDRA-16683
---
offline_tools_test.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/offline_tools_test.py b/offline_tools_test.py
index 8f6f98d..ecae6dd 100644
--- a/offline_tools_test.py
+++ b/offline_tools_test.py
@@ -290,11 +290,12 @@ class TestOfflineTools(Tester):
# use verbose to get some coverage on it
try:
(out, error, rc) = node1.run_sstableverify("keyspace1",
"standard1", options=['-v'])
+assert False, "sstable verify did not fail;
rc={}\nout={}\nerr={}".format(str(rc), out, error)
except ToolError as e:
# Process sstableverify output to normalize paths in string to
Python casing as above
-error = re.sub("(?<=Corrupted: ).*", lambda match:
os.path.normcase(match.group(0)), str(e))
+error = re.sub("(?<=WARNING: Corrupted SSTable : ).*", lambda
match: os.path.normcase(match.group(0)), str(e))
-assert re.search("Corrupted: " + sstable1, error)
+assert re.search("WARNING: Corrupted SSTable : " + sstable1, error)
assert e.exit_status == 1, str(e.exit_status)
def test_sstableexpiredblockers(self):
-
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-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 07504522c42ccd13ddd6fb3225400d84b1aa5777 Merge: 9f5886a d69ea28 Author: David Capwell AuthorDate: Fri May 21 16:55:19 2021 -0700 Merge branch 'cassandra-4.0' into trunk CHANGES.txt | 1 + .../org/apache/cassandra/db/compaction/Verifier.java| 12 ++-- .../org/apache/cassandra/tools/StandaloneVerifier.java | 17 - src/java/org/apache/cassandra/utils/OutputHandler.java | 4 4 files changed, 15 insertions(+), 19 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. dcapwell pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 54f73083a2bea2ce9b0a6cb7a2cb305b342f1b20 Merge: 24bd7d6 d2da11d Author: David Capwell AuthorDate: Fri May 21 16:51:49 2021 -0700 Merge branch 'cassandra-3.0' into cassandra-3.11 CHANGES.txt | 1 + .../org/apache/cassandra/tools/StandaloneVerifier.java | 17 - 2 files changed, 5 insertions(+), 13 deletions(-) diff --cc CHANGES.txt index 5fa97ae,784c550..2e419c9 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,12 -1,5 +1,13 @@@ -3.0.25: +3.11.11 + * Maps $CASSANDRA_LOG_DIR to cassandra.logdir java property when executing nodetool (CASSANDRA-16199) + * Nodetool garbagecollect should retain SSTableLevel for LCS (CASSANDRA-16634) + * Ignore stale acks received in the shadow round (CASSANDRA-16588) + * Add autocomplete and error messages for provide_overlapping_tombstones (CASSANDRA-16350) + * Add StorageServiceMBean.getKeyspaceReplicationInfo(keyspaceName) (CASSANDRA-16447) + * Make sure sstables with moved starts are removed correctly in LeveledGenerations (CASSANDRA-16552) + * Upgrade jackson-databind to 2.9.10.8 (CASSANDRA-16462) +Merged from 3.0: + * StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown (CASSANDRA-16683) * Fix bloom filter false ratio calculation by including true negatives (CASSANDRA-15834) * Prevent loss of commit log data when moving sstables between nodes (CASSANDRA-16619) * Fix materialized view builders inserting truncated data (CASSANDRA-16567) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit d69ea282162d4c69c8f75b352c5e0f863fc1b24e
Merge: 658f3e1 54f7308
Author: David Capwell
AuthorDate: Fri May 21 16:53:28 2021 -0700
Merge branch 'cassandra-3.11' into cassandra-4.0
CHANGES.txt | 1 +
.../org/apache/cassandra/db/compaction/Verifier.java| 12 ++--
.../org/apache/cassandra/tools/StandaloneVerifier.java | 17 -
src/java/org/apache/cassandra/utils/OutputHandler.java | 4
4 files changed, 15 insertions(+), 19 deletions(-)
diff --cc CHANGES.txt
index e84e3fe,2e419c9..e2305d1
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -14,7 -2,12 +14,8 @@@ Merged from 3.11
* Maps $CASSANDRA_LOG_DIR to cassandra.logdir java property when executing
nodetool (CASSANDRA-16199)
* Nodetool garbagecollect should retain SSTableLevel for LCS
(CASSANDRA-16634)
* Ignore stale acks received in the shadow round (CASSANDRA-16588)
- * Add autocomplete and error messages for provide_overlapping_tombstones
(CASSANDRA-16350)
- * Add StorageServiceMBean.getKeyspaceReplicationInfo(keyspaceName)
(CASSANDRA-16447)
- * Make sure sstables with moved starts are removed correctly in
LeveledGenerations (CASSANDRA-16552)
- * Upgrade jackson-databind to 2.9.10.8 (CASSANDRA-16462)
Merged from 3.0:
+ * StandaloneVerifier does not fail when unable to verify SSTables, it only
fails if Corruption is thrown (CASSANDRA-16683)
* Fix bloom filter false ratio calculation by including true negatives
(CASSANDRA-15834)
* Prevent loss of commit log data when moving sstables between nodes
(CASSANDRA-16619)
* Fix materialized view builders inserting truncated data (CASSANDRA-16567)
diff --cc src/java/org/apache/cassandra/db/compaction/Verifier.java
index 18b415c,8c5e8bb..30e74ad
--- a/src/java/org/apache/cassandra/db/compaction/Verifier.java
+++ b/src/java/org/apache/cassandra/db/compaction/Verifier.java
@@@ -143,72 -102,13 +143,72 @@@ public class Verifier implements Closea
}
catch (Throwable t)
{
- outputHandler.warn(t.getMessage());
-outputHandler.debug(t.getMessage());
-markAndThrow(false);
++outputHandler.warn(t);
+markAndThrow(t, false);
}
-outputHandler.output(String.format("Checking computed hash of %s ",
sstable));
+try
+{
+outputHandler.debug("Deserializing index for "+sstable);
+deserializeIndex(sstable);
+}
+catch (Throwable t)
+{
- outputHandler.warn(t.getMessage());
++outputHandler.warn(t);
+markAndThrow(t);
+}
+
+try
+{
+outputHandler.debug("Deserializing index summary for "+sstable);
+deserializeIndexSummary(sstable);
+}
+catch (Throwable t)
+{
+outputHandler.output("Index summary is corrupt - if it is removed
it will get rebuilt on startup
"+sstable.descriptor.filenameFor(Component.SUMMARY));
- outputHandler.warn(t.getMessage());
++outputHandler.warn(t);
+markAndThrow(t, false);
+}
+
+try
+{
+outputHandler.debug("Deserializing bloom filter for "+sstable);
+deserializeBloomFilter(sstable);
+
+}
+catch (Throwable t)
+{
- outputHandler.warn(t.getMessage());
++outputHandler.warn(t);
+markAndThrow(t);
+}
+
+if (options.checkOwnsTokens && !isOffline && !(cfs.getPartitioner()
instanceof LocalPartitioner))
+{
+outputHandler.debug("Checking that all tokens are owned by the
current node");
+try (KeyIterator iter = new KeyIterator(sstable.descriptor,
sstable.metadata()))
+{
+List> ownedRanges =
Range.normalize(tokenLookup.apply(cfs.metadata.keyspace));
+if (ownedRanges.isEmpty())
+return;
+RangeOwnHelper rangeOwnHelper = new
RangeOwnHelper(ownedRanges);
+while (iter.hasNext())
+{
+DecoratedKey key = iter.next();
+rangeOwnHelper.validate(key);
+}
+}
+catch (Throwable t)
+{
- outputHandler.warn(t.getMessage());
++outputHandler.warn(t);
+markAndThrow(t);
+}
+}
+
+if (options.quick)
+return;
// Verify will use the Digest files, which works for both compressed
and uncompressed sstables
+outputHandler.output(String.format("Checking computed hash of %s ",
sstable));
try
{
[cassandra] branch cassandra-4.0 updated (658f3e1 -> d69ea28)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 658f3e1 Improve AuditLogging documentation and logback.xml authored by Ekaterina Dimitrova, reviewed by Sarma Pydipally, Brandon Williams for CASSANDRA-16682 new d2da11d StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown new 54f7308 Merge branch 'cassandra-3.0' into cassandra-3.11 new d69ea28 Merge branch 'cassandra-3.11' into cassandra-4.0 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: CHANGES.txt | 1 + .../org/apache/cassandra/db/compaction/Verifier.java| 12 ++-- .../org/apache/cassandra/tools/StandaloneVerifier.java | 17 - src/java/org/apache/cassandra/utils/OutputHandler.java | 4 4 files changed, 15 insertions(+), 19 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 (24bd7d6 -> 54f7308)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 24bd7d6 Merge branch 'cassandra-3.0' into cassandra-3.11 new d2da11d StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown new 54f7308 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 1 + .../org/apache/cassandra/tools/StandaloneVerifier.java | 17 - 2 files changed, 5 insertions(+), 13 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (9f5886a -> 0750452)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 9f5886a Merge branch 'cassandra-4.0' into trunk new d2da11d StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown new 54f7308 Merge branch 'cassandra-3.0' into cassandra-3.11 new d69ea28 Merge branch 'cassandra-3.11' into cassandra-4.0 new 0750452 Merge branch 'cassandra-4.0' 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: CHANGES.txt | 1 + .../org/apache/cassandra/db/compaction/Verifier.java| 12 ++-- .../org/apache/cassandra/tools/StandaloneVerifier.java | 17 - src/java/org/apache/cassandra/utils/OutputHandler.java | 4 4 files changed, 15 insertions(+), 19 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: StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new d2da11d StandaloneVerifier does not fail when unable to verify
SSTables, it only fails if Corruption is thrown
d2da11d is described below
commit d2da11d537723259f9c89d1e30ed967e0938ad60
Author: David Capwell
AuthorDate: Fri May 21 15:50:14 2021 -0700
StandaloneVerifier does not fail when unable to verify SSTables, it only
fails if Corruption is thrown
patch by David Capwell; reviewed by Marcus Eriksson for CASSANDRA-16683
---
CHANGES.txt | 1 +
.../org/apache/cassandra/tools/StandaloneVerifier.java | 17 -
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 0ce3375..784c550 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.25:
+ * StandaloneVerifier does not fail when unable to verify SSTables, it only
fails if Corruption is thrown (CASSANDRA-16683)
* Fix bloom filter false ratio calculation by including true negatives
(CASSANDRA-15834)
* Prevent loss of commit log data when moving sstables between nodes
(CASSANDRA-16619)
* Fix materialized view builders inserting truncated data (CASSANDRA-16567)
diff --git a/src/java/org/apache/cassandra/tools/StandaloneVerifier.java
b/src/java/org/apache/cassandra/tools/StandaloneVerifier.java
index d358882..a8e72bd 100644
--- a/src/java/org/apache/cassandra/tools/StandaloneVerifier.java
+++ b/src/java/org/apache/cassandra/tools/StandaloneVerifier.java
@@ -95,23 +95,14 @@ public class StandaloneVerifier
for (SSTableReader sstable : sstables)
{
-try
+try (Verifier verifier = new Verifier(cfs, sstable, handler,
true))
{
-
-try (Verifier verifier = new Verifier(cfs, sstable,
handler, true))
-{
-verifier.verify(extended);
-}
-catch (CorruptSSTableException cs)
-{
-System.err.println(String.format("Error verifying %s:
%s", sstable, cs.getMessage()));
-hasFailed = true;
-}
+verifier.verify(extended);
}
catch (Exception e)
{
-System.err.println(String.format("Error verifying %s: %s",
sstable, e.getMessage()));
-e.printStackTrace(System.err);
+handler.warn(String.format("Error verifying %s: %s",
sstable, e.getMessage()), e);
+hasFailed = true;
}
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16683) StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown
[
https://issues.apache.org/jira/browse/CASSANDRA-16683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349555#comment-17349555
]
David Capwell commented on CASSANDRA-16683:
---
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|cassandra-3.0|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16683-cassandra-3.0-EE2779F4-1496-4C96-B603-E79E9C948014]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16683-cassandra-3.0-EE2779F4-1496-4C96-B603-E79E9C948014]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/797/]|
|cassandra-3.11|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16683-cassandra-3.11-EE2779F4-1496-4C96-B603-E79E9C948014]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16683-cassandra-3.11-EE2779F4-1496-4C96-B603-E79E9C948014]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/798/]|
|cassandra-4.0|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16683-cassandra-4.0-EE2779F4-1496-4C96-B603-E79E9C948014]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16683-cassandra-4.0-EE2779F4-1496-4C96-B603-E79E9C948014]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/799/]|
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16683-trunk-EE2779F4-1496-4C96-B603-E79E9C948014]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16683-trunk-EE2779F4-1496-4C96-B603-E79E9C948014]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/800/]|
> StandaloneVerifier does not fail when unable to verify SSTables, it only
> fails if Corruption is thrown
> --
>
> Key: CASSANDRA-16683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16683
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python, Tool/sstable
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> offline_tools_test.py::TestOfflineTools::test_sstableverify has the following
> check
> {code}
>try:
>(out, error, rc) = node1.run_sstableverify("keyspace1",
> "standard1", options=['-v'])
>except ToolError as e:
># Process sstableverify output to normalize paths in string to
> Python casing as above
>error = re.sub("(?<=Corrupted: ).*", lambda match:
> os.path.normcase(match.group(0)), str(e))
>assert re.search("Corrupted: " + sstable1, error)
>assert e.exit_status == 1, str(e.exit_status)
> {code}
> This checks if the corrupt log is present IFF ToolError is thrown, but does
> not validate that the error is actually thrown. I tried calling the same
> logic before the try to validate and see that it does not fail. If we fix
> the test to check for error we also see that the log that is returned to the
> user does not match 2.2’s behavior but instead returns different logic as
> digest validation throws IOException, which we do not convert to a
> CorruptSSTableException (which is the message the test checks for).
> This also shows another big issue, that when the digest fails verify passes
--
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-16683) StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown
[
https://issues.apache.org/jira/browse/CASSANDRA-16683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349500#comment-17349500
]
David Capwell commented on CASSANDRA-16683:
---
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|cassandra-3.0|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16683-cassandra-3.0-60A366A1-0D9E-42A6-A7AF-06A338809BF6]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16683-cassandra-3.0-60A366A1-0D9E-42A6-A7AF-06A338809BF6]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/793/]|
|cassandra-3.11|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16683-cassandra-3.11-60A366A1-0D9E-42A6-A7AF-06A338809BF6]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16683-cassandra-3.11-60A366A1-0D9E-42A6-A7AF-06A338809BF6]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/794/]|
|cassandra-4.0|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16683-cassandra-4.0-60A366A1-0D9E-42A6-A7AF-06A338809BF6]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16683-cassandra-4.0-60A366A1-0D9E-42A6-A7AF-06A338809BF6]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/795/]|
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16683-trunk-60A366A1-0D9E-42A6-A7AF-06A338809BF6]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16683-trunk-60A366A1-0D9E-42A6-A7AF-06A338809BF6]|[build|unknown]|
> StandaloneVerifier does not fail when unable to verify SSTables, it only
> fails if Corruption is thrown
> --
>
> Key: CASSANDRA-16683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16683
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python, Tool/sstable
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> offline_tools_test.py::TestOfflineTools::test_sstableverify has the following
> check
> {code}
>try:
>(out, error, rc) = node1.run_sstableverify("keyspace1",
> "standard1", options=['-v'])
>except ToolError as e:
># Process sstableverify output to normalize paths in string to
> Python casing as above
>error = re.sub("(?<=Corrupted: ).*", lambda match:
> os.path.normcase(match.group(0)), str(e))
>assert re.search("Corrupted: " + sstable1, error)
>assert e.exit_status == 1, str(e.exit_status)
> {code}
> This checks if the corrupt log is present IFF ToolError is thrown, but does
> not validate that the error is actually thrown. I tried calling the same
> logic before the try to validate and see that it does not fail. If we fix
> the test to check for error we also see that the log that is returned to the
> user does not match 2.2’s behavior but instead returns different logic as
> digest validation throws IOException, which we do not convert to a
> CorruptSSTableException (which is the message the test checks for).
> This also shows another big issue, that when the digest fails verify passes
--
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-16683) StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown
[
https://issues.apache.org/jira/browse/CASSANDRA-16683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16683:
--
Summary: StandaloneVerifier does not fail when unable to verify SSTables,
it only fails if Corruption is thrown (was:
offline_tools_test.py::TestOfflineTools::test_sstableverify does not validate
that verify fails so has not been doing its check since 3.0)
> StandaloneVerifier does not fail when unable to verify SSTables, it only
> fails if Corruption is thrown
> --
>
> Key: CASSANDRA-16683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16683
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python, Tool/sstable
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> offline_tools_test.py::TestOfflineTools::test_sstableverify has the following
> check
> {code}
>try:
>(out, error, rc) = node1.run_sstableverify("keyspace1",
> "standard1", options=['-v'])
>except ToolError as e:
># Process sstableverify output to normalize paths in string to
> Python casing as above
>error = re.sub("(?<=Corrupted: ).*", lambda match:
> os.path.normcase(match.group(0)), str(e))
>assert re.search("Corrupted: " + sstable1, error)
>assert e.exit_status == 1, str(e.exit_status)
> {code}
> This checks if the corrupt log is present IFF ToolError is thrown, but does
> not validate that the error is actually thrown. I tried calling the same
> logic before the try to validate and see that it does not fail. If we fix
> the test to check for error we also see that the log that is returned to the
> user does not match 2.2’s behavior but instead returns different logic as
> digest validation throws IOException, which we do not convert to a
> CorruptSSTableException (which is the message the test checks for).
> This also shows another big issue, that when the digest fails verify passes
--
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-16688) CircleCI - python dtests failing because of ccm issue
[
https://issues.apache.org/jira/browse/CASSANDRA-16688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349483#comment-17349483
]
Ekaterina Dimitrova commented on CASSANDRA-16688:
-
I think the latest ccm patch which triggered us to see retag hasn't been done
recently is still not committed. [~dcapwell] found a workaround which I plan to
ninja fix until Monday when we can commit that patch (want to double-check with
[~Bereng] whether the mentioned commit should be really committed or he had
some concerns), retag CCM and rebuild the docker image (I am positive that will
solve the problem). I am also not sure whether I will have the rights to push a
new image on docker hub actually.
> CircleCI - python dtests failing because of ccm issue
> -
>
> Key: CASSANDRA-16688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16688
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Circle CI fails to run dtests.
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/483/workflows/e9a5f84e-e465-40e6-92f4-08e8632edf47/jobs/4315]
> {code:java}
> Obtaining ccm from git+
> [https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
> (from -r /home/cassandra/cassandra-dtest/requirements.txt (line 9))
> Updating ./env3.6/src/ccm clone (to revision cassandra-test)
> Running command git fetch -q --tags
> WARNING: Discarding git+
> [https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
> . Command errored out with exit status 1: git fetch -q --tags Check the logs
> for full command output.
> ERROR: Could not find a version that satisfies the requirement ccm
> (unavailable)
> ERROR: No matching distribution found for ccm (unavailable)
> WARNING: You are using pip version 21.0.1; however, version 21.1.1 is
> available.
> {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-16672) Retag ccm
[
https://issues.apache.org/jira/browse/CASSANDRA-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349481#comment-17349481
]
Ekaterina Dimitrova commented on CASSANDRA-16672:
-
[~bereng], I think the latest ccm patch which triggered you to see retag hasn't
been recently is still not committed. [~dcapwell] found a workaround which I
plan to ninja fix until Monday when we can commit that patch (want to
double-check with you whether it should be really committed or you had some
concerns), retag CCM and rebuild the docker image (I am positive that will
solve the problem). I am also not sure whether I will have the rights to push a
new image on docker hub.
> Retag ccm
> -
>
> Key: CASSANDRA-16672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16672
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 3.0.x, 3.11.x, 4.x
>
>
> CCM repro's trunk is several commits ahead from {{cassandra-test}} tag.
> Probably an oversight but retagging needs CI to be ran just to make sure
> nothing broke in between.
--
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-16672) Retag ccm
[
https://issues.apache.org/jira/browse/CASSANDRA-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349461#comment-17349461
]
Ekaterina Dimitrova commented on CASSANDRA-16672:
-
CASSANDRA-16688 ticket opened. Thinking out loud, I guess there are some
specifics around the tags and the CI was run on a custom branch, probably so
not being able to catch this issue. Let's see whether the rebuild will help
> Retag ccm
> -
>
> Key: CASSANDRA-16672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16672
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 3.0.x, 3.11.x, 4.x
>
>
> CCM repro's trunk is several commits ahead from {{cassandra-test}} tag.
> Probably an oversight but retagging needs CI to be ran just to make sure
> nothing broke in between.
--
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-16688) CircleCI - python dtests failing because of ccm issue
[
https://issues.apache.org/jira/browse/CASSANDRA-16688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-16688:
---
Assignee: Ekaterina Dimitrova
> CircleCI - python dtests failing because of ccm issue
> -
>
> Key: CASSANDRA-16688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16688
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Circle CI fails to run dtests.
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/483/workflows/e9a5f84e-e465-40e6-92f4-08e8632edf47/jobs/4315]
> {code:java}
> Obtaining ccm from git+
> [https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
> (from -r /home/cassandra/cassandra-dtest/requirements.txt (line 9))
> Updating ./env3.6/src/ccm clone (to revision cassandra-test)
> Running command git fetch -q --tags
> WARNING: Discarding git+
> [https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
> . Command errored out with exit status 1: git fetch -q --tags Check the logs
> for full command output.
> ERROR: Could not find a version that satisfies the requirement ccm
> (unavailable)
> ERROR: No matching distribution found for ccm (unavailable)
> WARNING: You are using pip version 21.0.1; however, version 21.1.1 is
> available.
> {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-16688) CircleCI - python dtests failing because of ccm issue
[
https://issues.apache.org/jira/browse/CASSANDRA-16688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16688:
Bug Category: Parent values: Degradation(12984)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> CircleCI - python dtests failing because of ccm issue
> -
>
> Key: CASSANDRA-16688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16688
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Circle CI fails to run dtests.
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/483/workflows/e9a5f84e-e465-40e6-92f4-08e8632edf47/jobs/4315]
> {code:java}
> Obtaining ccm from git+
> [https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
> (from -r /home/cassandra/cassandra-dtest/requirements.txt (line 9))
> Updating ./env3.6/src/ccm clone (to revision cassandra-test)
> Running command git fetch -q --tags
> WARNING: Discarding git+
> [https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
> . Command errored out with exit status 1: git fetch -q --tags Check the logs
> for full command output.
> ERROR: Could not find a version that satisfies the requirement ccm
> (unavailable)
> ERROR: No matching distribution found for ccm (unavailable)
> WARNING: You are using pip version 21.0.1; however, version 21.1.1 is
> available.
> {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] [Created] (CASSANDRA-16688) CircleCI - python dtests failing because of ccm issue
Ekaterina Dimitrova created CASSANDRA-16688:
---
Summary: CircleCI - python dtests failing because of ccm issue
Key: CASSANDRA-16688
URL: https://issues.apache.org/jira/browse/CASSANDRA-16688
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Circle CI fails to run dtests.
[https://app.circleci.com/pipelines/github/adelapena/cassandra/483/workflows/e9a5f84e-e465-40e6-92f4-08e8632edf47/jobs/4315]
{code:java}
Obtaining ccm from git+
[https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
(from -r /home/cassandra/cassandra-dtest/requirements.txt (line 9))
Updating ./env3.6/src/ccm clone (to revision cassandra-test)
Running command git fetch -q --tags
WARNING: Discarding git+
[https://github.com/riptano/ccm.git@cassandra-test#egg=ccm]
. Command errored out with exit status 1: git fetch -q --tags Check the logs
for full command output.
ERROR: Could not find a version that satisfies the requirement ccm (unavailable)
ERROR: No matching distribution found for ccm (unavailable)
WARNING: You are using pip version 21.0.1; however, version 21.1.1 is available.
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16672) Retag ccm
[
https://issues.apache.org/jira/browse/CASSANDRA-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349447#comment-17349447
]
Ekaterina Dimitrova edited comment on CASSANDRA-16672 at 5/21/21, 7:14 PM:
---
[~adelapena] mentioned he had that issue too. I haven't tested it myself but if
you say you see it too, it means it wasn't something random.
Andres managed also to reproduce it locally running {{pip install -r
requirements.txt}} in his local python venv. It works after dropping the old
copy of the ccm repo that he had in his venv, on the {{src}} dir of the venv.
As for CircleCI, it says here that the dependencies are already installed on
the Docker image:
[https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L1109-L1117]
Might be that we need to rebuild the docker image, not sure. As the retagging
is just change of hash, no new dependencies added, this is weird. Also, I see
CI being run successfully before the commit but seems Berenguer cleaned already
his repo and I can't see the commits to verify if something has been missing
there.
was (Author: e.dimitrova):
[~adelapena] mentioned he had that issue too. I haven't tested it myself but if
you say you see it too, it means it wasn't something random.
Andres managed also to reproduce it locally running {{pip install -r
requirements.txt}} in his local python venv. It works after dropping the old
copy of the ccm repo that he had in his venv, on the {{src}} dir of the venv.
As for CircleCI, it says here that the dependencies are already installed on
the Docker image:
[https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L1109-L1117]
Might be that we need to rebuild the docker image, not sure. As the retagging
is just change of hash, no new dependencies added. Also, I see CI being run
successfully before the commit but seems Berenguer cleaned already his repo and
I can't see the commits to verify if something has been missing there.
> Retag ccm
> -
>
> Key: CASSANDRA-16672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16672
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 3.0.x, 3.11.x, 4.x
>
>
> CCM repro's trunk is several commits ahead from {{cassandra-test}} tag.
> Probably an oversight but retagging needs CI to be ran just to make sure
> nothing broke in between.
--
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-16672) Retag ccm
[
https://issues.apache.org/jira/browse/CASSANDRA-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349447#comment-17349447
]
Ekaterina Dimitrova commented on CASSANDRA-16672:
-
[~adelapena] mentioned he had that issue too. I haven't tested it myself but if
you say you see it too, it means it wasn't something random.
Andres managed also to reproduce it locally running {{pip install -r
requirements.txt}} in his local python venv. It works after dropping the old
copy of the ccm repo that he had in his venv, on the {{src}} dir of the venv.
As for CircleCI, it says here that the dependencies are already installed on
the Docker image:
[https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L1109-L1117]
Might be that we need to rebuild the docker image, not sure. As the retagging
is just change of hash, no new dependencies added. Also, I see CI being run
successfully before the commit but seems Berenguer cleaned already his repo and
I can't see the commits to verify if something has been missing there.
> Retag ccm
> -
>
> Key: CASSANDRA-16672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16672
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 3.0.x, 3.11.x, 4.x
>
>
> CCM repro's trunk is several commits ahead from {{cassandra-test}} tag.
> Probably an oversight but retagging needs CI to be ran just to make sure
> nothing broke in between.
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16682:
Fix Version/s: 4.0.x
4.0
Since Version: 4.0-rc1
Source Control Link:
https://github.com/apache/cassandra/commit/658f3e11a66aca7333157a9b20bf7189005329cf
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.0-rc, 4.0.x
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16682:
Status: Ready to Commit (was: Review In Progress)
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349445#comment-17349445
]
Ekaterina Dimitrova commented on CASSANDRA-16682:
-
Thank you both, the patch was committed to 4.0 and trunk. I also checked
locally the doc build. I took care of the super-duper-ultra-nit on commit :)
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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 cassandra-4.0 updated (8cd02af -> 658f3e1)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 8cd02af Spin up SEPWorker threads whenever we grow the number of work permits authored by Matt Fleming, reviewed by Jon Meredith, Andres de la Pena, Ekaterina Dimitrova for CASSANDRA-16668 add 658f3e1 Improve AuditLogging documentation and logback.xml authored by Ekaterina Dimitrova, reviewed by Sarma Pydipally, Brandon Williams for CASSANDRA-16682 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + conf/logback.xml | 23 doc/source/new/auditlogging.rst| 47 +++ doc/source/operating/audit_logging.rst | 236 - 4 files changed, 71 insertions(+), 236 deletions(-) delete mode 100644 doc/source/operating/audit_logging.rst - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (1112cdf -> 9f5886a)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 1112cdf Merge branch 'cassandra-4.0' into trunk add 658f3e1 Improve AuditLogging documentation and logback.xml authored by Ekaterina Dimitrova, reviewed by Sarma Pydipally, Brandon Williams for CASSANDRA-16682 new 9f5886a Merge branch 'cassandra-4.0' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + conf/logback.xml | 23 doc/source/new/auditlogging.rst| 47 +++ doc/source/operating/audit_logging.rst | 236 - 4 files changed, 71 insertions(+), 236 deletions(-) delete mode 100644 doc/source/operating/audit_logging.rst - 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-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 9f5886a4b8894c733e53c34457adae82034f9380 Merge: 1112cdf 658f3e1 Author: Ekaterina Dimitrova AuthorDate: Fri May 21 14:44:41 2021 -0400 Merge branch 'cassandra-4.0' into trunk CHANGES.txt| 1 + conf/logback.xml | 23 doc/source/new/auditlogging.rst| 47 +++ doc/source/operating/audit_logging.rst | 236 - 4 files changed, 71 insertions(+), 236 deletions(-) diff --cc CHANGES.txt index a739bd6,e84e3fe..b7690db --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,6 -1,5 +1,7 @@@ -4.0-rc2 +4.1 + * GossiperTest.testHasVersion3Nodes didn't take into account trunk version changes, fixed to rely on latest version (CASSANDRA-16651) +Merged from 4.0: + * Improve AuditLogging documentation and logback.xml(CASSANDRA-16682) * Spin up SEPWorker threads whenever we grow the number of work permits(CASSANDRA-16668) * Add a warning to cqlsh 6.0.0 that DESCRIBE does not work with a Cassandra 3.x servers (CASSANDRA-16652) * cqlsh: fix DESC TYPE with non-ascii character in the identifier (CASSANDRA-16400) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16682:
Reviewers: Brandon Williams, Sarma Pydipally (was: Brandon Williams,
Ekaterina Dimitrova)
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16672) Retag ccm
[
https://issues.apache.org/jira/browse/CASSANDRA-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349434#comment-17349434
]
David Capwell commented on CASSANDRA-16672:
---
Any idea why the following is happening?
{code}
bash-4.2$ pip3 install --upgrade
git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
Collecting ccm from
git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
Cloning https://github.com/riptano/ccm.git (to cassandra-test) to
/tmp/pip-build-zytofrkv/ccm
error: RPC failed; curl 56 TCP connection reset by peer
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
Command "git clone -q https://github.com/riptano/ccm.git
/tmp/pip-build-zytofrkv/ccm" failed with error code 128 in None
You are using pip version 9.0.1, however version 21.1.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
{code}
https://app.circleci.com/pipelines/github/dcapwell/cassandra/921/workflows/3cae536f-f429-40e6-b739-9212b203cd58/jobs/5578
python dtest builds are all failing to checkout ccm
> Retag ccm
> -
>
> Key: CASSANDRA-16672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16672
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 3.0.x, 3.11.x, 4.x
>
>
> CCM repro's trunk is several commits ahead from {{cassandra-test}} tag.
> Probably an oversight but retagging needs CI to be ran just to make sure
> nothing broke in between.
--
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-16668) Intermittent failure of SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race condition when shrinking maximum pool size to zero
[
https://issues.apache.org/jira/browse/CASSANDRA-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16668:
Since Version: (was: 4.0-rc1)
> Intermittent failure of
> SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race
> condition when shrinking maximum pool size to zero
> -
>
> Key: CASSANDRA-16668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16668
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Matt Fleming
>Assignee: Matt Fleming
>Priority: Normal
> Fix For: 4.0, 4.0-rc, 4.0.x
>
>
> A difficult-to-hit race condition exists in
> changingMaxWorkersMeetsConcurrencyGoalsTest when changing the maximum pool
> size from 0 -> 4 which results in the test failing like so:
> {{junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but
> was:junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but was: at
> org.apache.cassandra.concurrent.SEPExecutorTest.assertMaxTaskConcurrency(SEPExecutorTest.java:198)
> at
> org.apache.cassandra.concurrent.SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest(SEPExecutorTest.java:132)}}
> I can hit this issue maybe 2/3 times for every 100 invocations of the unit
> test.
> The issue that causes the failure is that if tasks are still enqueued when
> the maximum pool size is set to zero and if all of the SEPWorker threads
> enter the STOP state before the pool size is bumped to 4, then no SEPWorker
> threads will be spun up to service the task queue. This causes the above
> error.
> Why don't we spin up SEPWorker threads when enqueing tasks? Because of the
> guard logic in addTask:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/concurrent/SEPExecutor.java#L113,L121]
> In this scenario taskPermits will not be zero (because we have tasks on the
> queue) so we never call {{maybeStartSpinningWorker()}}.
> A trick to make this issue much easier to hit is to insert a
> {{Thread.sleep(500)}} immediately after setting the pool size to zero. This
> has the effect of guaranteeing that all SEPWorker threads will be STOP'd
> before enqueueing more work.
> Here's a fix that attempts to spin up an SEPWorker whenever we grow the
> number of work permits:
> https://github.com/mfleming/cassandra/commit/071516d29e41da9924af24e8002822d3c6af0e01
--
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-16668) Intermittent failure of SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race condition when shrinking maximum pool size to zero
[
https://issues.apache.org/jira/browse/CASSANDRA-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16668:
Fix Version/s: 4.0.x
4.0
Since Version: 4.0-rc1
Source Control Link:
https://github.com/apache/cassandra/commit/8cd02afce972ecaf0e0cf0fe09c610d67d9af9c5
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Intermittent failure of
> SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race
> condition when shrinking maximum pool size to zero
> -
>
> Key: CASSANDRA-16668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16668
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Matt Fleming
>Assignee: Matt Fleming
>Priority: Normal
> Fix For: 4.0, 4.0-rc, 4.0.x
>
>
> A difficult-to-hit race condition exists in
> changingMaxWorkersMeetsConcurrencyGoalsTest when changing the maximum pool
> size from 0 -> 4 which results in the test failing like so:
> {{junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but
> was:junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but was: at
> org.apache.cassandra.concurrent.SEPExecutorTest.assertMaxTaskConcurrency(SEPExecutorTest.java:198)
> at
> org.apache.cassandra.concurrent.SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest(SEPExecutorTest.java:132)}}
> I can hit this issue maybe 2/3 times for every 100 invocations of the unit
> test.
> The issue that causes the failure is that if tasks are still enqueued when
> the maximum pool size is set to zero and if all of the SEPWorker threads
> enter the STOP state before the pool size is bumped to 4, then no SEPWorker
> threads will be spun up to service the task queue. This causes the above
> error.
> Why don't we spin up SEPWorker threads when enqueing tasks? Because of the
> guard logic in addTask:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/concurrent/SEPExecutor.java#L113,L121]
> In this scenario taskPermits will not be zero (because we have tasks on the
> queue) so we never call {{maybeStartSpinningWorker()}}.
> A trick to make this issue much easier to hit is to insert a
> {{Thread.sleep(500)}} immediately after setting the pool size to zero. This
> has the effect of guaranteeing that all SEPWorker threads will be STOP'd
> before enqueueing more work.
> Here's a fix that attempts to spin up an SEPWorker whenever we grow the
> number of work permits:
> https://github.com/mfleming/cassandra/commit/071516d29e41da9924af24e8002822d3c6af0e01
--
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-16668) Intermittent failure of SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race condition when shrinking maximum pool size to zero
[
https://issues.apache.org/jira/browse/CASSANDRA-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349431#comment-17349431
]
Ekaterina Dimitrova commented on CASSANDRA-16668:
-
Committed to 4.0 and propagated to trunk. Thank you all!
> Intermittent failure of
> SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race
> condition when shrinking maximum pool size to zero
> -
>
> Key: CASSANDRA-16668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16668
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Matt Fleming
>Assignee: Matt Fleming
>Priority: Normal
> Fix For: 4.0-rc
>
>
> A difficult-to-hit race condition exists in
> changingMaxWorkersMeetsConcurrencyGoalsTest when changing the maximum pool
> size from 0 -> 4 which results in the test failing like so:
> {{junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but
> was:junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but was: at
> org.apache.cassandra.concurrent.SEPExecutorTest.assertMaxTaskConcurrency(SEPExecutorTest.java:198)
> at
> org.apache.cassandra.concurrent.SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest(SEPExecutorTest.java:132)}}
> I can hit this issue maybe 2/3 times for every 100 invocations of the unit
> test.
> The issue that causes the failure is that if tasks are still enqueued when
> the maximum pool size is set to zero and if all of the SEPWorker threads
> enter the STOP state before the pool size is bumped to 4, then no SEPWorker
> threads will be spun up to service the task queue. This causes the above
> error.
> Why don't we spin up SEPWorker threads when enqueing tasks? Because of the
> guard logic in addTask:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/concurrent/SEPExecutor.java#L113,L121]
> In this scenario taskPermits will not be zero (because we have tasks on the
> queue) so we never call {{maybeStartSpinningWorker()}}.
> A trick to make this issue much easier to hit is to insert a
> {{Thread.sleep(500)}} immediately after setting the pool size to zero. This
> has the effect of guaranteeing that all SEPWorker threads will be STOP'd
> before enqueueing more work.
> Here's a fix that attempts to spin up an SEPWorker whenever we grow the
> number of work permits:
> https://github.com/mfleming/cassandra/commit/071516d29e41da9924af24e8002822d3c6af0e01
--
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 (9a43241 -> 1112cdf)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 9a43241 Ninja: fix incorrect import for guava lib in row util add 8cd02af Spin up SEPWorker threads whenever we grow the number of work permits authored by Matt Fleming, reviewed by Jon Meredith, Andres de la Pena, Ekaterina Dimitrova for CASSANDRA-16668 new 1112cdf Merge branch 'cassandra-4.0' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/concurrent/SEPExecutor.java | 6 + .../cassandra/concurrent/SEPExecutorTest.java | 149 +++-- 3 files changed, 113 insertions(+), 43 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-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 1112cdf83c36cca8cbab4712b4a709e0ba8ffe42 Merge: 9a43241 8cd02af Author: Ekaterina Dimitrova AuthorDate: Fri May 21 14:22:51 2021 -0400 Merge branch 'cassandra-4.0' into trunk CHANGES.txt| 1 + .../apache/cassandra/concurrent/SEPExecutor.java | 6 + .../cassandra/concurrent/SEPExecutorTest.java | 149 +++-- 3 files changed, 113 insertions(+), 43 deletions(-) diff --cc CHANGES.txt index 4a4c7c1,e147a85..a739bd6 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,6 -1,5 +1,7 @@@ -4.0-rc2 +4.1 + * GossiperTest.testHasVersion3Nodes didn't take into account trunk version changes, fixed to rely on latest version (CASSANDRA-16651) +Merged from 4.0: + * Spin up SEPWorker threads whenever we grow the number of work permits(CASSANDRA-16668) * Add a warning to cqlsh 6.0.0 that DESCRIBE does not work with a Cassandra 3.x servers (CASSANDRA-16652) * cqlsh: fix DESC TYPE with non-ascii character in the identifier (CASSANDRA-16400) * Remove drivers dependency and bring cql_keywords_reserved on server side (CASSANDRA-16659) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (ae84406 -> 8cd02af)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from ae84406 Merge branch 'cassandra-3.11' into cassandra-4.0 add 8cd02af Spin up SEPWorker threads whenever we grow the number of work permits authored by Matt Fleming, reviewed by Jon Meredith, Andres de la Pena, Ekaterina Dimitrova for CASSANDRA-16668 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/concurrent/SEPExecutor.java | 6 + .../cassandra/concurrent/SEPExecutorTest.java | 149 +++-- 3 files changed, 113 insertions(+), 43 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349420#comment-17349420
]
Sarma Pydipally commented on CASSANDRA-16682:
-
got it ... i was not aware of the original design and decisions.
we should not introduce new flow before the major release.
please leave the new entries in logback.xml in COMMENTED OUT setion.
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349420#comment-17349420
]
Sarma Pydipally edited comment on CASSANDRA-16682 at 5/21/21, 6:03 PM:
---
got it ... i was not aware of the original design and decisions.
we should not introduce new flow before the major release.
please leave the new entries in logback.xml in COMMENTED OUT section.
was (Author: oramad):
got it ... i was not aware of the original design and decisions.
we should not introduce new flow before the major release.
please leave the new entries in logback.xml in COMMENTED OUT setion.
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349411#comment-17349411
]
Ekaterina Dimitrova edited comment on CASSANDRA-16682 at 5/21/21, 5:45 PM:
---
Thank you both for the quick reviews.
{quote}can we leave it in there WITHOUT commenting it out ? because on/off
switch is somewhere else "cassandra.yaml : audit_logging_options : enabled:
true/false" + it will require "logger : class_name: FileAuditLogger".
{quote}
I thought about it, but this will be a change to the original default behavior
which is as per design for audit logs to be directed to system logs and
separated only on user decision (by adding the config in logback.xml). I am not
sure we should change it now before the release.
was (Author: e.dimitrova):
Thank you both for the quick reviews.
{quote}can we leave it in there WITHOUT commenting it out ? because on/off
switch is somewhere else "cassandra.yaml : audit_logging_options : enabled:
true/false" + it will require "logger : class_name: FileAuditLogger".
{quote}
I thought about it, but this will be a change to the original default behavior
which is as per design for audit logs to be directed to system logs and
separated only on user request. I am not sure we should change it now before
the release.
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349411#comment-17349411
]
Ekaterina Dimitrova commented on CASSANDRA-16682:
-
Thank you both for the quick reviews.
{quote}can we leave it in there WITHOUT commenting it out ? because on/off
switch is somewhere else "cassandra.yaml : audit_logging_options : enabled:
true/false" + it will require "logger : class_name: FileAuditLogger".
{quote}
I thought about it, but this will be a change to the original default behavior
which is as per design for audit logs to be directed to system logs and
separated only on user request. I am not sure we should change it now before
the release.
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349407#comment-17349407 ] Ekaterina Dimitrova commented on CASSANDRA-16670: - I agree with you, we need both test classes back away from 'long', unfortunately. :-( While on this, can you also do the same for _ViewFilteringTest_. As It seems I didn't have to move that one too as part of CASSANDRA-16613. Thank you! > Flaky ViewComplexTest and InsertUpdateIfConditionTest > - > > Key: CASSANDRA-16670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16670 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.x > > > *ViewComplexTest* > Flaky > [test|https://ci-cassandra.apache.org/job/Cassandra-4.0/43/testReport/junit/org.apache.cassandra.cql3/ViewComplexTest/testPartialDeleteSelectedColumnWithoutFlush_3_/] > *InsertUpdateIfConditionTest* (CASSANDRA-16676) > Fails > [here|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/testListItem_2__clusterMinVersion_4_0_0_rc2_SNAPSHOT_/] > with a timeout. We can see in the history it takes quite a while in > [CI|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/history/] > _but_ it takes just 1m locally. Probably due to constrained resources. > Looking at the > [individual|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/] > test cases, for compression i.e., we can see 378 at an average of 1s each it > can easily go over the timeout of 240s. Recommendation is to either move to > 'long' section of to raise the timeout for the class for CI. -- 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-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349407#comment-17349407 ] Ekaterina Dimitrova edited comment on CASSANDRA-16670 at 5/21/21, 5:36 PM: --- I agree with you, we need both test classes back away from 'long', unfortunately. :-( While on this, can you also do the same for _ViewFilteringTest_, please? As It seems I didn't have to move that one too as part of CASSANDRA-16613. Thank you! was (Author: e.dimitrova): I agree with you, we need both test classes back away from 'long', unfortunately. :-( While on this, can you also do the same for _ViewFilteringTest_. As It seems I didn't have to move that one too as part of CASSANDRA-16613. Thank you! > Flaky ViewComplexTest and InsertUpdateIfConditionTest > - > > Key: CASSANDRA-16670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16670 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.x > > > *ViewComplexTest* > Flaky > [test|https://ci-cassandra.apache.org/job/Cassandra-4.0/43/testReport/junit/org.apache.cassandra.cql3/ViewComplexTest/testPartialDeleteSelectedColumnWithoutFlush_3_/] > *InsertUpdateIfConditionTest* (CASSANDRA-16676) > Fails > [here|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/testListItem_2__clusterMinVersion_4_0_0_rc2_SNAPSHOT_/] > with a timeout. We can see in the history it takes quite a while in > [CI|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/history/] > _but_ it takes just 1m locally. Probably due to constrained resources. > Looking at the > [individual|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/] > test cases, for compression i.e., we can see 378 at an average of 1s each it > can easily go over the timeout of 240s. Recommendation is to either move to > 'long' section of to raise the timeout for the class for CI. -- 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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349398#comment-17349398
]
Sarma Pydipally commented on CASSANDRA-16682:
-
BTW ... rest of changes looking good.
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349397#comment-17349397
]
Sarma Pydipally commented on CASSANDRA-16682:
-
thinking
in default "logback.xml" ... do we need to keep the new default entries for
audit logging in COMMENTED OUT mode ?
can we leave it in there WITHOUT commenting it out ? because on/off switch is
somewhere else "cassandra.yaml : audit_logging_options : enabled: true/false"
+ it will require "logger : class_name: FileAuditLogger".
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16682:
Reviewers: Brandon Williams, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349383#comment-17349383
]
Ekaterina Dimitrova edited comment on CASSANDRA-16682 at 5/21/21, 5:16 PM:
---
[Patch
|https://github.com/ekaterinadimitrova2/cassandra/commit/5c4f035e611c448ed6e2afa49c7b9c60ec2feb48]
[~oramad], do you mind to review it if you have a bit of time, please? Your
feedback is really valuable.
In any case we will need one more committer to review it. [~brandon.williams],
[~mck], will anyone of you have a bit of time to check it, please?
Thank you in advance.
was (Author: e.dimitrova):
[Patch
|https://github.com/ekaterinadimitrova2/cassandra/commit/5c4f035e611c448ed6e2afa49c7b9c60ec2feb48]
[~oramad], do you mind to review it if you have a bit of time, please? You
feedback is really valuable.
In any case we will need one more committer to review it. [~brandon.williams],
[~mck], will anyone of you have a bit of time to check it, please?
Thank you in advance.
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349387#comment-17349387
]
Brandon Williams commented on CASSANDRA-16682:
--
LGTM, with one super-duper-ultra-nit: "time stamp" could be "timestamp"
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16682:
Test and Documentation Plan:
https://issues.apache.org/jira/browse/CASSANDRA-16682?focusedCommentId=17349383&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17349383
Status: Patch Available (was: In Progress)
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16682) Cassandra 4.0 RC1 ... Audit Logs going to wrong location
[
https://issues.apache.org/jira/browse/CASSANDRA-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349383#comment-17349383
]
Ekaterina Dimitrova commented on CASSANDRA-16682:
-
[Patch
|https://github.com/ekaterinadimitrova2/cassandra/commit/5c4f035e611c448ed6e2afa49c7b9c60ec2feb48]
[~oramad], do you mind to review it if you have a bit of time, please? You
feedback is really valuable.
In any case we will need one more committer to review it. [~brandon.williams],
[~mck], will anyone of you have a bit of time to check it, please?
Thank you in advance.
> Cassandra 4.0 RC1 ... Audit Logs going to wrong location
>
>
> Key: CASSANDRA-16682
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16682
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Sarma Pydipally
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Version : Cassandra 4.0 RC1
> Settings in my : /conf/cassandra.yaml
> {code:yaml}
> audit_logging_options:
> enabled: true
> logger:
> - class_name: FileAuditLogger
> excluded_categories: QUERY, DML
> audit_logs_dir: "/apps/opt/cassandra/logs/audit"
> roll_cycle: DAILY
> block: false
> {code}
> After restart of Cassandra ... I can see the Audit Logs. But they are going
> into system.log and debug.log. They are NOT going into
> {noformat}
> "/apps/opt/cassandra/logs/audit/audit.log"{noformat}
>
> Also noticed that : it does not ignore the "excluded_categories" and logs
> everything ...
--
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-16668) Intermittent failure of SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race condition when shrinking maximum pool size to zero
[
https://issues.apache.org/jira/browse/CASSANDRA-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349349#comment-17349349
]
Matt Fleming commented on CASSANDRA-16668:
--
[~adelapena] your changes look good! Thanks for doing that. +1
> Intermittent failure of
> SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race
> condition when shrinking maximum pool size to zero
> -
>
> Key: CASSANDRA-16668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16668
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Matt Fleming
>Assignee: Matt Fleming
>Priority: Normal
> Fix For: 4.0-rc
>
>
> A difficult-to-hit race condition exists in
> changingMaxWorkersMeetsConcurrencyGoalsTest when changing the maximum pool
> size from 0 -> 4 which results in the test failing like so:
> {{junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but
> was:junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but was: at
> org.apache.cassandra.concurrent.SEPExecutorTest.assertMaxTaskConcurrency(SEPExecutorTest.java:198)
> at
> org.apache.cassandra.concurrent.SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest(SEPExecutorTest.java:132)}}
> I can hit this issue maybe 2/3 times for every 100 invocations of the unit
> test.
> The issue that causes the failure is that if tasks are still enqueued when
> the maximum pool size is set to zero and if all of the SEPWorker threads
> enter the STOP state before the pool size is bumped to 4, then no SEPWorker
> threads will be spun up to service the task queue. This causes the above
> error.
> Why don't we spin up SEPWorker threads when enqueing tasks? Because of the
> guard logic in addTask:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/concurrent/SEPExecutor.java#L113,L121]
> In this scenario taskPermits will not be zero (because we have tasks on the
> queue) so we never call {{maybeStartSpinningWorker()}}.
> A trick to make this issue much easier to hit is to insert a
> {{Thread.sleep(500)}} immediately after setting the pool size to zero. This
> has the effect of guaranteeing that all SEPWorker threads will be STOP'd
> before enqueueing more work.
> Here's a fix that attempts to spin up an SEPWorker whenever we grow the
> number of work permits:
> https://github.com/mfleming/cassandra/commit/071516d29e41da9924af24e8002822d3c6af0e01
--
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-16668) Intermittent failure of SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race condition when shrinking maximum pool size to zero
[
https://issues.apache.org/jira/browse/CASSANDRA-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349335#comment-17349335
]
Andres de la Peña commented on CASSANDRA-16668:
---
[~e.dimitrova] I have the two patches, the suggestions and few additional minor
warning fixes in [this
branch|https://github.com/adelapena/cassandra/tree/16668-trunk-review], which
is the one used for the CircleCI runs above.
> Intermittent failure of
> SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race
> condition when shrinking maximum pool size to zero
> -
>
> Key: CASSANDRA-16668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16668
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Matt Fleming
>Assignee: Matt Fleming
>Priority: Normal
> Fix For: 4.0-rc
>
>
> A difficult-to-hit race condition exists in
> changingMaxWorkersMeetsConcurrencyGoalsTest when changing the maximum pool
> size from 0 -> 4 which results in the test failing like so:
> {{junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but
> was:junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but was: at
> org.apache.cassandra.concurrent.SEPExecutorTest.assertMaxTaskConcurrency(SEPExecutorTest.java:198)
> at
> org.apache.cassandra.concurrent.SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest(SEPExecutorTest.java:132)}}
> I can hit this issue maybe 2/3 times for every 100 invocations of the unit
> test.
> The issue that causes the failure is that if tasks are still enqueued when
> the maximum pool size is set to zero and if all of the SEPWorker threads
> enter the STOP state before the pool size is bumped to 4, then no SEPWorker
> threads will be spun up to service the task queue. This causes the above
> error.
> Why don't we spin up SEPWorker threads when enqueing tasks? Because of the
> guard logic in addTask:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/concurrent/SEPExecutor.java#L113,L121]
> In this scenario taskPermits will not be zero (because we have tasks on the
> queue) so we never call {{maybeStartSpinningWorker()}}.
> A trick to make this issue much easier to hit is to insert a
> {{Thread.sleep(500)}} immediately after setting the pool size to zero. This
> has the effect of guaranteeing that all SEPWorker threads will be STOP'd
> before enqueueing more work.
> Here's a fix that attempts to spin up an SEPWorker whenever we grow the
> number of work permits:
> https://github.com/mfleming/cassandra/commit/071516d29e41da9924af24e8002822d3c6af0e01
--
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-16687) Support upgrade tests in CircleCI multiplexer
[
https://issues.apache.org/jira/browse/CASSANDRA-16687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349310#comment-17349310
]
Ekaterina Dimitrova commented on CASSANDRA-16687:
-
{quote}As it's mentioned in the description, supporting Python upgrade dtests
is easy, we only need to add the {{--execute-upgrade-tests}} as it's done
[here|https://github.com/apache/cassandra/pull/1016/commits/d5966428453e225510bfc0caa28eb1723dd56ee5].
If I'm right this flag is harmless when the repeated test to be run isn't an
upgrade test.
{quote}
Indeed, it is harmless but I think it will be confusing to have the multiplexer
for python dtests and python upgrade tests at one job.
Why? Because I am +1 on your option number 5 and because everywhere we have
separately run any upgrade tests in a loop or not. I think it will be
consistent and less confusing for the user to separate them. WDYT?
> Support upgrade tests in CircleCI multiplexer
> -
>
> Key: CASSANDRA-16687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16687
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The CircleCI jobs for running a test repeatedly added by CASSANDRA-16625
> don't support upgrade tests. In the case of Python upgrade dtests we only
> need the {{--execute-upgrade-tests}} when calling {{pytest}}. For Java
> upgrade tests we need to build the dtest jars before running the repeated
> tests.
--
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-16668) Intermittent failure of SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race condition when shrinking maximum pool size to zero
[
https://issues.apache.org/jira/browse/CASSANDRA-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16668:
Status: Ready to Commit (was: Review In Progress)
> Intermittent failure of
> SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race
> condition when shrinking maximum pool size to zero
> -
>
> Key: CASSANDRA-16668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16668
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Matt Fleming
>Assignee: Matt Fleming
>Priority: Normal
> Fix For: 4.0-rc
>
>
> A difficult-to-hit race condition exists in
> changingMaxWorkersMeetsConcurrencyGoalsTest when changing the maximum pool
> size from 0 -> 4 which results in the test failing like so:
> {{junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but
> was:junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but was: at
> org.apache.cassandra.concurrent.SEPExecutorTest.assertMaxTaskConcurrency(SEPExecutorTest.java:198)
> at
> org.apache.cassandra.concurrent.SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest(SEPExecutorTest.java:132)}}
> I can hit this issue maybe 2/3 times for every 100 invocations of the unit
> test.
> The issue that causes the failure is that if tasks are still enqueued when
> the maximum pool size is set to zero and if all of the SEPWorker threads
> enter the STOP state before the pool size is bumped to 4, then no SEPWorker
> threads will be spun up to service the task queue. This causes the above
> error.
> Why don't we spin up SEPWorker threads when enqueing tasks? Because of the
> guard logic in addTask:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/concurrent/SEPExecutor.java#L113,L121]
> In this scenario taskPermits will not be zero (because we have tasks on the
> queue) so we never call {{maybeStartSpinningWorker()}}.
> A trick to make this issue much easier to hit is to insert a
> {{Thread.sleep(500)}} immediately after setting the pool size to zero. This
> has the effect of guaranteeing that all SEPWorker threads will be STOP'd
> before enqueueing more work.
> Here's a fix that attempts to spin up an SEPWorker whenever we grow the
> number of work permits:
> https://github.com/mfleming/cassandra/commit/071516d29e41da9924af24e8002822d3c6af0e01
--
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-16668) Intermittent failure of SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race condition when shrinking maximum pool size to zero
[
https://issues.apache.org/jira/browse/CASSANDRA-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349305#comment-17349305
]
Ekaterina Dimitrova commented on CASSANDRA-16668:
-
+1 from me too, if it is fine with the others I can address on commit the nits
from Andres later today. Thank you!
> Intermittent failure of
> SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race
> condition when shrinking maximum pool size to zero
> -
>
> Key: CASSANDRA-16668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16668
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Matt Fleming
>Assignee: Matt Fleming
>Priority: Normal
> Fix For: 4.0-rc
>
>
> A difficult-to-hit race condition exists in
> changingMaxWorkersMeetsConcurrencyGoalsTest when changing the maximum pool
> size from 0 -> 4 which results in the test failing like so:
> {{junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but
> was:junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but was: at
> org.apache.cassandra.concurrent.SEPExecutorTest.assertMaxTaskConcurrency(SEPExecutorTest.java:198)
> at
> org.apache.cassandra.concurrent.SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest(SEPExecutorTest.java:132)}}
> I can hit this issue maybe 2/3 times for every 100 invocations of the unit
> test.
> The issue that causes the failure is that if tasks are still enqueued when
> the maximum pool size is set to zero and if all of the SEPWorker threads
> enter the STOP state before the pool size is bumped to 4, then no SEPWorker
> threads will be spun up to service the task queue. This causes the above
> error.
> Why don't we spin up SEPWorker threads when enqueing tasks? Because of the
> guard logic in addTask:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/concurrent/SEPExecutor.java#L113,L121]
> In this scenario taskPermits will not be zero (because we have tasks on the
> queue) so we never call {{maybeStartSpinningWorker()}}.
> A trick to make this issue much easier to hit is to insert a
> {{Thread.sleep(500)}} immediately after setting the pool size to zero. This
> has the effect of guaranteeing that all SEPWorker threads will be STOP'd
> before enqueueing more work.
> Here's a fix that attempts to spin up an SEPWorker whenever we grow the
> number of work permits:
> https://github.com/mfleming/cassandra/commit/071516d29e41da9924af24e8002822d3c6af0e01
--
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-16687) Support upgrade tests in CircleCI multiplexer
[
https://issues.apache.org/jira/browse/CASSANDRA-16687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16687:
Reviewers: Ekaterina Dimitrova
> Support upgrade tests in CircleCI multiplexer
> -
>
> Key: CASSANDRA-16687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16687
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The CircleCI jobs for running a test repeatedly added by CASSANDRA-16625
> don't support upgrade tests. In the case of Python upgrade dtests we only
> need the {{--execute-upgrade-tests}} when calling {{pytest}}. For Java
> upgrade tests we need to build the dtest jars before running the repeated
> tests.
--
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-16668) Intermittent failure of SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race condition when shrinking maximum pool size to zero
[
https://issues.apache.org/jira/browse/CASSANDRA-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16668:
Reviewers: Andres de la Peña, Ekaterina Dimitrova, Jon Meredith (was:
Andres de la Peña, Jon Meredith)
> Intermittent failure of
> SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest caused by race
> condition when shrinking maximum pool size to zero
> -
>
> Key: CASSANDRA-16668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16668
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Matt Fleming
>Assignee: Matt Fleming
>Priority: Normal
> Fix For: 4.0-rc
>
>
> A difficult-to-hit race condition exists in
> changingMaxWorkersMeetsConcurrencyGoalsTest when changing the maximum pool
> size from 0 -> 4 which results in the test failing like so:
> {{junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but
> was:junit.framework.AssertionFailedError: Test tasks did not hit max
> concurrency goal expected: but was: at
> org.apache.cassandra.concurrent.SEPExecutorTest.assertMaxTaskConcurrency(SEPExecutorTest.java:198)
> at
> org.apache.cassandra.concurrent.SEPExecutorTest.changingMaxWorkersMeetsConcurrencyGoalsTest(SEPExecutorTest.java:132)}}
> I can hit this issue maybe 2/3 times for every 100 invocations of the unit
> test.
> The issue that causes the failure is that if tasks are still enqueued when
> the maximum pool size is set to zero and if all of the SEPWorker threads
> enter the STOP state before the pool size is bumped to 4, then no SEPWorker
> threads will be spun up to service the task queue. This causes the above
> error.
> Why don't we spin up SEPWorker threads when enqueing tasks? Because of the
> guard logic in addTask:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/concurrent/SEPExecutor.java#L113,L121]
> In this scenario taskPermits will not be zero (because we have tasks on the
> queue) so we never call {{maybeStartSpinningWorker()}}.
> A trick to make this issue much easier to hit is to insert a
> {{Thread.sleep(500)}} immediately after setting the pool size to zero. This
> has the effect of guaranteeing that all SEPWorker threads will be STOP'd
> before enqueueing more work.
> Here's a fix that attempts to spin up an SEPWorker whenever we grow the
> number of work permits:
> https://github.com/mfleming/cassandra/commit/071516d29e41da9924af24e8002822d3c6af0e01
--
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-16687) Support upgrade tests in CircleCI multiplexer
[
https://issues.apache.org/jira/browse/CASSANDRA-16687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349242#comment-17349242
]
Andres de la Peña commented on CASSANDRA-16687:
---
As it's mentioned in the description, supporting Python upgrade dtests is easy,
we only need to add the {{--execute-upgrade-tests}} as it's done
[here|https://github.com/apache/cassandra/pull/1016/commits/d5966428453e225510bfc0caa28eb1723dd56ee5].
If I'm right this flag is harmless when the repeated test to be run isn't an
upgrade test.
As for JVM upgrade dtests, it's a bit more complicated because we need the
dtest jars. I can think of multiple ways of doing this:
# Do nothing. If we start the job {{start_jvm_upgrade_tests}} it will call the
job {{j8_dtest_jars_build}}, which will create the jars and add them to the
workspace, making them available for the dtest multiplexer. The downside is
that it forces us to run the entire set of JVM upgrade tests and wait for the
finalization of the {{j8_dtest_jars_build}} job before approving the
{{start_repeated_utest}} job. Of course this isn't very practical.
# Build the dtest jars on each repeated test runner. This would be quite
inefficient because it will build the jars 25 times in the case of MIDRES, and
100 times with HIGHRES.
# Allow to run {{j8_dtest_jars_build}} separately, and make
{{jvm_upgrade_tests}} depend on it, as it's done
[here|https://github.com/apache/cassandra/pull/1016/commits/2d1f34a2afc6ceb060e192fd04fa2c5824dfbcad].
That way we don't need to run the the entire set of JVM upgrade tests to run
the multiplexer, but we still need to wait for the finalization of the
{{j8_dtest_jars_build}} job before approving the {{start_repeated_utest}} job
in case we are repeating a JVM upgrade test, which is a bit inconvenient.
# Make the {{repeated_utest}} job depend on {{j8_dtest_jars_build}}, so we can
approve both {{start_repeated_utest}} and {{start_j8_dtest_jars_build}} as soon
as the workflow is created. The downside is that it will build the dtest jars
even if the test to run repeatedly isn't an upgrade one, which is inefficient
and slightly confusing (why do we need to build the dtest jar to run a repeated
utest?).
# Make a separate, specific job for running JVM upgrade tests named
{{repeated-jvm-upgrade-dtest}}, and make it depend on {{j8_dtest_jars_build}},
as it's done
[here|https://github.com/apache/cassandra/pull/1016/commits/b9eebd7ec32f38f477dedbd7dea264550986951c].
Also we would add separate env vars for that job, as it's done
[here|https://github.com/apache/cassandra/pull/1016/commits/2fd8415a953f226abc4c8909547774dd3f1dde01].
That is efficient in the sense that the dtest jars are only built once in all
the workflow, and I think that makes the dependencies easy to understand. The
resulting workflow can be seen on [this
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/484/workflows/1604b21f-42fd-487a-a6ef-3561bf82cc55].
I think the approach described in 5. is the right one, even though it requires
an extra click to run the JVM upgrade tests. Any alternative ideas are more
than welcome. It would be super nice to have a way to automatically run the
{{j8_dtest_jars_build}} job only if {{start_jvm_upgrade_tests}} *or*
{{start-repeated-jvm-upgrade-dtest}} are called, but I can't see a way to do so
with CircleCI.
> Support upgrade tests in CircleCI multiplexer
> -
>
> Key: CASSANDRA-16687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16687
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The CircleCI jobs for running a test repeatedly added by CASSANDRA-16625
> don't support upgrade tests. In the case of Python upgrade dtests we only
> need the {{--execute-upgrade-tests}} when calling {{pytest}}. For Java
> upgrade tests we need to build the dtest jars before running the repeated
> tests.
--
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-16687) Support upgrade tests in CircleCI multiplexer
[
https://issues.apache.org/jira/browse/CASSANDRA-16687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16687:
--
Change Category: Quality Assurance
Complexity: Low Hanging Fruit
Status: Open (was: Triage Needed)
> Support upgrade tests in CircleCI multiplexer
> -
>
> Key: CASSANDRA-16687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16687
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> The CircleCI jobs for running a test repeatedly added by CASSANDRA-16625
> don't support upgrade tests. In the case of Python upgrade dtests we only
> need the {{--execute-upgrade-tests}} when calling {{pytest}}. For Java
> upgrade tests we need to build the dtest jars before running the repeated
> tests.
--
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-16687) Support upgrade tests in CircleCI multiplexer
Andres de la Peña created CASSANDRA-16687:
-
Summary: Support upgrade tests in CircleCI multiplexer
Key: CASSANDRA-16687
URL: https://issues.apache.org/jira/browse/CASSANDRA-16687
Project: Cassandra
Issue Type: Task
Components: CI
Reporter: Andres de la Peña
Assignee: Andres de la Peña
The CircleCI jobs for running a test repeatedly added by CASSANDRA-16625 don't
support upgrade tests. In the case of Python upgrade dtests we only need the
{{--execute-upgrade-tests}} when calling {{pytest}}. For Java upgrade tests we
need to build the dtest jars before running the repeated tests.
--
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-16684) Flaky MemtableSizeTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-16684:
---
Assignee: Ekaterina Dimitrova
> Flaky MemtableSizeTest
> --
>
> Key: CASSANDRA-16684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16684
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Flaky
> [MemtableSizeTest|https://ci-cassandra.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.cql3/MemtableSizeTest/testSize_compression/]
> {noformat}
> Error Message
> Expected heap usage close to 50.085MiB, got 41.294MiB.
> Stacktrace
> junit.framework.AssertionFailedError: Expected heap usage close to 50.085MiB,
> got 41.294MiB.
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testSize(MemtableSizeTest.java:121)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2021-05-18 22:08:42,837 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-05-18 22:08:42,840 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-05-18 22:08:42,934 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-05-18 22:08:42,956 PlatformDependent0
> ...[truncated 86028 chars]...
> hed transaction log, deleting
> /home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb_txn_flush_a3253f00-b825-11eb-b0ec-cd4f0218a6b5.log
>
> DEBUG [MemtableFlushWriter:2] 2021-05-18 22:08:55,552
> ColumnFamilyStore.java:1197 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb-6-big-Data.db')]
> (1 sstables, 4.894KiB), biggest 4.894KiB, smallest 4.894KiB
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16665) WEBSITE - May 2021 updates
[ https://issues.apache.org/jira/browse/CASSANDRA-16665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16665: --- Status: Ready to Commit (was: Review In Progress) LGTM > WEBSITE - May 2021 updates > -- > > Key: CASSANDRA-16665 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16665 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > > Sharing a batch of HTML updates to be made to the website that include: > * Homepage – update banner to include playlist for World Party (replacing > World Party registration promo) > * Ecosystem – adding two new items and updating a name based on request from > user list. > * Update blog URL to fix 404 > * Update Black Rock logo naming to fix broken image > > -- 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-16665) WEBSITE - May 2021 updates
[ https://issues.apache.org/jira/browse/CASSANDRA-16665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16665: --- Fix Version/s: (was: 4.0.x) 4.0 4.0-rc2 Source Control Link: https://github.com/apache/cassandra-website/commit/4465915899095ec877f70255d97c3ff612e27dd0 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [4465915899095ec877f70255d97c3ff612e27dd0|https://github.com/apache/cassandra-website/commit/4465915899095ec877f70255d97c3ff612e27dd0]. > WEBSITE - May 2021 updates > -- > > Key: CASSANDRA-16665 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16665 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Melissa Logan >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-rc2, 4.0 > > > Sharing a batch of HTML updates to be made to the website that include: > * Homepage – update banner to include playlist for World Party (replacing > World Party registration promo) > * Ecosystem – adding two new items and updating a name based on request from > user list. > * Update blog URL to fix 404 > * Update Black Rock logo naming to fix broken image > > -- 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-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
[
https://issues.apache.org/jira/browse/CASSANDRA-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349151#comment-17349151
]
Ekaterina Dimitrova commented on CASSANDRA-16637:
-
This is not only 4.0 issue and also we already have this ticket open so I don't
see a reason to open new one or check versions.
> LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
> --
>
> Key: CASSANDRA-16637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Adam Holmberg
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x
>
>
> Test is failing occasionally as follows:
> {noformat}
> Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
> at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
> at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
> at
> org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
> 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)
> {noformat}
> [Recent
> ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated: CASSANDRA-16665 May 2021 updates to static pages
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/asf-site by this push: new 4465915 CASSANDRA-16665 May 2021 updates to static pages 4465915 is described below commit 4465915899095ec877f70255d97c3ff612e27dd0 Author: Erick Ramirez AuthorDate: Fri May 21 04:07:34 2021 + CASSANDRA-16665 May 2021 updates to static pages --- content/blog/Join-Cassandra-GSoC-2021.html | 254 + content/ecosystem/index.html | 3 +- content/index.html | 4 +- 3 files changed, 258 insertions(+), 3 deletions(-) diff --git a/content/blog/Join-Cassandra-GSoC-2021.html b/content/blog/Join-Cassandra-GSoC-2021.html new file mode 100644 index 000..4952338 --- /dev/null +++ b/content/blog/Join-Cassandra-GSoC-2021.html @@ -0,0 +1,254 @@ + + + + + + Join Apache Cassandra for Google Summer of Code 2021 | Blog + https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js";> + + + + https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400&family=Red+Hat+Display:ital,wght@0,400;0,500;0,700;1,400;1,500&display=swap"; rel="stylesheet"> + + + +https://plausible.cassandra.apache.org/js/plausible.js";> + + + + + Cassandra Basics + Quickstart + Ecosystem + https://cassandra.apache.org/doc/latest/";>Documentation + Community + Case Studies + Resources + Blog + Download + + + + + + + + + + + + + Get Started + + + + + + + + Cassandra Basics + + + + + + + + + + Quickstart + + + + + + + + + + Ecosystem + +
[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16671:
---
Fix Version/s: (was: 4.0.x)
4.0-rc
> Cassandra can return no row when the row columns have been deleted.
> ---
>
> Key: CASSANDRA-16671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16671
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> It is the semantic of CQL that a (CQL) row exists as long as it has one
> non-null column (including the PK columns).
> To determine if a row has some *non-null primary key*, Cassandra relies on
> the row primary key liveness.
> For example:
> {code}
> CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
> INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
> DELETE v FROM test WHERE pk = 1 AND ck = 1
> SELECT v FROM test;
> {code}
> will return
> {code}
> v
> ---
> null
> {code}
> {{UPDATE}} statements do not set the row primary key liveness by consequence
> if the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
> {{SELECT}} query would *not have returned any rows*.
> CASSANDRA-16226 introduced a regression by stopping early in the timestamp
> ordered logic if an {{UPDATE}} statement covering all the columns was found
> in an SSTable. As the row returned did not have a primary key liveness if
> another node was also returning a column deletion, the expected row will not
> be returned.
> The problem can be reproduced with the following test:
> {code}
>@Test
> public void
> testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
> Throwable
> {
> try (Cluster cluster = init(builder().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int,
> ck text, v int, PRIMARY KEY (pk, ck))"));
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
> (pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
> TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
> USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
> cluster.get(2).flush(KEYSPACE);
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row(1, "1", null)); // <-- FAIL
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row((Integer) null));
> }
> }
> {code}
> cc: [~maedhroz], [~ifesdjeen]
--
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-16686) Queries returning static content when the partition has no rows might fail to return some rows
[
https://issues.apache.org/jira/browse/CASSANDRA-16686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16686:
---
Bug Category: Parent values: Correctness(12982)Level 1 values: Transient
Incorrect Response(12987)
Complexity: Normal
Component/s: CQL/Interpreter
Discovered By: Code Inspection
Fix Version/s: 4.x
Severity: Normal
Status: Open (was: Triage Needed)
> Queries returning static content when the partition has no rows might fail to
> return some rows
> --
>
> Key: CASSANDRA-16686
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16686
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> The problem can be reproduced with the following test:
> {code}
> @Test
> public void testStaticColumnDeletionWithMultipleStaticColumns() throws
> Throwable
> {
> createTable("CREATE TABLE %s (pk int, ck int, s1 int static, s2 int
> static, v int, PRIMARY KEY(pk, ck))");
> execute("INSERT INTO %s (pk, s1, s2) VALUES (1, 1, 1) USING TIMESTAMP
> 1000");
> flush();
> execute("INSERT INTO %s (pk, s1) VALUES (1, 2) USING TIMESTAMP 2000");
> flush();
> execute("DELETE s1 FROM %s USING TIMESTAMP 3000 WHERE pk = 1");
> flush();
> assertRows(execute("SELECT * FROM %s WHERE pk=1"), row(1, null, null,
> 1, null));
> assertRows(execute("SELECT s1, s2 FROM %s WHERE pk=1"), row((Integer)
> null, 1));
> assertRows(execute("SELECT s1 FROM %s WHERE pk=1"), row((Integer)
> null)); // <-FAIL
> }
> {code}
> This problem is a regression in 4.0 and trunk
--
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-16686) Queries returning static content when the partition has no rows might fail to return some rows
Benjamin Lerer created CASSANDRA-16686:
--
Summary: Queries returning static content when the partition has
no rows might fail to return some rows
Key: CASSANDRA-16686
URL: https://issues.apache.org/jira/browse/CASSANDRA-16686
Project: Cassandra
Issue Type: Bug
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
The problem can be reproduced with the following test:
{code}
@Test
public void testStaticColumnDeletionWithMultipleStaticColumns() throws
Throwable
{
createTable("CREATE TABLE %s (pk int, ck int, s1 int static, s2 int
static, v int, PRIMARY KEY(pk, ck))");
execute("INSERT INTO %s (pk, s1, s2) VALUES (1, 1, 1) USING TIMESTAMP
1000");
flush();
execute("INSERT INTO %s (pk, s1) VALUES (1, 2) USING TIMESTAMP 2000");
flush();
execute("DELETE s1 FROM %s USING TIMESTAMP 3000 WHERE pk = 1");
flush();
assertRows(execute("SELECT * FROM %s WHERE pk=1"), row(1, null, null,
1, null));
assertRows(execute("SELECT s1, s2 FROM %s WHERE pk=1"), row((Integer)
null, 1));
assertRows(execute("SELECT s1 FROM %s WHERE pk=1"), row((Integer)
null)); // <-FAIL
}
{code}
This problem is a regression in 4.0 and trunk
--
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-16685) Flaky ActiveRepairServiceTest.testRejectWhenPoolFullStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-16685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16685:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.x
4.0
4.0-rc2
Severity: Normal
Status: Open (was: Triage Needed)
> Flaky ActiveRepairServiceTest.testRejectWhenPoolFullStrategy
>
>
> Key: CASSANDRA-16685
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16685
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Flaky
> [ActiveRepairServiceTest.testRejectWhenPoolFullStrategy|https://ci-cassandra.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.service/ActiveRepairServiceTest/testRejectWhenPoolFullStrategy_compression/]
> {noformat}
> Error Message
> Task java.util.concurrent.FutureTask@63553e9f[Not completed, task =
> java.util.concurrent.Executors$RunnableAdapter@52cb52bd[Wrapped task =
> org.apache.cassandra.service.ActiveRepairServiceTest$Task@1d1c37d5]] rejected
> from
> org.apache.cassandra.concurrent.JMXEnabledThreadPoolExecutor@218df7d6[Running,
> pool size = 2, active threads = 2, queued tasks = 0, completed tasks = 0]
> Stacktrace
> java.util.concurrent.RejectedExecutionException: Task
> java.util.concurrent.FutureTask@63553e9f[Not completed, task =
> java.util.concurrent.Executors$RunnableAdapter@52cb52bd[Wrapped task =
> org.apache.cassandra.service.ActiveRepairServiceTest$Task@1d1c37d5]] rejected
> from
> org.apache.cassandra.concurrent.JMXEnabledThreadPoolExecutor@218df7d6[Running,
> pool size = 2, active threads = 2, queued tasks = 0, completed tasks = 0]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2055)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:825)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1355)
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:176)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
> at
> org.apache.cassandra.service.ActiveRepairServiceTest.testRejectWhenPoolFullStrategy(ActiveRepairServiceTest.java:380)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2021-05-18 22:04:31,694 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-05-18 22:04:31,698 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-05-18 22:04:31,807 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-05-18 22:04:31,827 PlatformDependent0
> ...[truncated 95289 chars]...
> andra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb_txn_flush_08e70270-b825-11eb-a393-871312b17b94.log
>
> DEBUG [MemtableFlushWriter:1] 2021-05-18 22:04:36,792
> ColumnFamilyStore.java:1197 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-15-big-Data.db')]
> (1 sstables, 4.944KiB), biggest 4.944KiB, smallest 4.944KiB
> DEBUG [main] 2021-05-18 22:04:36,795 StorageService.java:1619 - NORMAL
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16685) Flaky ActiveRepairServiceTest.testRejectWhenPoolFullStrategy
Berenguer Blasi created CASSANDRA-16685:
---
Summary: Flaky
ActiveRepairServiceTest.testRejectWhenPoolFullStrategy
Key: CASSANDRA-16685
URL: https://issues.apache.org/jira/browse/CASSANDRA-16685
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Berenguer Blasi
Flaky
[ActiveRepairServiceTest.testRejectWhenPoolFullStrategy|https://ci-cassandra.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.service/ActiveRepairServiceTest/testRejectWhenPoolFullStrategy_compression/]
{noformat}
Error Message
Task java.util.concurrent.FutureTask@63553e9f[Not completed, task =
java.util.concurrent.Executors$RunnableAdapter@52cb52bd[Wrapped task =
org.apache.cassandra.service.ActiveRepairServiceTest$Task@1d1c37d5]] rejected
from
org.apache.cassandra.concurrent.JMXEnabledThreadPoolExecutor@218df7d6[Running,
pool size = 2, active threads = 2, queued tasks = 0, completed tasks = 0]
Stacktrace
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.FutureTask@63553e9f[Not completed, task =
java.util.concurrent.Executors$RunnableAdapter@52cb52bd[Wrapped task =
org.apache.cassandra.service.ActiveRepairServiceTest$Task@1d1c37d5]] rejected
from
org.apache.cassandra.concurrent.JMXEnabledThreadPoolExecutor@218df7d6[Running,
pool size = 2, active threads = 2, queued tasks = 0, completed tasks = 0]
at
java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2055)
at
java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:825)
at
java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1355)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:176)
at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
at
org.apache.cassandra.service.ActiveRepairServiceTest.testRejectWhenPoolFullStrategy(ActiveRepairServiceTest.java:380)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Standard Output
INFO [main] 2021-05-18 22:04:31,694 YamlConfigurationLoader.java:93 -
Configuration location:
file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
DEBUG [main] 2021-05-18 22:04:31,698 YamlConfigurationLoader.java:112 - Loading
settings from
file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
DEBUG [main] 2021-05-18 22:04:31,807 InternalLoggerFactory.java:63 - Using
SLF4J as the default logging framework
DEBUG [main] 2021-05-18 22:04:31,827 PlatformDependent0
...[truncated 95289 chars]...
andra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb_txn_flush_08e70270-b825-11eb-a393-871312b17b94.log
DEBUG [MemtableFlushWriter:1] 2021-05-18 22:04:36,792
ColumnFamilyStore.java:1197 - Flushed to
[BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-15-big-Data.db')]
(1 sstables, 4.944KiB), biggest 4.944KiB, smallest 4.944KiB
DEBUG [main] 2021-05-18 22:04:36,795 StorageService.java:1619 - NORMAL
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16684) Flaky MemtableSizeTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16684:
Fix Version/s: 4.x
4.0
4.0-rc2
> Flaky MemtableSizeTest
> --
>
> Key: CASSANDRA-16684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16684
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Flaky
> [MemtableSizeTest|https://ci-cassandra.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.cql3/MemtableSizeTest/testSize_compression/]
> {noformat}
> Error Message
> Expected heap usage close to 50.085MiB, got 41.294MiB.
> Stacktrace
> junit.framework.AssertionFailedError: Expected heap usage close to 50.085MiB,
> got 41.294MiB.
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testSize(MemtableSizeTest.java:121)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2021-05-18 22:08:42,837 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-05-18 22:08:42,840 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-05-18 22:08:42,934 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-05-18 22:08:42,956 PlatformDependent0
> ...[truncated 86028 chars]...
> hed transaction log, deleting
> /home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb_txn_flush_a3253f00-b825-11eb-b0ec-cd4f0218a6b5.log
>
> DEBUG [MemtableFlushWriter:2] 2021-05-18 22:08:55,552
> ColumnFamilyStore.java:1197 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb-6-big-Data.db')]
> (1 sstables, 4.894KiB), biggest 4.894KiB, smallest 4.894KiB
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16684) Flaky MemtableSizeTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16684:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: Unit Test
Severity: Normal
Status: Open (was: Triage Needed)
> Flaky MemtableSizeTest
> --
>
> Key: CASSANDRA-16684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16684
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Priority: Normal
>
> Flaky
> [MemtableSizeTest|https://ci-cassandra.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.cql3/MemtableSizeTest/testSize_compression/]
> {noformat}
> Error Message
> Expected heap usage close to 50.085MiB, got 41.294MiB.
> Stacktrace
> junit.framework.AssertionFailedError: Expected heap usage close to 50.085MiB,
> got 41.294MiB.
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testSize(MemtableSizeTest.java:121)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2021-05-18 22:08:42,837 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-05-18 22:08:42,840 YamlConfigurationLoader.java:112 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2021-05-18 22:08:42,934 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-05-18 22:08:42,956 PlatformDependent0
> ...[truncated 86028 chars]...
> hed transaction log, deleting
> /home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb_txn_flush_a3253f00-b825-11eb-b0ec-cd4f0218a6b5.log
>
> DEBUG [MemtableFlushWriter:2] 2021-05-18 22:08:55,552
> ColumnFamilyStore.java:1197 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb-6-big-Data.db')]
> (1 sstables, 4.894KiB), biggest 4.894KiB, smallest 4.894KiB
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16684) Flaky MemtableSizeTest
Berenguer Blasi created CASSANDRA-16684:
---
Summary: Flaky MemtableSizeTest
Key: CASSANDRA-16684
URL: https://issues.apache.org/jira/browse/CASSANDRA-16684
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Berenguer Blasi
Flaky
[MemtableSizeTest|https://ci-cassandra.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.cql3/MemtableSizeTest/testSize_compression/]
{noformat}
Error Message
Expected heap usage close to 50.085MiB, got 41.294MiB.
Stacktrace
junit.framework.AssertionFailedError: Expected heap usage close to 50.085MiB,
got 41.294MiB.
at
org.apache.cassandra.cql3.MemtableSizeTest.testSize(MemtableSizeTest.java:121)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Standard Output
INFO [main] 2021-05-18 22:08:42,837 YamlConfigurationLoader.java:93 -
Configuration location:
file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
DEBUG [main] 2021-05-18 22:08:42,840 YamlConfigurationLoader.java:112 - Loading
settings from
file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
DEBUG [main] 2021-05-18 22:08:42,934 InternalLoggerFactory.java:63 - Using
SLF4J as the default logging framework
DEBUG [main] 2021-05-18 22:08:42,956 PlatformDependent0
...[truncated 86028 chars]...
hed transaction log, deleting
/home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb_txn_flush_a3253f00-b825-11eb-b0ec-cd4f0218a6b5.log
DEBUG [MemtableFlushWriter:2] 2021-05-18 22:08:55,552
ColumnFamilyStore.java:1197 - Flushed to
[BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb-6-big-Data.db')]
(1 sstables, 4.894KiB), biggest 4.894KiB, smallest 4.894KiB
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16670) Flaky ViewComplexTest and InsertUpdateIfConditionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349087#comment-17349087 ] Berenguer Blasi commented on CASSANDRA-16670: - [~e.dimitrova] I just realized we can't happily move things to the 'long' section. CI works under std, cdc and compression variants but not for the 'long' section, moving a test to long removes testing coverage so: A. InsertUpdateIfConditionTest has been split into 3 themes: std, collections and statics and it does _not_ move to 'long' section B. ViewComplexTest has been split into 3 themes: std, deletions and TTL that should be good enough for the 'long' section. The q I have now is double: first wdyt? and secondly is whether we should split ViewComplexTest further so it can go back away from 'long' to the std test path bc of test coverage reasons? > Flaky ViewComplexTest and InsertUpdateIfConditionTest > - > > Key: CASSANDRA-16670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16670 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.x > > > *ViewComplexTest* > Flaky > [test|https://ci-cassandra.apache.org/job/Cassandra-4.0/43/testReport/junit/org.apache.cassandra.cql3/ViewComplexTest/testPartialDeleteSelectedColumnWithoutFlush_3_/] > *InsertUpdateIfConditionTest* (CASSANDRA-16676) > Fails > [here|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/testListItem_2__clusterMinVersion_4_0_0_rc2_SNAPSHOT_/] > with a timeout. We can see in the history it takes quite a while in > [CI|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/history/] > _but_ it takes just 1m locally. Probably due to constrained resources. > Looking at the > [individual|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/] > test cases, for compression i.e., we can see 378 at an average of 1s each it > can easily go over the timeout of 240s. Recommendation is to either move to > 'long' section of to raise the timeout for the class for CI. -- 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-16683) offline_tools_test.py::TestOfflineTools::test_sstableverify does not validate that verify fails so has not been doing its check since 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-16683:
Status: Ready to Commit (was: Review In Progress)
+1
> offline_tools_test.py::TestOfflineTools::test_sstableverify does not validate
> that verify fails so has not been doing its check since 3.0
> -
>
> Key: CASSANDRA-16683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16683
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python, Tool/sstable
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> offline_tools_test.py::TestOfflineTools::test_sstableverify has the following
> check
> {code}
>try:
>(out, error, rc) = node1.run_sstableverify("keyspace1",
> "standard1", options=['-v'])
>except ToolError as e:
># Process sstableverify output to normalize paths in string to
> Python casing as above
>error = re.sub("(?<=Corrupted: ).*", lambda match:
> os.path.normcase(match.group(0)), str(e))
>assert re.search("Corrupted: " + sstable1, error)
>assert e.exit_status == 1, str(e.exit_status)
> {code}
> This checks if the corrupt log is present IFF ToolError is thrown, but does
> not validate that the error is actually thrown. I tried calling the same
> logic before the try to validate and see that it does not fail. If we fix
> the test to check for error we also see that the log that is returned to the
> user does not match 2.2’s behavior but instead returns different logic as
> digest validation throws IOException, which we do not convert to a
> CorruptSSTableException (which is the message the test checks for).
> This also shows another big issue, that when the digest fails verify passes
--
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-16683) offline_tools_test.py::TestOfflineTools::test_sstableverify does not validate that verify fails so has not been doing its check since 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-16683:
Reviewers: Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson)
Marcus Eriksson, Marcus Eriksson
Status: Review In Progress (was: Patch Available)
> offline_tools_test.py::TestOfflineTools::test_sstableverify does not validate
> that verify fails so has not been doing its check since 3.0
> -
>
> Key: CASSANDRA-16683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16683
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python, Tool/sstable
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> offline_tools_test.py::TestOfflineTools::test_sstableverify has the following
> check
> {code}
>try:
>(out, error, rc) = node1.run_sstableverify("keyspace1",
> "standard1", options=['-v'])
>except ToolError as e:
># Process sstableverify output to normalize paths in string to
> Python casing as above
>error = re.sub("(?<=Corrupted: ).*", lambda match:
> os.path.normcase(match.group(0)), str(e))
>assert re.search("Corrupted: " + sstable1, error)
>assert e.exit_status == 1, str(e.exit_status)
> {code}
> This checks if the corrupt log is present IFF ToolError is thrown, but does
> not validate that the error is actually thrown. I tried calling the same
> logic before the try to validate and see that it does not fail. If we fix
> the test to check for error we also see that the log that is returned to the
> user does not match 2.2’s behavior but instead returns different logic as
> digest validation throws IOException, which we do not convert to a
> CorruptSSTableException (which is the message the test checks for).
> This also shows another big issue, that when the digest fails verify passes
--
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-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
[
https://issues.apache.org/jira/browse/CASSANDRA-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349034#comment-17349034
]
Berenguer Blasi edited comment on CASSANDRA-16637 at 5/21/21, 7:09 AM:
---
I would also favor commenting it out with a note and a ticket reference.
Although my preference would be to try to skip by actually detecting the
version if that is possible and we're not in a hot path. I would also open a
ticket as a reminder. Hope it makes sense.
was (Author: bereng):
I would also favor commenting it out with a note a ticket reference. Although
my preference would be to try to skip by actually detecting the version if that
is possible and we're not in a hot path. I would also open a ticket as a
reminder. Hope it makes sense.
> LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
> --
>
> Key: CASSANDRA-16637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Adam Holmberg
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x
>
>
> Test is failing occasionally as follows:
> {noformat}
> Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
> at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
> at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
> at
> org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
> 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)
> {noformat}
> [Recent
> ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
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-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
[
https://issues.apache.org/jira/browse/CASSANDRA-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16637:
Reviewers: Berenguer Blasi
> LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
> --
>
> Key: CASSANDRA-16637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Adam Holmberg
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x
>
>
> Test is failing occasionally as follows:
> {noformat}
> Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
> at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
> at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
> at
> org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
> 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)
> {noformat}
> [Recent
> ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
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-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
[
https://issues.apache.org/jira/browse/CASSANDRA-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349034#comment-17349034
]
Berenguer Blasi commented on CASSANDRA-16637:
-
I would also favor commenting it out with a note a ticket reference. Although
my preference would be to try to skip by actually detecting the version if that
is possible and we're not in a hot path. I would also open a ticket as a
reminder. Hope it makes sense.
> LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
> --
>
> Key: CASSANDRA-16637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Adam Holmberg
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x
>
>
> Test is failing occasionally as follows:
> {noformat}
> Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
> at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
> at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
> at
> org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
> 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)
> {noformat}
> [Recent
> ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
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
