[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17274: --- Source Control Link: https://github.com/apache/cassandra-website/commit/a0022ebd77c4ae2fa234dda3d9ed6d27b4f839e7 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [a0022ebd77c4ae2fa234dda3d9ed6d27b4f839e7|https://github.com/apache/cassandra-website/commit/a0022ebd77c4ae2fa234dda3d9ed6d27b4f839e7]. > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. > > Cause for the issue was in content we were using the URL macro but instead > have to use link macro. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: Fix link syntax community component
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/trunk by this push:
new a0022eb Fix link syntax community component
a0022eb is described below
commit a0022ebd77c4ae2fa234dda3d9ed6d27b4f839e7
Author: Yash Ladha
AuthorDate: Fri Jan 21 10:52:08 2022 +0530
Fix link syntax community component
Previously, link for contribute to cassandra was broken and rendered as
plaintext instead of a link tag, this was because the link was a relative
instead of absolute link and URL macro was not able to understand that.
Using link macro solved the issue and corrected the path to
development/index.html for contribute to cassandra.
patch by Yash Ladha; reviewed by Mick Semb Wever for CASSANDRA-17274
---
site-content/source/modules/ROOT/pages/community.adoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/site-content/source/modules/ROOT/pages/community.adoc
b/site-content/source/modules/ROOT/pages/community.adoc
index e290da7..f7138f3 100644
--- a/site-content/source/modules/ROOT/pages/community.adoc
+++ b/site-content/source/modules/ROOT/pages/community.adoc
@@ -331,7 +331,7 @@ https://www.apache.org/theapacheway/index.html[The Apache
Way,window=blank]
[openblock, float75 full-800]
--
-Contributors are individuals who contribute patches—source code,
documentation, help on mailing lists, website—to Apache projects. While
contributors do not have a specific governance role, they are crucial to the
project’s success. Read the docs to learn how to
{site-url}doc/latest/development/index.html[contribute to
Cassandra,window=blank], and review our
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance[governance,window=blank]
page to understa [...]
+Contributors are individuals who contribute patches—source code,
documentation, help on mailing lists, website—to Apache projects. While
contributors do not have a specific governance role, they are crucial to the
project’s success. Read the docs to learn how to
link:{site-url}_/development/index.html[contribute to Cassandra,window=blank],
and review our
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance[governance,window=blank]
page to understand h [...]
--
// end row
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17274: --- Status: Ready to Commit (was: Review In Progress) +1 tested locally. > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. > > Cause for the issue was in content we were using the URL macro but instead > have to use link macro. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17274: --- Test and Documentation Plan: UI Status: Patch Available (was: Open) > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. > > Cause for the issue was in content we were using the URL macro but instead > have to use link macro. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17274: --- Status: Review In Progress (was: Patch Available) > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. > > Cause for the issue was in content we were using the URL macro but instead > have to use link macro. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17274: --- Change Category: Semantic Complexity: Low Hanging Fruit Fix Version/s: NA Reviewers: Michael Semb Wever Status: Open (was: Triage Needed) > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. > > Cause for the issue was in content we were using the URL macro but instead > have to use link macro. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17265) dtest byteman errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479841#comment-17479841 ] Berenguer Blasi commented on CASSANDRA-17265: - ^yes I noticed that. It is being skipped _without_ vnodes but ran _with_ vnodes. > dtest byteman errors > > > Key: CASSANDRA-17265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17265 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x > > > Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on > missing btm files. I checked and the files _are there_. Also it doesn't repro > locally. See 4.0 vanilla runs > [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yash Ladha updated CASSANDRA-17274: --- Impacts: Docs (was: None) > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Labels: pull-request-available > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. > > Cause for the issue was in content we were using the URL macro but instead > have to use link macro. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yash Ladha updated CASSANDRA-17274: --- Description: When visiting the community page of cassandra and going to `How to contribute` session the link is not rendered properly. !image-2022-01-21-10-45-44-885.png! We can see that _contribute to Cassandra_ is a simple text instead of a blank link tag. Cause for the issue was in content we were using the URL macro but instead have to use link macro. was: When visiting the community page of cassandra and going to `How to contribute` session the link is not rendered properly. !image-2022-01-21-10-45-44-885.png! We can see that _contribute to Cassandra_ is a simple text instead of a blank link tag. > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Labels: pull-request-available > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. > > Cause for the issue was in content we were using the URL macro but instead > have to use link macro. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479832#comment-17479832 ] Yash Ladha commented on CASSANDRA-17274: Created PR : [https://github.com/apache/cassandra-website/pull/92] to fix the issue. > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Labels: pull-request-available > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. > > Cause for the issue was in content we were using the URL macro but instead > have to use link macro. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17274: --- Labels: pull-request-available (was: ) > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Labels: pull-request-available > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yash Ladha updated CASSANDRA-17274: --- Component/s: Documentation/Website > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yash Ladha updated CASSANDRA-17274: --- Attachment: (was: image-2022-01-21-10-43-55-144.png) > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
Yash Ladha created CASSANDRA-17274: -- Summary: Broken link for contribute to cassandra on community page Key: CASSANDRA-17274 URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 Project: Cassandra Issue Type: Task Reporter: Yash Ladha Assignee: Yash Ladha Attachments: image-2022-01-21-10-45-44-885.png When visiting the community page of cassandra and going to `How to contribute` session the link is not rendered properly. !image-2022-01-21-10-43-55-144.png! We can see that _contribute to Cassandra_ is a simple text instead of a blank link tag. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yash Ladha updated CASSANDRA-17274: --- Attachment: image-2022-01-21-10-45-44-885.png > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yash Ladha updated CASSANDRA-17274: --- Description: When visiting the community page of cassandra and going to `How to contribute` session the link is not rendered properly. !image-2022-01-21-10-45-44-885.png! We can see that _contribute to Cassandra_ is a simple text instead of a blank link tag. was: When visiting the community page of cassandra and going to `How to contribute` session the link is not rendered properly. !image-2022-01-21-10-43-55-144.png! We can see that _contribute to Cassandra_ is a simple text instead of a blank link tag. > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17265) dtest byteman errors
[
https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479821#comment-17479821
]
Brandon Williams edited comment on CASSANDRA-17265 at 1/21/22, 4:47 AM:
FWIW, I think that test is being skipped on jenkins, here's why on my lab
(where cassandra is on trunk):
{code}
$ pytest --cassandra-dir=~/cassandra --keep-failed-test-dir
read_repair_test.py::TestReadRepairGuarantees::test_atomic_writes -rsx
==
test session starts
===
platform linux -- Python 3.8.10, pytest-3.6.4, py-1.11.0, pluggy-0.7.1
rootdir: /home/cassandra/cassandra-dtest, inifile: pytest.ini
plugins: timeout-1.4.2, repeat-0.9.1, flaky-3.7.0
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 2 items
read_repair_test.py ss
[100%]
short test summary info
=
SKIP [2] /home/cassandra/cassandra-dtest/conftest.py:507: ported to in-JVM from
4.0 >= 4.1
{code}
was (Author: brandon.williams):
FWIW, I think that test is being skipped on jenkins, here's why on my lab
(where cassandra is on trunk):
{quote}
$ pytest --cassandra-dir=~/cassandra --keep-failed-test-dir
read_repair_test.py::TestReadRepairGuarantees::test_atomic_writes -rsx
==
test session starts
===
platform linux -- Python 3.8.10, pytest-3.6.4, py-1.11.0, pluggy-0.7.1
rootdir: /home/cassandra/cassandra-dtest, inifile: pytest.ini
plugins: timeout-1.4.2, repeat-0.9.1, flaky-3.7.0
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 2 items
read_repair_test.py ss
[100%]
short test summary info
=
SKIP [2] /home/cassandra/cassandra-dtest/conftest.py:507: ported to in-JVM from
4.0 >= 4.1
{quote}
> dtest byteman errors
>
>
> Key: CASSANDRA-17265
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17265
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on
> missing btm files. I checked and the files _are there_. Also it doesn't repro
> locally. See 4.0 vanilla runs
> [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17265) dtest byteman errors
[
https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479821#comment-17479821
]
Brandon Williams commented on CASSANDRA-17265:
--
FWIW, I think that test is being skipped on jenkins, here's why on my lab
(where cassandra is on trunk):
{quote}
$ pytest --cassandra-dir=~/cassandra --keep-failed-test-dir
read_repair_test.py::TestReadRepairGuarantees::test_atomic_writes -rsx
==
test session starts
===
platform linux -- Python 3.8.10, pytest-3.6.4, py-1.11.0, pluggy-0.7.1
rootdir: /home/cassandra/cassandra-dtest, inifile: pytest.ini
plugins: timeout-1.4.2, repeat-0.9.1, flaky-3.7.0
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 2 items
read_repair_test.py ss
[100%]
short test summary info
=
SKIP [2] /home/cassandra/cassandra-dtest/conftest.py:507: ported to in-JVM from
4.0 >= 4.1
{quote}
> dtest byteman errors
>
>
> Key: CASSANDRA-17265
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17265
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on
> missing btm files. I checked and the files _are there_. Also it doesn't repro
> locally. See 4.0 vanilla runs
> [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (a3f12f5 -> c5a1b27)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard a3f12f5 generate docs for 540e0817 new c5a1b27 generate docs for 540e0817 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (a3f12f5) \ N -- N -- N refs/heads/asf-staging (c5a1b27) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740057 -> 4740057 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (cecfb7e -> a3f12f5)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard cecfb7e generate docs for 540e0817 new a3f12f5 generate docs for 540e0817 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (cecfb7e) \ N -- N -- N refs/heads/asf-staging (a3f12f5) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740057 -> 4740057 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479794#comment-17479794
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/21/22, 2:53 AM:
---
The CI lgtm, there are all known failures. The byteman issues appear again but
they turned to be general problem with CircleCI. There is already a ticket for
investigation.
One thing on my mind is - there was a question whether we should use "fail" or
"abort" if I am not mistaken. I noticed that only recently "abort" was
introduced, "fail" is widely used in our config. I would suggest to stick to
"fail" as it is already common for our users. Of course, I will be happy to
hear if someone has a different perspective on this topic.
Also, my understanding is that [~dcapwell](from offline discussion) and
[~maedhroz] are done with their reviews. [~blerer] is swamped at the moment
but I want to thank him for all his support and feedback at the early stages.
My understanding is [~mck] is about to do a final review and then we can commit
when he is ready and of course, I address any potential concerns he might have.
I will also do another pass tomorrow as the patch is big and widely spread
around the codebase. [~mck] , please, let me know if you want me to squash
already the work; what is easier for you to review.
was (Author: e.dimitrova):
The CI lgtm, there are all known failures. The byteman issues appear again but
they turned to be general problem with CircleCI. There is already a ticket for
investigation.
One thing on my mind is - there was a question whether we should use "fail" or
"abort" if I am not mistaken. I noticed that only recently "abort" was
introduced, "fail" is widely used in our config. I would suggest to stick to
"fail" as it is already common for our users. Of course, I will be happy to
hear if someone has a different perspective on this topic.
Also, my understanding is that [~dcapwell](from offline discussion) and
[~maedhroz] are done with their reviews. [~blerer] is swamped at the moment
but I want to thank him for all his support and feedback at the early stages.
My understanding is [~mck] is about to do a final review and then we can commit
when he is ready and of course, I address any potential concerns he might have.
I will also do another pass tomorrow as the patch is big and widely spread
around the codebase.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479794#comment-17479794
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
The CI lgtm, there are all known failures. The byteman issues appear again but
they turned to be general problem with CircleCI. There is already a ticket for
investigation.
One thing on my mind is - there was a question whether we should use "fail" or
"abort" if I am not mistaken. I noticed that only recently "abort" was
introduced, "fail" is widely used in our config. I would suggest to stick to
"fail" as it is already common for our users. Of course, I will be happy to
hear if someone has a different perspective on this topic.
Also, my understanding is that [~dcapwell](from offline discussion) and
[~maedhroz] are done with their reviews. [~blerer] is swamped at the moment
but I want to thank him for all his support and feedback at the early stages.
My understanding is [~mck] is about to do a final review and then we can commit
when he is ready and of course, I address any potential concerns he might have.
I will also do another pass tomorrow as the patch is big and widely spread
around the codebase.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (cce6f78 -> cecfb7e)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard cce6f78 generate docs for 540e0817 new cecfb7e generate docs for 540e0817 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (cce6f78) \ N -- N -- N refs/heads/asf-staging (cecfb7e) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740057 -> 4740057 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17273) Lazy transaction log replica creation allows incorrect replica content divergence during anticompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479738#comment-17479738
]
Caleb Rackliffe commented on CASSANDRA-17273:
-
[~marcuse] noted that this may not be an issue on 3.11+ w/ CASSANDRA-6696 in
place there.
> Lazy transaction log replica creation allows incorrect replica content
> divergence during anticompaction
> ---
>
> Key: CASSANDRA-17273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17273
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Recently encountered this around compaction/anticompaction:
> {noformat}
> 2022-01-13 10:18:24,325 ERROR [main]
> org.apache.cassandra.db.lifecycle.LogTransaction - Unexpected disk state:
> failed to read transaction log
> [mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log in
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f,
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f]
> Files and contents follow:
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350437-big,0,8][4051162457]
> ***Does not match
>
> in first replica file
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> {noformat}
> We have two data directories and two transaction log files, but one is
> missing an ADD entry when the contents of the two log replicas should be
> identical. One scenario that can cause this is the following:
> 1. Start anticompaction on a single file, in directory {{/tmp/d0}}.
> 2. Call {{trackNew()}} with 2 new files, both in a single directory, but in
> directory {{/tmp/d1}}. This initializes the log file in {{/tmp/d1}}, but
> there is still no log file in {{/tmp/d0}}.
> 3. Anticompaction only writes to one of the files in {{/tmp/d1}} (say all
> other keys were outside the repaired range).
> 4. When anticompaction is done, the empty writer is aborted and we call
> {{untrackNew()}}, which removes the added file from the registered log
> “records" (BUT NOT FROM DISK in {{/tmp/d1}}).
> 5. The REMOVE record is added. This references {{/tmp/d0}}. We lazily create
> the log file there by dumping all the records we have in memory to that file,
> which does not include the aborted SSTable above.
> 6. Now the log files contain:
> {noformat}
> /tmp/d1/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-2-big,0,8][3268492367]
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> ** /tmp/d0/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17273) Lazy transaction log replica creation allows incorrect replica content divergence during anticompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17273:
-
Fix Version/s: (was: 4.1)
> Lazy transaction log replica creation allows incorrect replica content
> divergence during anticompaction
> ---
>
> Key: CASSANDRA-17273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17273
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Recently encountered this around compaction/anticompaction:
> {noformat}
> 2022-01-13 10:18:24,325 ERROR [main]
> org.apache.cassandra.db.lifecycle.LogTransaction - Unexpected disk state:
> failed to read transaction log
> [mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log in
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f,
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f]
> Files and contents follow:
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350437-big,0,8][4051162457]
> ***Does not match
>
> in first replica file
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> {noformat}
> We have two data directories and two transaction log files, but one is
> missing an ADD entry when the contents of the two log replicas should be
> identical. One scenario that can cause this is the following:
> 1. Start anticompaction on a single file, in directory {{/tmp/d0}}.
> 2. Call {{trackNew()}} with 2 new files, both in a single directory, but in
> directory {{/tmp/d1}}. This initializes the log file in {{/tmp/d1}}, but
> there is still no log file in {{/tmp/d0}}.
> 3. Anticompaction only writes to one of the files in {{/tmp/d1}} (say all
> other keys were outside the repaired range).
> 4. When anticompaction is done, the empty writer is aborted and we call
> {{untrackNew()}}, which removes the added file from the registered log
> “records" (BUT NOT FROM DISK in {{/tmp/d1}}).
> 5. The REMOVE record is added. This references {{/tmp/d0}}. We lazily create
> the log file there by dumping all the records we have in memory to that file,
> which does not include the aborted SSTable above.
> 6. Now the log files contain:
> {noformat}
> /tmp/d1/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-2-big,0,8][3268492367]
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> ** /tmp/d0/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (f744ea9 -> cce6f78)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard f744ea9 generate docs for 540e0817 new cce6f78 generate docs for 540e0817 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (f744ea9) \ N -- N -- N refs/heads/asf-staging (cce6f78) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740057 -> 4740057 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17273) Lazy transaction log replica creation allows incorrect replica content divergence during anticompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17273:
Bug Category: Parent values: Availability(12983)Level 1 values: Process
Crash(12992)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 4.1
3.0.x
3.11.x
4.0.x
4.x
Severity: Critical
Status: Open (was: Triage Needed)
> Lazy transaction log replica creation allows incorrect replica content
> divergence during anticompaction
> ---
>
> Key: CASSANDRA-17273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17273
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1, 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Recently encountered this around compaction/anticompaction:
> {noformat}
> 2022-01-13 10:18:24,325 ERROR [main]
> org.apache.cassandra.db.lifecycle.LogTransaction - Unexpected disk state:
> failed to read transaction log
> [mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log in
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f,
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f]
> Files and contents follow:
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350437-big,0,8][4051162457]
> ***Does not match
>
> in first replica file
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> {noformat}
> We have two data directories and two transaction log files, but one is
> missing an ADD entry when the contents of the two log replicas should be
> identical. One scenario that can cause this is the following:
> 1. Start anticompaction on a single file, in directory {{/tmp/d0}}.
> 2. Call {{trackNew()}} with 2 new files, both in a single directory, but in
> directory {{/tmp/d1}}. This initializes the log file in {{/tmp/d1}}, but
> there is still no log file in {{/tmp/d0}}.
> 3. Anticompaction only writes to one of the files in {{/tmp/d1}} (say all
> other keys were outside the repaired range).
> 4. When anticompaction is done, the empty writer is aborted and we call
> {{untrackNew()}}, which removes the added file from the registered log
> “records" (BUT NOT FROM DISK in {{/tmp/d1}}).
> 5. The REMOVE record is added. This references {{/tmp/d0}}. We lazily create
> the log file there by dumping all the records we have in memory to that file,
> which does not include the aborted SSTable above.
> 6. Now the log files contain:
> {noformat}
> /tmp/d1/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-2-big,0,8][3268492367]
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> ** /tmp/d0/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
[jira] [Created] (CASSANDRA-17273) Lazy transaction log replica creation allows incorrect replica content divergence during anticompaction
Caleb Rackliffe created CASSANDRA-17273:
---
Summary: Lazy transaction log replica creation allows incorrect
replica content divergence during anticompaction
Key: CASSANDRA-17273
URL: https://issues.apache.org/jira/browse/CASSANDRA-17273
Project: Cassandra
Issue Type: Bug
Components: Consistency/Repair, Local/Compaction
Reporter: Caleb Rackliffe
Assignee: Caleb Rackliffe
Recently encountered this around compaction/anticompaction:
{noformat}
2022-01-13 10:18:24,325 ERROR [main]
org.apache.cassandra.db.lifecycle.LogTransaction - Unexpected disk state:
failed to read transaction log
[mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log in
.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f,
.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f]
Files and contents follow:
.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
COMMIT:[,0,0][2613697770]
.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350437-big,0,8][4051162457]
***Does not match
in first replica file
ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
COMMIT:[,0,0][2613697770]
{noformat}
We have two data directories and two transaction log files, but one is missing
an ADD entry when the contents of the two log replicas should be identical. One
scenario that can cause this is the following:
1. Start anticompaction on a single file, in directory {{/tmp/d0}}.
2. Call {{trackNew()}} with 2 new files, both in a single directory, but in
directory {{/tmp/d1}}. This initializes the log file in {{/tmp/d1}}, but there
is still no log file in {{/tmp/d0}}.
3. Anticompaction only writes to one of the files in {{/tmp/d1}} (say all other
keys were outside the repaired range).
4. When anticompaction is done, the empty writer is aborted and we call
{{untrackNew()}}, which removes the added file from the registered log
“records" (BUT NOT FROM DISK in {{/tmp/d1}}).
5. The REMOVE record is added. This references {{/tmp/d0}}. We lazily create
the log file there by dumping all the records we have in memory to that file,
which does not include the aborted SSTable above.
6. Now the log files contain:
{noformat}
/tmp/d1/logfile.log:
ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-2-big,0,8][3268492367]
ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
COMMIT:[,0,0][2613697770]
** /tmp/d0/logfile.log:
ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
COMMIT:[,0,0][2613697770]
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479733#comment-17479733
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
[~maedhroz] I just rebased (both Cassandra and Cassandra-dtest) and pushed the
updated as per your review patch. Still keeping things in separate commits for
historical purposes until I have a go to squash things. Starting CI here -
[j8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1276/workflows/2a49cd4f-d543-4b4c-966b-7cfe0c80f592]
and
[j11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1276/workflows/39a8545b-b44d-46e9-a374-acc86dbe5da0]
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479711#comment-17479711
]
Caleb Rackliffe commented on CASSANDRA-17212:
-
100% agree about {{replica_filtering_protection}}. I don't think there's a
single nesting strategy that will be most elegant for every feature. In the
long term, I would like to see us move toward nesting, even if that has to
happen incrementally and imperfectly. (It seems like we've at least gotten some
consensus for this in the {{[DISCUSS] Nested YAML configs for new features}}
thread on the dev list already.)
I won't push for blocking this or CASSANDRA-17188 on a comprehensive plan for
changing the entire structure of {{cassandra.yaml}}, but let's at least take
care with how we lay things out now in case they later might fall into the
proposals we've sketched out
[here|https://github.com/maedhroz/cassandra/commit/49e83c70eba3357978d1081ecf500bbbdee960d8]
and
[here|https://github.com/belliottsmith/cassandra/commits/CASSANDRA-15234-grouping-ideas].
[~benedict] Given the discussion we've already had on the dev list, perhaps the
best course would be to retrofit our nesting proposals once CASSANDRA-15234
merges and post them in a new Jira, then pursue discussion there.
Interactions w/ CASSANDRA-15234 should be easy enough to spot in review. (No
units in new parameter names, etc.)
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[
https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479683#comment-17479683
]
Caleb Rackliffe edited comment on CASSANDRA-16262 at 1/20/22, 9:33 PM:
---
I attempted to build the branch again this afternoon:
1.) Cleared local maven cache
2.) Moved aside existing {{settings.xml}}
3.) git clean -fxd && ant realclean && ant jar && ant build-test && ant
generate-idea-files
Got the following:
{noformat}
[retry] Attempt [0]: error occurred; retrying...
[resolver:resolve] Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[retry] Attempt [1]: error occurred; retrying...
[resolver:resolve] Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[retry] Attempt [2]: error occurred; retrying...
[resolver:resolve] Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479687#comment-17479687
]
Andres de la Peña commented on CASSANDRA-17212:
---
I don't find that structure so appealing for things like the thresholds for
{{{}replica_filtering_protection{}}}. I understand that in that spirit it will
look like:
{code:java}
limits:
warn:
replica_filtering_protection_cached_rows: 2000
(other warn thresholds)
fail:
replica_filtering_protection_cached_rows: 32000
(other fail thresholds)
{code}
Where would we place the detailed comments about what RFP is, and what its
cache does, etc.? Should we repeat the comments in both the warn and the fail
thresholds? I don't think we can find a self-documenting name for something
like that.
That said, the property {{default_keyspace_rf}} doesn't match what is covered
by thresholds, and probably we are not interested on a warn threshold for
replication factor. So maybe we should just not use guardrails for this one,
independently of how we structure the config file.
As for restructuring the config file in general, that seems to deserve a
separate ticket and probably a discussion on the mail list, especially if
that's going to block work on other features like new guardrails like
CASSANDRA-17188, wdyt?
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[
https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479683#comment-17479683
]
Caleb Rackliffe commented on CASSANDRA-16262:
-
I attempted to build the branch again this afternoon:
1.) Cleared local maven cache
2.) Moved aside existing {{settings.xml}}
3.) git clean -fxd && ant realclean && ant jar && ant build-test && ant
generate-idea-files
Got the following:
{noformat}
[retry] Attempt [0]: error occurred; retrying...
[resolver:resolve] Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[retry] Attempt [1]: error occurred; retrying...
[resolver:resolve] Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[retry] Attempt [2]: error occurred; retrying...
[resolver:resolve] Could not transfer metadata
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xml from/to
resolver-apache-snapshots (${artifact.remoteRepository.apacheSnapshots}):
Cannot access ${artifact.remoteRepository.apacheSnapshots} with type default
using the available connector factories: BasicRepositoryConnectorFactory
[resolver:resolve]
org.apache.cassandra:harry-core:1.0.0-SNAPSHOT/maven-metadata.xmlfailed to
transfer from ${artifact.remoteRepository.apacheSnapshots} during a previous
attempt. This failure was cached in the local repository and resolution will
not be reattempted until the update interval of resolver-apache-snapshots has
elapsed or updates are forced. Original error: Could not transfer metadata
org.apache.cassandra:harry-c
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479671#comment-17479671
]
Andres de la Peña commented on CASSANDRA-17188:
---
[~maedhroz] are you proposing to stop all the work on the guardrails epic
(CASSANDRA-17146) and any new config property in general until we get to an
agreement on restructuring the yaml? I don't think we should stop progress on
this waiting for a config restructuring that we don't know if/when is going to
happen. If that's the case probably we should have that discussion on the mail
list, and see if we should freeze the config for all new properties.
Even if we are going to end up with a different config format in the end, I
don't think we should stop the work on other features that require config
properties, since restructuring the config on a later patch is relatively easy
compared to doing the configurable feature. In the case of guardrails, most of
the effort is in preparing the guardrail instance, finding the places where the
check should be done and writing the tests, and rearranging the config should
be quite easy.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (f04aaf7 -> f744ea9)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard f04aaf7 generate docs for 540e0817 new f744ea9 generate docs for 540e0817 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (f04aaf7) \ N -- N -- N refs/heads/asf-staging (f744ea9) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../4.0.0/cassandra/tools/nodetool/bootstrap.html | 8 +- .../4.0.0/cassandra/tools/nodetool/nodetool.html | 10 +-- .../cassandra/tools/nodetool/repair_admin.html | 85 +-- .../4.0.1/cassandra/tools/nodetool/bootstrap.html | 8 +- .../4.0.1/cassandra/tools/nodetool/nodetool.html | 10 +-- .../cassandra/tools/nodetool/repair_admin.html | 85 +-- .../4.0/cassandra/tools/nodetool/bootstrap.html| 8 +- .../doc/4.0/cassandra/tools/nodetool/nodetool.html | 10 +-- .../4.0/cassandra/tools/nodetool/repair_admin.html | 85 +-- .../4.1/cassandra/tools/nodetool/bootstrap.html| 8 +- .../doc/4.1/cassandra/tools/nodetool/nodetool.html | 9 ++- .../4.1/cassandra/tools/nodetool/repair_admin.html | 90 ++--- .../latest/cassandra/tools/nodetool/bootstrap.html | 8 +- .../latest/cassandra/tools/nodetool/nodetool.html | 9 ++- .../cassandra/tools/nodetool/repair_admin.html | 90 ++--- .../stable/cassandra/tools/nodetool/bootstrap.html | 8 +- .../stable/cassandra/tools/nodetool/nodetool.html | 10 +-- .../cassandra/tools/nodetool/repair_admin.html | 85 +-- .../trunk/cassandra/tools/nodetool/bootstrap.html | 8 +- .../trunk/cassandra/tools/nodetool/nodetool.html | 9 ++- .../cassandra/tools/nodetool/repair_admin.html | 90 ++--- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4740057 -> 4740057 bytes 23 files changed, 371 insertions(+), 364 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479620#comment-17479620
]
Stefan Miklosovic commented on CASSANDRA-16956:
---
Aha, this is interesting, I forgot about that one. Hence it seems that they can
not even run it if they do not somehow get these scripts back, so the code in
4.0.x, as is, is even not (practically) "invokable" / runnnable on Windows. So
it is truly a dead code.
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc, signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479596#comment-17479596 ] Brandon Williams edited comment on CASSANDRA-17242 at 1/20/22, 7:09 PM: No worries, it was tagged 4.0.x earlier, you probably caught that update. Adding a jenkins run to see if anything needs to be disabled there. [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1373/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1373/pipeline] was (Author: brandon.williams): No worries, it was tagged 4.0.x earlier, you probably caught that update. Adding a jenkins run to see if anything needs to be disabled there. [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1372/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1372/pipeline] > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479614#comment-17479614
]
Brandon Williams commented on CASSANDRA-16956:
--
Are you talking about reverting CASSANDRA-16171 where we already removed those?
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc, signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479609#comment-17479609
]
Josh McKenzie edited comment on CASSANDRA-16956 at 1/20/22, 6:58 PM:
-
{quote}once we say we do not support Windows on 4.0 a user can still run it
{quote}
Yeah, there's mingw and WSL as well so they can still do it that way if they're
so inclined. Maybe we update the headers on the .bat and .ps1 files and
NEWS.txt to indicate Windows isn't supported on 4.0 and they use it at their
own peril and point to this ticket, then do the removal on trunk?
was (Author: jmckenzie):
{quote}once we say we do not support Windows on 4.0 a user can still run it
{quote}
Yeah, there's mingw and WSL as well so they can still do it that way as well.
Maybe we update the headers on the .bat and .ps1 files and NEWS.txt to indicate
Windows isn't supported on 4.0 and they use it at their own peril and point to
this ticket, then do the removal on trunk?
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc, signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479609#comment-17479609
]
Josh McKenzie commented on CASSANDRA-16956:
---
{quote}once we say we do not support Windows on 4.0 a user can still run it
{quote}
Yeah, there's mingw and WSL as well so they can still do it that way as well.
Maybe we update the headers on the .bat and .ps1 files and NEWS.txt to indicate
Windows isn't supported on 4.0 and they use it at their own peril and point to
this ticket, then do the removal on trunk?
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc, signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479596#comment-17479596 ] Brandon Williams commented on CASSANDRA-17242: -- No worries, it was tagged 4.0.x earlier, you probably caught that update. Adding a jenkins run to see if anything needs to be disabled there. [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1372/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1372/pipeline] > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Status: Review In Progress (was: Patch Available)
> Dtest cluster reusage
> -
>
> Key: CASSANDRA-16951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16951
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Dtests are very heavy but in some instances most of the time is spent
> restarting nodes in between test methods. Not all of them, but many seem
> could benefit form reusing a common cluster sparing the restarts. Obviously
> that is not the case for tests that manipulate the nodes itself during the
> test. The ones that follow a setup node/do test seem to benefit greatly in
> terms of time execution.
> Some classes run time can be cut form 10m to 1,5m. Others only from 30m to
> 25m. But taking a 5m shave and considering it will probably get ran *
> with/without vnodes * j8/j11/j8j11 * 4.0/trunk turns the 5m cut into a 60m
> cut. That should be a nice reduction in CI usage. Unfortunately run time will
> mostly remain the same until we have a majority of tests reusing nodes as the
> 'longest pole' will be the determining factor.
> How it works? It's an opt-in. Annotate the first test with
> {{@reuse_cluster(new_cluster=True)}} and the following ones with
> {{@reuse_cluster}}. Best effort to reuse the cluster will be made. Stop using
> the annotation at any test method and it will start a new one.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Status: Patch Available (was: In Progress)
> Dtest cluster reusage
> -
>
> Key: CASSANDRA-16951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16951
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Dtests are very heavy but in some instances most of the time is spent
> restarting nodes in between test methods. Not all of them, but many seem
> could benefit form reusing a common cluster sparing the restarts. Obviously
> that is not the case for tests that manipulate the nodes itself during the
> test. The ones that follow a setup node/do test seem to benefit greatly in
> terms of time execution.
> Some classes run time can be cut form 10m to 1,5m. Others only from 30m to
> 25m. But taking a 5m shave and considering it will probably get ran *
> with/without vnodes * j8/j11/j8j11 * 4.0/trunk turns the 5m cut into a 60m
> cut. That should be a nice reduction in CI usage. Unfortunately run time will
> mostly remain the same until we have a majority of tests reusing nodes as the
> 'longest pole' will be the determining factor.
> How it works? It's an opt-in. Annotate the first test with
> {{@reuse_cluster(new_cluster=True)}} and the following ones with
> {{@reuse_cluster}}. Best effort to reuse the cluster will be made. Stop using
> the annotation at any test method and it will start a new one.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479580#comment-17479580 ] Ekaterina Dimitrova commented on CASSANDRA-17242: - I think I misread 4.0.x instead of 4.x. Please ignore me. Sorry for the noise. > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479543#comment-17479543 ] Brandon Williams commented on CASSANDRA-17242: -- It does target trunk? > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479543#comment-17479543 ] Brandon Williams edited comment on CASSANDRA-17242 at 1/20/22, 5:47 PM: It does target trunk? I'm not planning to remove it from 4.0 for reasons that you stated. was (Author: brandon.williams): It does target trunk? > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479541#comment-17479541
]
Caleb Rackliffe edited comment on CASSANDRA-17188 at 1/20/22, 5:39 PM:
---
Perhaps we should resolve the ongoing conversation around config structure in
CASSANDRA-17212 (which actually started in CASSANDRA-15234 before that was
focused on just human-readable parameter names) before we press forward w/ this?
was (Author: maedhroz):
Perhaps we should resolve the ongoing conversation around config structure in
CASSANDRA-17212 before we press forward w/ this?
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479541#comment-17479541
]
Caleb Rackliffe commented on CASSANDRA-17188:
-
Perhaps we should resolve the ongoing conversation around config structure in
CASSANDRA-17212 before we press forward w/ this?
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17148) Adapt track_warnings to Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479538#comment-17479538 ] Caleb Rackliffe commented on CASSANDRA-17148: - The only thing I'm a little worried about is that it might be best to continue w/ this when CASSANDRA-15234 lands, and when we can resolve the structural conversation in CASSANDRA-17212? (The former will affect parameter naming and the latter configuration structure.) CC [~benedict] [~e.dimitrova] > Adapt track_warnings to Guardrails > -- > > Key: CASSANDRA-17148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17148 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > The purpose of this ticket is adapting the warnings added by CASSANDRA-16850 > to use the new Guardrails framework. This will involve extending the > framework to be able to propagate warnings and failures triggered on > replicas, taking advantage of the machinery added in that ticket. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479535#comment-17479535
]
Caleb Rackliffe commented on CASSANDRA-17212:
-
Looking through the proposals so far, I find [~benedict]'s structure
[here|https://github.com/belliottsmith/cassandra/blob/5f80d1c0d38873b7a27dc137656d8b81f8e6bbd7/conf/cassandra_nocomment.yaml#L160]
most appealing. In that case, I think the CASSANDRA-14557 replication bits we
want would look something like...
{noformat}
limits:
...
replication:
minimum: 3
default: 1
{noformat}
On the subject of a global {{enable}} flag, that feels most appropriate for
individual categories or limit concepts. Most of its value is not having to
come up with special/sentinel values that disable something. (i.e. You can
leave something both disabled and w/ a reasonable value if enabled in the
config as documentation.)
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479534#comment-17479534 ] Ekaterina Dimitrova edited comment on CASSANDRA-17242 at 1/20/22, 5:28 PM: --- Quick question - shouldn't this target only trunk? I feel that was intentionally still there in 4.0. I think that cutting it in a patch release is not a good idea and contradicts with the release process probably was (Author: e.dimitrova): Quick question - shouldn't this target only trunk? > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479534#comment-17479534 ] Ekaterina Dimitrova commented on CASSANDRA-17242: - Quick question - shouldn't this target only trunk? > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479530#comment-17479530 ] Brandon Williams edited comment on CASSANDRA-17242 at 1/20/22, 5:21 PM: This looks good and I'm +1, but need to figure out how to disable the py2 dtest runs for trunk. was (Author: brandon.williams): This looks good and I'm +1, but need to figure out how to disable the py2 dtest runs for 4.0 and trunk. > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479530#comment-17479530 ] Brandon Williams commented on CASSANDRA-17242: -- This looks good and I'm +1, but need to figure out how to disable the py2 dtest runs for 4.0 and trunk. > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479504#comment-17479504
]
Stefan Miklosovic edited comment on CASSANDRA-16956 at 1/20/22, 4:50 PM:
-
Fair enough. I still consider it to be a bug based on the fact that once we say
we do not support Windows on 4.0 a user can still run it. It is as if (this is
purely hypothetical example) we said that we do not support materialized views
but they are still there. My take on it is that if it is not supported it
should not be there. We have quite comprehensive test suite to make a fair
assumption that it has not broken anything.
But again, I can totally live with that code in 4.0. You guys are longer here
and decisions like these are not always black and white.
btw, the fact is that it will be still in 4.0.0 and if there is somebody who
absolutely wants to run (any) 4.0 on Windows, it will be possible. So us
removing it in 4.0.x is kind of useless anyway. So looking at it from this
perspective, I would go with your argument to NOT remove it. We basically do
not eliminate people to run 4.0 on Windows if they really want so it is already
"too late". We might as well just leave it there.
was (Author: smiklosovic):
Fair enough. I still consider it to be a bug based on the fact that once we say
we do not support Windows on 4.0 a user can still run it. It is as if (this is
purely hypothetical example) we said that we do not support materialized views
but they are still there. My take on it is that if it is not supported it
should not be there. We have quite comprehensive test suite to make a fair
assumption that it has not broken anything.
But again, I can totally live with that code in 4.0. You guys are longer here
and decisions like these are not always black and white.
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc, signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479504#comment-17479504
]
Stefan Miklosovic commented on CASSANDRA-16956:
---
Fair enough. I still consider it to be a bug based on the fact that once we say
we do not support Windows on 4.0 a user can still run it. It is as if (this is
purely hypothetical example) we said that we do not support materialized views
but they are still there. My take on it is that if it is not supported it
should not be there. We have quite comprehensive test suite to make a fair
assumption that it has not broken anything.
But again, I can totally live with that code in 4.0. You guys are longer here
and decisions like these are not always black and white.
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc, signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17271) Remove unused dependency of geomet from cqlsh.py
[
https://issues.apache.org/jira/browse/CASSANDRA-17271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17271:
-
Fix Version/s: 4.0.2
4.1
(was: 4.x)
(was: 4.0.x)
Source Control Link:
https://github.com/apache/cassandra/commit/bccb5adf9518624147ee092971eb788e83d497f1
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks.
> Remove unused dependency of geomet from cqlsh.py
>
>
> Key: CASSANDRA-17271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17271
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.2, 4.1
>
>
> The python library *geomet* is used (optionally) by a unit test in the python
> driver, but was made optional in v3.24.0 of the cassandra-driver:
> * 👉 Make geomet an optional dependency at runtime (PYTHON-1237)
> It's inclusion on the sys.path for cqlsh would appear unnecessary and unused.
>
> cqlsh.py:
> {quote}third_parties = ('futures-', 'six-', 'geomet-'){quote}
> {quote}for lib in third_parties:
> lib_zip = find_zip(lib)
> if lib_zip:
> sys.path.insert(0, lib_zip){quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 9577fd36d681266ea2d4758c51ed506e940d0d0e Merge: fac84e0 bccb5ad Author: Brandon Williams AuthorDate: Thu Jan 20 10:09:36 2022 -0600 Merge branch 'cassandra-4.0' into trunk CHANGES.txt | 1 + bin/cqlsh.py | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --cc CHANGES.txt index b1d749d,1bde0c9..de77d25 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,82 -1,5 +1,83 @@@ -4.0.2 +4.1 + * Prewarm role and credential caches to avoid timeouts at startup (CASSANDRA-16958) + * Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool (CASSANDRA-17063) + * Added startup check for read_ahead_kb setting (CASSANDRA-16436) + * Avoid unecessary array allocations and initializations when performing query checks (CASSANDRA-17209) + * Add guardrail for list operations that require read before write (CASSANDRA-17154) + * Migrate thresholds for number of keyspaces and tables to guardrails (CASSANDRA-17195) + * Remove self-reference in SSTableTidier (CASSANDRA-17205) + * Add guardrail for query page size (CASSANDRA-17189) + * Allow column_index_size_in_kb to be configurable through nodetool (CASSANDRA-17121) + * Emit a metric for number of local read and write calls + * Add non-blocking mode for CDC writes (CASSANDRA-17001) + * Add guardrails framework (CASSANDRA-17147) + * Harden resource management on SSTable components to prevent future leaks (CASSANDRA-17174) + * Make nodes more resilient to local unrelated files during startup (CASSANDRA-17082) + * repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout (CASSANDRA-16992) + * Log queries that fail on timeout or unavailable errors up to once per minute by default (CASSANDRA-17159) + * Refactor normal/preview/IR repair to standardize repair cleanup and error handling of failed RepairJobs (CASSANDRA-17069) + * Log missing peers in StartupClusterConnectivityChecker (CASSANDRA-17130) + * Introduce separate rate limiting settings for entire SSTable streaming (CASSANDRA-17065) + * Implement Virtual Tables for Auth Caches (CASSANDRA-16914) + * Actively update auth cache in the background (CASSANDRA-16957) + * Add unix time conversion functions (CASSANDRA-17029) + * JVMStabilityInspector.forceHeapSpaceOomMaybe should handle all non-heap OOMs rather than only supporting direct only (CASSANDRA-17128) + * Forbid other Future implementations with checkstyle (CASSANDRA-17055) + * commit log was switched from non-daemon to daemon threads, which causes the JVM to exit in some case as no non-daemon threads are active (CASSANDRA-17085) + * Add a Denylist to block reads and writes on specific partition keys (CASSANDRA-12106) + * v4+ protocol did not clean up client warnings, which caused leaking the state (CASSANDRA-17054) + * Remove duplicate toCQLString in ReadCommand (CASSANDRA-17023) + * Ensure hint window is persistent across restarts of a node (CASSANDRA-14309) + * Allow to GRANT or REVOKE multiple permissions in a single statement (CASSANDRA-17030) + * Allow to grant permission for all tables in a keyspace (CASSANDRA-17027) + * Log time spent writing keys during compaction (CASSANDRA-17037) + * Make nodetool compactionstats and sstable_tasks consistent (CASSANDRA-16976) + * Add metrics and logging around index summary redistribution (CASSANDRA-17036) + * Add configuration options for minimum allowable replication factor and default replication factor (CASSANDRA-14557) + * Expose information about stored hints via a nodetool command and a virtual table (CASSANDRA-14795) + * Add broadcast_rpc_address to system.local (CASSANDRA-11181) + * Add support for type casting in WHERE clause components and in the values of INSERT/UPDATE statements (CASSANDRA-14337) + * add credentials file support to CQLSH (CASSANDRA-16983) + * Skip remaining bytes in the Envelope buffer when a ProtocolException is thrown to avoid double decoding (CASSANDRA-17026) + * Allow reverse iteration of resources during permissions checking (CASSANDRA-17016) + * Add feature to verify correct ownership of attached locations on disk at startup (CASSANDRA-16879) + * Make SSLContext creation pluggable/extensible (CASSANDRA-1) + * Add soft/hard limits to local reads to protect against reading too much data in a single query (CASSANDRA-16896) + * Avoid token cache invalidation for removing a non-member node (CASSANDRA-15290) + * Allow configuration of consistency levels on auth operations (CASSANDRA-12988) + * Add number of sstables in a compaction to compactionstats output (CASSANDRA-16844) + * Upgrade Caffeine to 2.9.2 (CASSANDRA-15153) + * Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it (CASSANDRA-16806) + * I
[cassandra] branch cassandra-4.0 updated: Remove path for unused geomet package in cqlsh
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams 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 bccb5ad Remove path for unused geomet package in cqlsh
bccb5ad is described below
commit bccb5adf9518624147ee092971eb788e83d497f1
Author: Brad Schoening <5796692+bschoen...@users.noreply.github.com>
AuthorDate: Tue Jan 18 18:46:36 2022 -0500
Remove path for unused geomet package in cqlsh
Patch by Brad Schoening; reviewed by brandonwilliams and bereng for
CASSANDRA-17271
Remove path for unused `geomet` package, which does not appear to be
used in CQLSH. It is an optional dependency of the cassandra-driver in
a test case.
---
CHANGES.txt | 1 +
bin/cqlsh.py | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index c176a47..1bde0c9 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0.2
+ * Remove unused 'geomet' package from cqlsh path (CASSANDRA-17271)
* Removed unused 'cql' dependency (CASSANDRA-17247)
* Don't block gossip when clearing repair snapshots (CASSANDRA-17168)
* Deduplicate warnings for deprecated parameters (changed names)
(CASSANDRA-17160)
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 37f839d..df08203 100755
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -116,7 +116,7 @@ if cql_zip:
ver = os.path.splitext(os.path.basename(cql_zip))[0][len(CQL_LIB_PREFIX):]
sys.path.insert(0, os.path.join(cql_zip, 'cassandra-driver-' + ver))
-third_parties = ('futures-', 'six-', 'geomet-')
+third_parties = ('futures-', 'six-')
for lib in third_parties:
lib_zip = find_zip(lib)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (fac84e0 -> 9577fd3)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from fac84e0 Merge branch 'cassandra-4.0' into trunk new bccb5ad Remove path for unused geomet package in cqlsh new 9577fd3 Merge branch 'cassandra-4.0' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 1 + bin/cqlsh.py | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17247) Remove unused dependencies from pylib/requirements.txt
[
https://issues.apache.org/jira/browse/CASSANDRA-17247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17247:
-
Fix Version/s: 4.0.2
4.1
(was: 4.x)
(was: 4.0.x)
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/8c8d9b8e5743825c47c7743c7bbfd062533e1602
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thank you!
> Remove unused dependencies from pylib/requirements.txt
> --
>
> Key: CASSANDRA-17247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17247
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.2, 4.1
>
> Attachments: 17247-removed-obsolete-cql-dependency.patch
>
>
> The dependency 'cql' appears to be obsolete in requirements.txt and is not
> imported by the python code.
> The package 'cql' was last updated in 2012 and has been deprecated by its
> authors
> [https://pypi.org/project/cql|https://pypi.org/project/cql/] (see
> release history)
> _A DB-API 2.0 compliant client library for Cassandra/CQL_
> _This driver has been {*}deprecated{*}. Please use python-driver
> [https://github.com/datastax/python-driver] instead._
> above from homepage at
> [https://code.google.com/archive/a/apache-extras.org/p/cassandra-dbapi2|https://code.google.com/archive/a/apache-extras.org/p/cassandra-dbapi2_]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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: Remove obsolete 'cql' dependency
This is an automated email from the ASF dual-hosted git repository. brandonwilliams 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 8c8d9b8 Remove obsolete 'cql' dependency 8c8d9b8 is described below commit 8c8d9b8e5743825c47c7743c7bbfd062533e1602 Author: Brad Schoening <5796692+bschoen...@users.noreply.github.com> AuthorDate: Sun Jan 9 21:42:43 2022 -0500 Remove obsolete 'cql' dependency Patch by Brad Schoening; reviewed by brandonwilliams and bereng for CASSANDRA-17247 --- CHANGES.txt| 1 + pylib/requirements.txt | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index 6492096..c176a47 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0.2 + * Removed unused 'cql' dependency (CASSANDRA-17247) * Don't block gossip when clearing repair snapshots (CASSANDRA-17168) * Deduplicate warnings for deprecated parameters (changed names) (CASSANDRA-17160) * Update ant-junit to version 1.10.12 (CASSANDRA-17218) diff --git a/pylib/requirements.txt b/pylib/requirements.txt index 45efb5e..8dd527e 100644 --- a/pylib/requirements.txt +++ b/pylib/requirements.txt @@ -7,7 +7,6 @@ six>=1.12.0 # Used ccm version is tracked by cassandra-test branch in ccm repo. Please create a PR there for fixes or upgrades to new releases. -e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm coverage -cql decorator docopt enum34 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (add1d1d -> fac84e0)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from add1d1d Merge branch 'cassandra-4.0' into trunk new 8c8d9b8 Remove obsolete 'cql' dependency new fac84e0 Merge branch 'cassandra-4.0' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + pylib/requirements.txt | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit fac84e0a8098d562a4c3d59b026dfc925a9da9b7 Merge: add1d1d 8c8d9b8 Author: Brandon Williams AuthorDate: Thu Jan 20 10:02:42 2022 -0600 Merge branch 'cassandra-4.0' into trunk CHANGES.txt| 1 + pylib/requirements.txt | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --cc CHANGES.txt index d3c4dc0,c176a47..b1d749d --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,82 -1,5 +1,83 @@@ -4.0.2 +4.1 + * Prewarm role and credential caches to avoid timeouts at startup (CASSANDRA-16958) + * Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool (CASSANDRA-17063) + * Added startup check for read_ahead_kb setting (CASSANDRA-16436) + * Avoid unecessary array allocations and initializations when performing query checks (CASSANDRA-17209) + * Add guardrail for list operations that require read before write (CASSANDRA-17154) + * Migrate thresholds for number of keyspaces and tables to guardrails (CASSANDRA-17195) + * Remove self-reference in SSTableTidier (CASSANDRA-17205) + * Add guardrail for query page size (CASSANDRA-17189) + * Allow column_index_size_in_kb to be configurable through nodetool (CASSANDRA-17121) + * Emit a metric for number of local read and write calls + * Add non-blocking mode for CDC writes (CASSANDRA-17001) + * Add guardrails framework (CASSANDRA-17147) + * Harden resource management on SSTable components to prevent future leaks (CASSANDRA-17174) + * Make nodes more resilient to local unrelated files during startup (CASSANDRA-17082) + * repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout (CASSANDRA-16992) + * Log queries that fail on timeout or unavailable errors up to once per minute by default (CASSANDRA-17159) + * Refactor normal/preview/IR repair to standardize repair cleanup and error handling of failed RepairJobs (CASSANDRA-17069) + * Log missing peers in StartupClusterConnectivityChecker (CASSANDRA-17130) + * Introduce separate rate limiting settings for entire SSTable streaming (CASSANDRA-17065) + * Implement Virtual Tables for Auth Caches (CASSANDRA-16914) + * Actively update auth cache in the background (CASSANDRA-16957) + * Add unix time conversion functions (CASSANDRA-17029) + * JVMStabilityInspector.forceHeapSpaceOomMaybe should handle all non-heap OOMs rather than only supporting direct only (CASSANDRA-17128) + * Forbid other Future implementations with checkstyle (CASSANDRA-17055) + * commit log was switched from non-daemon to daemon threads, which causes the JVM to exit in some case as no non-daemon threads are active (CASSANDRA-17085) + * Add a Denylist to block reads and writes on specific partition keys (CASSANDRA-12106) + * v4+ protocol did not clean up client warnings, which caused leaking the state (CASSANDRA-17054) + * Remove duplicate toCQLString in ReadCommand (CASSANDRA-17023) + * Ensure hint window is persistent across restarts of a node (CASSANDRA-14309) + * Allow to GRANT or REVOKE multiple permissions in a single statement (CASSANDRA-17030) + * Allow to grant permission for all tables in a keyspace (CASSANDRA-17027) + * Log time spent writing keys during compaction (CASSANDRA-17037) + * Make nodetool compactionstats and sstable_tasks consistent (CASSANDRA-16976) + * Add metrics and logging around index summary redistribution (CASSANDRA-17036) + * Add configuration options for minimum allowable replication factor and default replication factor (CASSANDRA-14557) + * Expose information about stored hints via a nodetool command and a virtual table (CASSANDRA-14795) + * Add broadcast_rpc_address to system.local (CASSANDRA-11181) + * Add support for type casting in WHERE clause components and in the values of INSERT/UPDATE statements (CASSANDRA-14337) + * add credentials file support to CQLSH (CASSANDRA-16983) + * Skip remaining bytes in the Envelope buffer when a ProtocolException is thrown to avoid double decoding (CASSANDRA-17026) + * Allow reverse iteration of resources during permissions checking (CASSANDRA-17016) + * Add feature to verify correct ownership of attached locations on disk at startup (CASSANDRA-16879) + * Make SSLContext creation pluggable/extensible (CASSANDRA-1) + * Add soft/hard limits to local reads to protect against reading too much data in a single query (CASSANDRA-16896) + * Avoid token cache invalidation for removing a non-member node (CASSANDRA-15290) + * Allow configuration of consistency levels on auth operations (CASSANDRA-12988) + * Add number of sstables in a compaction to compactionstats output (CASSANDRA-16844) + * Upgrade Caffeine to 2.9.2 (CASSANDRA-15153) + * Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it (CASSA
[jira] [Updated] (CASSANDRA-17204) Upgrade to Logback 1.2.9 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17204:
-
Fix Version/s: 3.0.26
3.11.12
4.0.2
4.1
(was: 3.0.x)
(was: 4.x)
(was: 3.11.x)
(was: 4.0.x)
Source Control Link:
https://github.com/apache/cassandra/commit/28004d9c602bff1d6e3d8551c8cd53538578a8bb
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks for the review.
> Upgrade to Logback 1.2.9 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1
>
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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. brandonwilliams pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit cf9091a12c655d5ec58c62f5ac7d3f9cf0bcd3a5 Merge: 9a1bb62 7e68448 Author: Brandon Williams AuthorDate: Thu Jan 20 09:48:54 2022 -0600 Merge branch 'cassandra-3.11' into cassandra-4.0 CHANGES.txt | 1 + build.xml | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --cc CHANGES.txt index d9303f8,c810378..6492096 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,36 -1,17 +1,37 @@@ -3.11.12 - * Upgrade snakeyaml to 1.26 in 3.11 (CASSANDRA=17028) +4.0.2 + * Don't block gossip when clearing repair snapshots (CASSANDRA-17168) + * Deduplicate warnings for deprecated parameters (changed names) (CASSANDRA-17160) + * Update ant-junit to version 1.10.12 (CASSANDRA-17218) + * Add droppable tombstone metrics to nodetool tablestats (CASSANDRA-16308) + * Fix disk failure triggered when enabling FQL on an unclean directory (CASSANDRA-17136) + * Fixed broken classpath when multiple jars in build directory (CASSANDRA-17129) + * DebuggableThreadPoolExecutor does not propagate client warnings (CASSANDRA-17072) + * internode_send_buff_size_in_bytes and internode_recv_buff_size_in_bytes have new names. Backward compatibility with the old names added (CASSANDRA-17141) + * Remove unused configuration parameters from cassandra.yaml (CASSANDRA-17132) + * Queries performed with NODE_LOCAL consistency level do not update request metrics (CASSANDRA-17052) + * Fix multiple full sources can be select unexpectedly for bootstrap streaming (CASSANDRA-16945) + * Fix cassandra.yaml formatting of parameters (CASSANDRA-17131) + * Add backward compatibility for CQLSSTableWriter Date fields (CASSANDRA-17117) + * Push initial client connection messages to trace (CASSANDRA-17038) + * Correct the internode message timestamp if sending node has wrapped (CASSANDRA-16997) + * Avoid race causing us to return null in RangesAtEndpoint (CASSANDRA-16965) + * Avoid rewriting all sstables during cleanup when transient replication is enabled (CASSANDRA-16966) + * Prevent CQLSH from failure on Python 3.10 (CASSANDRA-16987) + * Avoid trying to acquire 0 permits from the rate limiter when taking snapshot (CASSANDRA-16872) + * Upgrade Caffeine to 2.5.6 (CASSANDRA-15153) + * Include SASI components to snapshots (CASSANDRA-15134) + * Fix missed wait latencies in the output of `nodetool tpstats -F` (CASSANDRA-16938) + * Remove all the state pollution between tests in SSTableReaderTest (CASSANDRA-16888) + * Delay auth setup until after gossip has settled to avoid unavailables on startup (CASSANDRA-16783) + * Fix clustering order logic in CREATE MATERIALIZED VIEW (CASSANDRA-16898) + * org.apache.cassandra.db.rows.ArrayCell#unsharedHeapSizeExcludingData includes data twice (CASSANDRA-16900) + * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) +Merged from 3.11: * Add key validation to ssstablescrub (CASSANDRA-16969) * Update Jackson from 2.9.10 to 2.12.5 (CASSANDRA-16851) - * Include SASI components to snapshots (CASSANDRA-15134) * Make assassinate more resilient to missing tokens (CASSANDRA-16847) - * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) - * Validate SASI tokenizer options before adding index to schema (CASSANDRA-15135) - * Fixup scrub output when no data post-scrub and clear up old use of row, which really means partition (CASSANDRA-16835) - * Fix ant-junit dependency issue (CASSANDRA-16827) - * Reduce thread contention in CommitLogSegment and HintsBuffer (CASSANDRA-16072) - * Avoid sending CDC column if not enabled (CASSANDRA-16770) Merged from 3.0: + * Upgrade logback to 1.2.9 (CASSANDRA-17204) * Avoid race in AbstractReplicationStrategy endpoint caching (CASSANDRA-16673) * Fix abort when window resizing during cqlsh COPY (CASSANDRA-15230) * Fix slow keycache load which blocks startup for tables with many sstables (CASSANDRA-14898) diff --cc build.xml index 89c0cac,a094e8b..d3e0abd --- a/build.xml +++ b/build.xml @@@ -514,11 -348,11 +514,11 @@@ - - - + + + - - + + - 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.
brandonwilliams pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 7e684482353b763d7f41b9cb15d311bf150174f8
Merge: b5d0626 28004d9
Author: Brandon Williams
AuthorDate: Thu Jan 20 09:47:23 2022 -0600
Merge branch 'cassandra-3.0' into cassandra-3.11
CHANGES.txt | 1 +
build.xml| 4 ++--
.../apache/cassandra/config/DatabaseDescriptorRefTest.java | 2 +-
.../cql3/validation/operations/AggregationTest.java | 12
4 files changed, 16 insertions(+), 3 deletions(-)
diff --cc CHANGES.txt
index 5e8213f,65fe841..c810378
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,16 -1,5 +1,17 @@@
-3.0.26:
+3.11.12
+ * Upgrade snakeyaml to 1.26 in 3.11 (CASSANDRA=17028)
+ * Add key validation to ssstablescrub (CASSANDRA-16969)
+ * Update Jackson from 2.9.10 to 2.12.5 (CASSANDRA-16851)
+ * Include SASI components to snapshots (CASSANDRA-15134)
+ * Make assassinate more resilient to missing tokens (CASSANDRA-16847)
+ * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies
(CASSANDRA-16854)
+ * Validate SASI tokenizer options before adding index to schema
(CASSANDRA-15135)
+ * Fixup scrub output when no data post-scrub and clear up old use of row,
which really means partition (CASSANDRA-16835)
+ * Fix ant-junit dependency issue (CASSANDRA-16827)
+ * Reduce thread contention in CommitLogSegment and HintsBuffer
(CASSANDRA-16072)
+ * Avoid sending CDC column if not enabled (CASSANDRA-16770)
+Merged from 3.0:
+ * Upgrade logback to 1.2.9 (CASSANDRA-17204)
* Avoid race in AbstractReplicationStrategy endpoint caching
(CASSANDRA-16673)
* Fix abort when window resizing during cqlsh COPY (CASSANDRA-15230)
* Fix slow keycache load which blocks startup for tables with many sstables
(CASSANDRA-14898)
diff --cc build.xml
index 9b4b086,6dd09fe..a094e8b
--- a/build.xml
+++ b/build.xml
@@@ -351,11 -326,10 +351,11 @@@
-
-
+
+
-
-
+
+
+
diff --cc test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java
index 791212d,000..83c6bea
mode 100644,00..100644
--- a/test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java
+++ b/test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java
@@@ -1,285 -1,0 +1,285 @@@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.config;
+
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.PrintStream;
+import java.lang.management.ManagementFactory;
+import java.lang.management.ThreadInfo;
+import java.lang.management.ThreadMXBean;
+import java.lang.reflect.Method;
+import java.net.URL;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.junit.Test;
+
+import org.apache.cassandra.utils.Pair;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.fail;
+
+/**
+ * Verifies that {@link DatabaseDescriptor#clientInitialization()} } and a
couple of apply methods
+ * do not somehow lazily initialize any unwanted part of Cassandra like
schema, commit log or start
+ * unexpected threads.
+ *
+ * {@link DatabaseDescriptor#toolInitialization()} is tested via unit tests
extending
+ * {@link org.apache.cassandra.tools.ToolsTester}.
+ */
+public class DatabaseDescriptorRefTest
+{
+static final String[] validClasses = {
+"org.apache.cassandra.auth.IInternodeAuthenticator",
+"org.apache.cassandra.auth.IAuthenticator",
+"org.apache.cassandra.auth.IAuthorizer",
+"org.apache.cassandra.auth.IRoleManager",
+"org.apache.cassandra.config.DatabaseDescriptor",
+
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit add1d1d75237d2ef51e7c53b88a66c80bde52550 Merge: 0dc5a28 cf9091a Author: Brandon Williams AuthorDate: Thu Jan 20 09:50:08 2022 -0600 Merge branch 'cassandra-4.0' into trunk CHANGES.txt | 1 + build.xml | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (0dc5a28 -> add1d1d)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 0dc5a28 Preserve tests that use BigInt numbers new 28004d9 Upgrade logback to 1.2.9 new 7e68448 Merge branch 'cassandra-3.0' into cassandra-3.11 new cf9091a Merge branch 'cassandra-3.11' into cassandra-4.0 new add1d1d 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 + build.xml | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) - 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 (9a1bb62 -> cf9091a)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 9a1bb62 Merge branch 'cassandra-3.11' into cassandra-4.0 new 28004d9 Upgrade logback to 1.2.9 new 7e68448 Merge branch 'cassandra-3.0' into cassandra-3.11 new cf9091a 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 + build.xml | 4 ++-- 2 files changed, 3 insertions(+), 2 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 (b5d0626 -> 7e68448)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from b5d0626 Merge branch 'cassandra-3.0' into cassandra-3.11 new 28004d9 Upgrade logback to 1.2.9 new 7e68448 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 + build.xml| 4 ++-- .../apache/cassandra/config/DatabaseDescriptorRefTest.java | 2 +- .../cql3/validation/operations/AggregationTest.java | 12 4 files changed, 16 insertions(+), 3 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: Upgrade logback to 1.2.9
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams 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 28004d9 Upgrade logback to 1.2.9
28004d9 is described below
commit 28004d9c602bff1d6e3d8551c8cd53538578a8bb
Author: Brandon Williams
AuthorDate: Tue Dec 14 13:24:20 2021 -0600
Upgrade logback to 1.2.9
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-17204
includes backported test changes from CASSANDRA-14183
---
CHANGES.txt | 1 +
build.xml| 4 ++--
.../cql3/validation/operations/AggregationTest.java | 12
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index e23f5e7..65fe841 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.26:
+ * Upgrade logback to 1.2.9 (CASSANDRA-17204)
* Avoid race in AbstractReplicationStrategy endpoint caching (CASSANDRA-16673)
* Fix abort when window resizing during cqlsh COPY (CASSANDRA-15230)
* Fix slow keycache load which blocks startup for tables with many sstables
(CASSANDRA-14898)
diff --git a/build.xml b/build.xml
index 41f530d..6dd09fe 100644
--- a/build.xml
+++ b/build.xml
@@ -326,8 +326,8 @@
-
-
+
+
diff --git
a/test/unit/org/apache/cassandra/cql3/validation/operations/AggregationTest.java
b/test/unit/org/apache/cassandra/cql3/validation/operations/AggregationTest.java
index a073aca..6de7052 100644
---
a/test/unit/org/apache/cassandra/cql3/validation/operations/AggregationTest.java
+++
b/test/unit/org/apache/cassandra/cql3/validation/operations/AggregationTest.java
@@ -38,6 +38,7 @@ import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import ch.qos.logback.classic.LoggerContext;
+import ch.qos.logback.classic.joran.ReconfigureOnChangeTask;
import ch.qos.logback.classic.spi.TurboFilterList;
import ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter;
import ch.qos.logback.classic.turbo.TurboFilter;
@@ -59,6 +60,7 @@ import
org.apache.cassandra.transport.Event.SchemaChange.Change;
import org.apache.cassandra.transport.Event.SchemaChange.Target;
import org.apache.cassandra.transport.messages.ResultMessage;
+import static ch.qos.logback.core.CoreConstants.RECONFIGURE_ON_CHANGE_TASK;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
import static org.junit.Assert.assertNull;
@@ -1871,6 +1873,16 @@ public class AggregationTest extends CQLTester
break;
}
}
+
+ReconfigureOnChangeTask roct = (ReconfigureOnChangeTask)
ctx.getObject(RECONFIGURE_ON_CHANGE_TASK);
+if (roct != null)
+{
+// New functionality in logback - they replaced
ReconfigureOnChangeFilter (which runs in the logging code)
+// with an async ReconfigureOnChangeTask - i.e. in a thread that
does not become sandboxed.
+// Let the test run anyway, just we cannot reconfigure it (and it
is pointless to reconfigure).
+return;
+}
+
assertTrue("ReconfigureOnChangeFilter not in logback's turbo-filter
list - do that by adding scan=\"true\" to logback-test.xml's configuration
element", done);
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479406#comment-17479406
]
Benedict Elliott Smith commented on CASSANDRA-17164:
I have pushed a documentation commit, adding javadoc to the {{Paxos}} class. It
might turn out to be inadequate, but it is hopefully a starting point to help
further discussion.
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17272) LeveledCompactionStrategy disk space check improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17272: Test and Documentation Plan: cci runs + new unit tests Status: Patch Available (was: Open) > LeveledCompactionStrategy disk space check improvements > --- > > Key: CASSANDRA-17272 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17272 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > > We currently allow reducing scope (removing sstables from the compaction) > when starting STCS-in-L0 with LCS if the compaction is too large for the > available disk space. We can do the same for L0 -> L1 compactions - but we > can only remove L0 sstables to avoid causing overlap in L1. > Also, in 3.0, when starting an LCS compaction we try to [get a writeable > location|https://github.com/apache/cassandra/blob/b1a8a56c563b85ab9a34d3bbf9c16278dd441157/src/java/org/apache/cassandra/db/compaction/writers/CompactionAwareWriter.java#L128] > where the full result of the compaction will fit - here we should only get a > directory where the first sstable fits, otherwise the compaction might fail > even though there is enough space in total among the data directories -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17272) LeveledCompactionStrategy disk space check improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17272: Fix Version/s: 3.0.x 3.11.x 4.0.x 4.x (was: 4.1) (was: 3.0.26) (was: 3.11.12) (was: 4.0.2) > LeveledCompactionStrategy disk space check improvements > --- > > Key: CASSANDRA-17272 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17272 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > > We currently allow reducing scope (removing sstables from the compaction) > when starting STCS-in-L0 with LCS if the compaction is too large for the > available disk space. We can do the same for L0 -> L1 compactions - but we > can only remove L0 sstables to avoid causing overlap in L1. > Also, in 3.0, when starting an LCS compaction we try to [get a writeable > location|https://github.com/apache/cassandra/blob/b1a8a56c563b85ab9a34d3bbf9c16278dd441157/src/java/org/apache/cassandra/db/compaction/writers/CompactionAwareWriter.java#L128] > where the full result of the compaction will fit - here we should only get a > directory where the first sstable fits, otherwise the compaction might fail > even though there is enough space in total among the data directories -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17272) LeveledCompactionStrategy disk space check improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17272: Bug Category: Parent values: Degradation(12984)Level 1 values: Resource Management(12995) Complexity: Low Hanging Fruit Component/s: Local/Compaction/LCS Discovered By: Adhoc Test Fix Version/s: 3.0.26 3.11.12 4.0.2 4.1 Severity: Normal Status: Open (was: Triage Needed) https://github.com/apache/cassandra/pull/1411 https://github.com/apache/cassandra/pull/1412 https://github.com/apache/cassandra/pull/1413 https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2Flcs_disk_space https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2Flcs_disk_space-3.11 https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2Flcs_disk_space-4.0 > LeveledCompactionStrategy disk space check improvements > --- > > Key: CASSANDRA-17272 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17272 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1 > > > We currently allow reducing scope (removing sstables from the compaction) > when starting STCS-in-L0 with LCS if the compaction is too large for the > available disk space. We can do the same for L0 -> L1 compactions - but we > can only remove L0 sstables to avoid causing overlap in L1. > Also, in 3.0, when starting an LCS compaction we try to [get a writeable > location|https://github.com/apache/cassandra/blob/b1a8a56c563b85ab9a34d3bbf9c16278dd441157/src/java/org/apache/cassandra/db/compaction/writers/CompactionAwareWriter.java#L128] > where the full result of the compaction will fit - here we should only get a > directory where the first sstable fits, otherwise the compaction might fail > even though there is enough space in total among the data directories -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479389#comment-17479389
]
Josh McKenzie commented on CASSANDRA-17182:
---
I'd parked the "-f option for verify" ticket because I lost interest in testing
a custom ccm branch in circle; was janky and annoying enough, and that patch
orthogonal enough to most things changing in the codebase, I figured I'd sit on
it for a bit. Then this ticket came along - happy little accidents!
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479387#comment-17479387
]
Josh McKenzie commented on CASSANDRA-16956:
---
{quote}I find the argument for not destabilising 4.0 silly
{quote}
What you find silly or not is irrelevant to the agreed upon rules of the
project. The question here is whether we interpret "removing dead code" as an
improvement or a bug, and how we apply our agreed upon merge rules prioritizing
stability in light of that.
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc, signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17272) LeveledCompactionStrategy disk space check improvements
Marcus Eriksson created CASSANDRA-17272: --- Summary: LeveledCompactionStrategy disk space check improvements Key: CASSANDRA-17272 URL: https://issues.apache.org/jira/browse/CASSANDRA-17272 Project: Cassandra Issue Type: Bug Reporter: Marcus Eriksson Assignee: Marcus Eriksson We currently allow reducing scope (removing sstables from the compaction) when starting STCS-in-L0 with LCS if the compaction is too large for the available disk space. We can do the same for L0 -> L1 compactions - but we can only remove L0 sstables to avoid causing overlap in L1. Also, in 3.0, when starting an LCS compaction we try to [get a writeable location|https://github.com/apache/cassandra/blob/b1a8a56c563b85ab9a34d3bbf9c16278dd441157/src/java/org/apache/cassandra/db/compaction/writers/CompactionAwareWriter.java#L128] where the full result of the compaction will fit - here we should only get a directory where the first sstable fits, otherwise the compaction might fail even though there is enough space in total among the data directories -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17153) Guardrails for collection/UDT items and size
[
https://issues.apache.org/jira/browse/CASSANDRA-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17153:
--
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Guardrails for collection/UDT items and size
>
>
> Key: CASSANDRA-17153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17153
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrails for the number of items in a collection/UDT and possibly also
> the size of a collection. For example:
> {code}
> # Failure threshold to prevent creating more fields in user-defined-type than
> threshold.
> # Defaults -1 to disable.
> # fields_per_udt_failure_threshold: -1
> # Warning threshold to warn when encountering larger size of collection data
> than threshold.
> # Defaults -1 to disable.
> # collection_size_warn_threshold_in_kb: -1
> # Warning threshold to warn when encountering more elements in collection
> than threshold.
> # Defaults -1 to disable.
> # items_per_collection_warn_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17153) Guardrails for collection/UDT items and size
[
https://issues.apache.org/jira/browse/CASSANDRA-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-17153:
-
Assignee: Andres de la Peña
> Guardrails for collection/UDT items and size
>
>
> Key: CASSANDRA-17153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17153
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrails for the number of items in a collection/UDT and possibly also
> the size of a collection. For example:
> {code}
> # Failure threshold to prevent creating more fields in user-defined-type than
> threshold.
> # Defaults -1 to disable.
> # fields_per_udt_failure_threshold: -1
> # Warning threshold to warn when encountering larger size of collection data
> than threshold.
> # Defaults -1 to disable.
> # collection_size_warn_threshold_in_kb: -1
> # Warning threshold to warn when encountering more elements in collection
> than threshold.
> # Defaults -1 to disable.
> # items_per_collection_warn_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17242: - Fix Version/s: (was: 4.0.x) > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479317#comment-17479317 ] Brandon Williams commented on CASSANDRA-17242: -- [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17242] and [circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17242&filter=all]. > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.0.x, 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17242: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > Remove Python 2.x support from CQLSH > > > Key: CASSANDRA-17242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.0.x, 4.x > > > Python 2 has now reached EOL and should be removed from CQLSH and other > Cassandra components. > "We are volunteers who make and take care of the Python programming language. > We have decided that January 1, 2020, was the day that we sunset Python 2. > That means that we will not improve it anymore after that day, even if > someone finds a security problem in it. You should upgrade to Python 3 as > soon as you can. > And if many people keep using Python 2, then that makes it hard for [the > volunteers who use Python to make > software|https://python3statement.org/#sections50-why]. They can't use the > good new things in Python 3 to improve the tools they make. > As of January 1st, 2020 no new bug reports, fixes, or changes will be made to > Python 2, and Python 2 is no longer supported. > " > [https://www.python.org/doc/sunset-python-2/] > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17265) dtest byteman errors
[
https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479304#comment-17479304
]
Berenguer Blasi edited comment on CASSANDRA-17265 at 1/20/22, 11:55 AM:
Weird. Running the test locally, locally with the preceding test it runs on
circle, on circle just that method, just the class or the full file works. But
a full dtest run renders:
{noformat}
11:17:45,567 read_repair_test DEBUG Current path byteman func
is:/tmp/tmp61o2mx51
11:17:45,567 read_repair_test DEBUG ['bin', 'data', 'logs']
11:17:45,567 read_repair_test DEBUG Script path is:
./byteman/read_repair/stop_writes.btm
{noformat}
Which I can only think there is some obscure test cross-talk or circle env
weird juggling of files.
was (Author: bereng):
Weird. Running the test locally, locally with the preceding test it runs on
circle, on circle just that method, just the class or the full file works. But
a full dtest run renders:
{noformat}
10:29:05,846 read_repair_test DEBUG Current path is:/tmp/tmpmk4i7wt7
10:29:05,846 read_repair_test DEBUG Script path is:
./byteman/read_repair/stop_writes.btm
{noformat}
Which I can only think there is some obscure test cross-talk or circle env
weird juggling of files.
> dtest byteman errors
>
>
> Key: CASSANDRA-17265
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17265
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on
> missing btm files. I checked and the files _are there_. Also it doesn't repro
> locally. See 4.0 vanilla runs
> [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17265) dtest byteman errors
[
https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479304#comment-17479304
]
Berenguer Blasi commented on CASSANDRA-17265:
-
Weird. Running the test locally, locally with the preceding test it runs on
circle, on circle just that method, just the class or the full file works. But
a full dtest run renders:
{noformat}
10:29:05,846 read_repair_test DEBUG Current path is:/tmp/tmpmk4i7wt7
10:29:05,846 read_repair_test DEBUG Script path is:
./byteman/read_repair/stop_writes.btm
{noformat}
Which I can only think there is some obscure test cross-talk or circle env
weird juggling of files.
> dtest byteman errors
>
>
> Key: CASSANDRA-17265
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17265
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on
> missing btm files. I checked and the files _are there_. Also it doesn't repro
> locally. See 4.0 vanilla runs
> [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17248) Fix Prepared Statements behaviours after 15252
[ https://issues.apache.org/jira/browse/CASSANDRA-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17248: Status: Ready to Commit (was: Review In Progress) +1, minor comment-nit on the PRs > Fix Prepared Statements behaviours after 15252 > -- > > Key: CASSANDRA-17248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17248 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when > preparing fully qualified prepared statements which was causing > cluster-killing re-prepare loops. However, the fix introduced a regression: > non-qualified statements can get prepared against one keyspace but then > executed on another under some circumstances. This patch reconciles all > behaviours. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17266) DESCRIBE KEYSPACE / MATERIALIZED VIEW generates invalid CQL for views
[
https://issues.apache.org/jira/browse/CASSANDRA-17266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17266:
---
Description:
Materialized views do not allow default_time_to_live option in CQL (see
CASSANDRA-12868).
But, if the MV was created without this option, DESCRIBE KEYSPACE /
MATERIALIZED VIEW command generates CQL that includes it.
E.g.
{code:java}
CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': '1'};
USE test;
CREATE TABLE test_table(
id text,
date text,
col1 text,
col2 text,
PRIMARY KEY(id,date)
) WITH default_time_to_live = 60 AND CLUSTERING ORDER BY (date DESC);
CREATE MATERIALIZED VIEW test_view AS
SELECT id, date, col1
FROM test_table
WHERE id IS NOT NULL AND date IS NOT NULL
PRIMARY KEY(id, date);{code}
It is OK.
{code:java}
DESCRIBE MATERIALIZED VIEW test_view; {code}
returns the same CQL + all default options:
{code:java}
CREATE MATERIALIZED VIEW test.test_view AS
SELECT id, date, col1
FROM test.test_table
WHERE id IS NOT NULL AND date IS NOT NULL
PRIMARY KEY (id, date)
WITH CLUSTERING ORDER BY (date ASC)
AND additional_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '16', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
{code}
Note the 'default_time_to_live = 0' clause! If this veiw is dropped,
re-creating it using DESCRIBE output would fail with
{noformat}
Cannot set default_time_to_live for a materialized view. Data in a materialized
view always expire at the same time than the corresponding data in the parent
table.{noformat}
+Additional Information for newcomers:+
The code writting the table parameters is in {{TableParams.appendCqlTo}} and is
called through {{TableMetadata.appendTableOptions}}. Those method will need to
have a new parameter specifying if the call is for a table or a materialized
view.
Some unit test need to be adapted in {{DescribeStatementTest}}
was:
Materialized views do not allow default_time_to_live option in CQL (see
CASSANDRA-12868).
But, if the MV was created without this option, DESCRIBE KEYSPACE /
MATERIALIZED VIEW command generates CQL that includes it.
E.g.
{code:java}
CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': '1'};
USE test;
CREATE TABLE test_table(
id text,
date text,
col1 text,
col2 text,
PRIMARY KEY(id,date)
) WITH default_time_to_live = 60 AND CLUSTERING ORDER BY (date DESC);
CREATE MATERIALIZED VIEW test_view AS
SELECT id, date, col1
FROM test_table
WHERE id IS NOT NULL AND date IS NOT NULL
PRIMARY KEY(id, date);{code}
It is OK.
{code:java}
DESCRIBE MATERIALIZED VIEW test_view; {code}
returns the same CQL + all default options:
{code:java}
CREATE MATERIALIZED VIEW test.test_view AS
SELECT id, date, col1
FROM test.test_table
WHERE id IS NOT NULL AND date IS NOT NULL
PRIMARY KEY (id, date)
WITH CLUSTERING ORDER BY (date ASC)
AND additional_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '16', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
{code}
Note the 'default_time_to_live = 0' clause! If this veiw is dropped,
re-creating it using DESCRIBE output would fail with
{noformat}
Cannot set default_time_to_live for a materialized view. Data in a materialized
view always expire at the same time than the corresponding data in the parent
table.{noformat}
> DESCRIBE KEYSPACE / MATERIALIZED VIEW generates invalid CQL for views
> -
>
> Key: CASSANDRA-17266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17266
> Project: Cassandra
> Issue Type
[jira] [Comment Edited] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479183#comment-17479183
]
Benedict Elliott Smith edited comment on CASSANDRA-17164 at 1/20/22, 9:58 AM:
--
{quote}Specifically, what stops the following from happening?{quote}
In this example, I believe (3) would not yield {{FOUND_INCOMPLETE_COMMIT}} but
{{FOUND_INCOMPLETE_ACCEPTED}} and so would correctly re-propose (2), expending
its ballot?
{quote}The fact that we tie accepting a promise to a majority with matching
"most recent commit" means that we effectively treat it as the identifier of
the current session{quote}
It is used as an identifier for a commit that was accepted by a majority using
that ballot, only to ensure it is durable (made it to at least a quorum) before
we propose a new value. We don't tie accepting a promise to matching the "most
recent commit" but we cannot safely propose anything without ensuring the prior
commit is durable, which is why we may simply "refresh" and continue using the
promises we sought... I feel like there may be some minor disconnects here in
our language, though, which might be complicating the discussion a little.
{quote}It seems the next prepare will return FOUND_INCOMPLETE_ACCEPTED and
trigger reproposal and commit{quote}
{{hasInProgressProposal}} first checks if {{latestAccepted.update.isEmpty()}}
and if so, returns false, i.e. this would not be considered an incomplete
proposal.
was (Author: benedict):
{quote}Specifically, what stops the following from happening?{quote}
In this example, I believe (3) would not yield {{FOUND_INCOMPLETE_COMMIT}} but
{{FOUND_INCOMPLETE_ACCEPTED}} and so would correctly re-propose (2), expending
its ballot?
{quote}It seems the next prepare will return FOUND_INCOMPLETE_ACCEPTED and
trigger reproposal and commit{quote}
{{hasInProgressProposal}} first checks if {{latestAccepted.update.isEmpty()}}
and if so, returns false, i.e. this would not be considered an incomplete
proposal.
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17266) DESCRIBE KEYSPACE / MATERIALIZED VIEW generates invalid CQL for views
[
https://issues.apache.org/jira/browse/CASSANDRA-17266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17266:
---
Complexity: Low Hanging Fruit (was: Normal)
Labels: lhf (was: )
> DESCRIBE KEYSPACE / MATERIALIZED VIEW generates invalid CQL for views
> -
>
> Key: CASSANDRA-17266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17266
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oleg Zhovtanyuk
>Priority: Normal
> Labels: lhf
> Fix For: 4.0.x
>
>
> Materialized views do not allow default_time_to_live option in CQL (see
> CASSANDRA-12868).
> But, if the MV was created without this option, DESCRIBE KEYSPACE /
> MATERIALIZED VIEW command generates CQL that includes it.
> E.g.
> {code:java}
> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> USE test;
> CREATE TABLE test_table(
> id text,
> date text,
> col1 text,
> col2 text,
> PRIMARY KEY(id,date)
> ) WITH default_time_to_live = 60 AND CLUSTERING ORDER BY (date DESC);
> CREATE MATERIALIZED VIEW test_view AS
> SELECT id, date, col1
> FROM test_table
> WHERE id IS NOT NULL AND date IS NOT NULL
> PRIMARY KEY(id, date);{code}
> It is OK.
> {code:java}
> DESCRIBE MATERIALIZED VIEW test_view; {code}
> returns the same CQL + all default options:
> {code:java}
> CREATE MATERIALIZED VIEW test.test_view AS
> SELECT id, date, col1
> FROM test.test_table
> WHERE id IS NOT NULL AND date IS NOT NULL
> PRIMARY KEY (id, date)
> WITH CLUSTERING ORDER BY (date ASC)
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> {code}
> Note the 'default_time_to_live = 0' clause! If this veiw is dropped,
> re-creating it using DESCRIBE output would fail with
> {noformat}
> Cannot set default_time_to_live for a materialized view. Data in a
> materialized view always expire at the same time than the corresponding data
> in the parent table.{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479183#comment-17479183
]
Benedict Elliott Smith edited comment on CASSANDRA-17164 at 1/20/22, 9:46 AM:
--
{quote}Specifically, what stops the following from happening?{quote}
In this example, I believe (3) would not yield {{FOUND_INCOMPLETE_COMMIT}} but
{{FOUND_INCOMPLETE_ACCEPTED}} and so would correctly re-propose (2), expending
its ballot?
{quote}It seems the next prepare will return FOUND_INCOMPLETE_ACCEPTED and
trigger reproposal and commit{quote}
{{hasInProgressProposal}} first checks if {{latestAccepted.update.isEmpty()}}
and if so, returns false, i.e. this would not be considered an incomplete
proposal.
was (Author: benedict):
{quote}Specifically, what stops the following from happening?{quote}
In this example, I believe (3) would not yield {{FOUND_INCOMPLETE_COMMIT}} but
{{FOUND_INCOMPLETE_ACCEPTED}} and so would correctly re-propose (2), expending
its ballot?
{quote}It seems the next prepare will return FOUND_INCOMPLETE_ACCEPTED and
trigger reproposal and commit{quote}
{{hasInProgressProposal}} first checks if {{latestAccepted.update.isEmpty()}}
and if so, returns false, i.e. this would not be considered an incomplete
proposal.
The fast read optimisation does however leave an incomplete _promise_ that we
might want to change to asynchronously send an empty proposal.
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479167#comment-17479167
]
Branimir Lambov edited comment on CASSANDRA-17164 at 1/20/22, 8:45 AM:
---
{quote}I think this is actually the typical way of implementing Classic Paxos,
even though Lamport's paper seems to suggest you must only contact the nodes
that responded to the prepare (there may be something else specific about his
formulation that necessitates this, I forget, as I dislike his writings on the
topic). This is corroborated by Heidi Howard's dissertation, which was the
easiest place I could find a straight-forward formulation of Classic Paxos
besides that of Lamport. See Algorithm 3 on Page 30.
{quote}
This is an excellent pointer, thank you. Lamport's proof also works with
separate proposal quorum – my only request here is that this should be stated
somewhere as other contributors might start with Lamport's original definition
too.
{quote}I don't quite follow what you mean by this, as this is not limited to
"most recent commit", but a ballot directly maps to the instance id of classic
paxos, it just avoids pre-splitting the range of integers.
{quote}
Well, I don't follow this one. A ballot id is something one replica selects and
sends it as a prepare message to everyone. At this point some nodes may have
committed a proposal, others may have accepted it, and yet others may have
never heard of it. From the point of view of a sequence of paxos instances, the
first two will definitely make promises for different instances, and likely the
third one will be promising for yet another one. The fact that we tie accepting
a promise to a majority with matching "most recent commit" means that we
effectively treat it as the identifier of the current session.
More interestingly, we can then send a proposal to nodes with older most recent
commit (i.e. nodes that are effectively working on a previous paxos instance),
that proposal will be accepted (overwriting the decided value but not advancing
the most recent commit), and this might lead to a decision using just a small
number of participants with the right "most recent commit". Specifically, what
stops the following from happening?
{code:java}
A mrcA acceptedA promised B mrc B
accepted B promised C mrcC accepted C promised
prepare(1) -> ABC- -1-
- 1 - -1
propose(1, X) -> ABC - 1,X1-
1,X 1 - 1,X 1
commit(1, X) -> AB 1,X -1 1,X
- 1 - -1
prepare(2) -> AB1,X -2 1,X
- 2 - 1,X 1
majority AB, no refresh
propose(2, Y) -> BC 1,X -2 1,X
2,Y 2 - 2,Y 2
returns successful Y
prepare(3) -> AC1,X1,X3 1,X
2,Y 2 1,X -3
refresh stale, then forms majority AC
propose(3, Z) -> ABC1,X3,Z3 1,X
3,Z 3 1,X3,Z 3
returns successful Z
{code}
If this is permitted, there's a further error possibility if B is partitioned
after the 2,Y proposal succeeds and a commit is executed in B. Then the
committed value can be read from B, and later wiped with a conflicting decision.
In LWT terms, if
X: {{{}column = X if not exists{}}},
Y: {{column = Y if column == X}} and
Z: {{{}column = Z if column == X{}}},
we may be able to read (serially) both Y and Z.
{quote}Could you explain what you are referring to here? I think this is all
standard stuff for Paxos, we're again just recording the most recently used
instance number for each register.
{quote}
Judging from the above, this may be insufficient. I'm likely missing something
here – that something needs to be documented.
{quote}The final commit phase is only required to ensure any "decree"
(decision) is disseminated. If we have proposed that no decree be made, there
is nothing to disseminate, and nothing to complete if another transaction
encounters it. This is in some ways an artefact of the feature of Cassandra's
implementation, that we initiate a paxos round without knowing if it will do
anything, though this feature would I suppose be present for read-only
operations anyway.
{quote}
This is also hard to read from the code: {{Paxos.ca
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479183#comment-17479183
]
Benedict Elliott Smith commented on CASSANDRA-17164:
{quote}Specifically, what stops the following from happening?{quote}
In this example, I believe (3) would not yield {{FOUND_INCOMPLETE_COMMIT}} but
{{FOUND_INCOMPLETE_ACCEPTED}} and so would correctly re-propose (2), expending
its ballot?
{quote}It seems the next prepare will return FOUND_INCOMPLETE_ACCEPTED and
trigger reproposal and commit{quote}
{{hasInProgressProposal}} first checks if {{latestAccepted.update.isEmpty()}}
and if so, returns false, i.e. this would not be considered an incomplete
proposal.
The fast read optimisation does however leave an incomplete _promise_ that we
might want to change to asynchronously send an empty proposal.
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479167#comment-17479167
]
Branimir Lambov commented on CASSANDRA-17164:
-
bq. I think this is actually the typical way of implementing Classic Paxos,
even though Lamport's paper seems to suggest you must only contact the nodes
that responded to the prepare (there may be something else specific about his
formulation that necessitates this, I forget, as I dislike his writings on the
topic). This is corroborated by Heidi Howard's dissertation, which was the
easiest place I could find a straight-forward formulation of Classic Paxos
besides that of Lamport. See Algorithm 3 on Page 30.
This is an excellent pointer, thank you. Lamport's proof also works with
separate proposal quorum -- my only request here is that this should be stated
somewhere as other contributors might start with Lamport's original definition
too.
bq. I don't quite follow what you mean by this, as this is not limited to "most
recent commit", but a ballot directly maps to the instance id of classic paxos,
it just avoids pre-splitting the range of integers.
Well, I don't follow this one. A ballot id is something one replica selects and
sends it as a prepare message to everyone. At this point some nodes may have
committed a proposal, others may have accepted it, and yet others may have
never heard of it. From the point of view of a sequence of paxos instances, the
first two will definitely make promises for different instances, and likely the
third one will be promising for yet another one. The fact that we tie accepting
a promise to a majority with matching "most recent commit" means that we
effectively treat it as the identifier of the current session.
More interestingly, we can then send a proposal to nodes with older most recent
commit (i.e. nodes that are effectively working on a previous paxos instance),
that proposal will be accepted (overwriting the decided value but not advancing
the most recent commit), and this might lead to a decision using just a small
number of participants with the right "most recent commit". Specifically, what
stops the following from happening?
{code}
A mrcA acceptedA promised B mrc B
accepted B promised C mrcC accepted C promised
prepare(1) -> ABC- -1-
- 1 - -1
propose(1, X) -> ABC - 1,X1-
1,X 1 - 1,X 1
commit(1, X) -> AB 1,X -1 1,X
- 1 - -1
prepare(2) -> AB1,X -2 1,X
- 2 - 1,X 1
majority AB, no refresh
propose(2, Y) -> BC 1,X -2 1,X
2,Y 2 - 2,Y 2
returns successful Y
prepare(3) -> AC1,X1,X3 1,X
2,Y 2 1,X -3
refresh stale, then forms majority AC
propose(3, Z) -> ABC1,X3,Z3 1,X
3,Z 3 1,X3,Z 3
returns successful Z
{code}
If this is permitted, there's a further error possibility if B is partitioned
after the 2,Y proposal succeeds and a commit is executed in B. Then the
committed value can be read from B, and later wiped with a conflicting
decision.
In LWT terms, if
X: {{column = X if not exists}},
Y: {{column = Y if column == X}} and
Z: {{column = Z if column == X}},
we may be able to read both Y and Z.
bq. Could you explain what you are referring to here? I think this is all
standard stuff for Paxos, we're again just recording the most recently used
instance number for each register.
Judging from the above, this may be insufficient. I'm likely missing something
here -- that something needs to be documented.
bq. The final commit phase is only required to ensure any "decree" (decision)
is disseminated. If we have proposed that no decree be made, there is nothing
to disseminate, and nothing to complete if another transaction encounters it.
This is in some ways an artefact of the feature of Cassandra's implementation,
that we initiate a paxos round without knowing if it will do anything, though
this feature would I suppose be present for read-only operations anyway.
This is also hard to read from the code: {{Paxos.cas}} does not issue a commit
for an empty proposal, but it seems the next {{prepare}} will return
{{FOUND_
[jira] [Updated] (CASSANDRA-17243) Fix BYTES_PER_MEGABIT in StreamManager
[
https://issues.apache.org/jira/browse/CASSANDRA-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17243:
Status: Ready to Commit (was: Review In Progress)
> Fix BYTES_PER_MEGABIT in StreamManager
> --
>
> Key: CASSANDRA-17243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17243
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> While working on CASSANDRA-15234 I noticed BYTES_PER_MEGABIT constant in the
> {code:java}
> StreamManager
> {code}
> class. It was introduced in CASSANDRA-16959.
> The current formula converts actually bytes to mebibits.
> The change needed for 3.0, 3.11 and 4.0(I am currently changing rate
> parameters to be in MiB/s for trunk as part of CASSANDRA-15234):
> {code:java}
> public static final double BYTES_PER_MEGABIT = (1000 * 1000) / 8; // from bits
> {code}
> CC [~adelapena]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17243) Fix BYTES_PER_MEGABIT in StreamManager
[
https://issues.apache.org/jira/browse/CASSANDRA-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17243:
Reviewers: Berenguer Blasi, Berenguer Blasi (was: Berenguer Blasi)
Berenguer Blasi, Berenguer Blasi (was: Berenguer Blasi)
Status: Review In Progress (was: Patch Available)
> Fix BYTES_PER_MEGABIT in StreamManager
> --
>
> Key: CASSANDRA-17243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17243
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> While working on CASSANDRA-15234 I noticed BYTES_PER_MEGABIT constant in the
> {code:java}
> StreamManager
> {code}
> class. It was introduced in CASSANDRA-16959.
> The current formula converts actually bytes to mebibits.
> The change needed for 3.0, 3.11 and 4.0(I am currently changing rate
> parameters to be in MiB/s for trunk as part of CASSANDRA-15234):
> {code:java}
> public static final double BYTES_PER_MEGABIT = (1000 * 1000) / 8; // from bits
> {code}
> CC [~adelapena]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17247) Remove unused dependencies from pylib/requirements.txt
[
https://issues.apache.org/jira/browse/CASSANDRA-17247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17247:
Status: Ready to Commit (was: Review In Progress)
> Remove unused dependencies from pylib/requirements.txt
> --
>
> Key: CASSANDRA-17247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17247
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17247-removed-obsolete-cql-dependency.patch
>
>
> The dependency 'cql' appears to be obsolete in requirements.txt and is not
> imported by the python code.
> The package 'cql' was last updated in 2012 and has been deprecated by its
> authors
> [https://pypi.org/project/cql|https://pypi.org/project/cql/] (see
> release history)
> _A DB-API 2.0 compliant client library for Cassandra/CQL_
> _This driver has been {*}deprecated{*}. Please use python-driver
> [https://github.com/datastax/python-driver] instead._
> above from homepage at
> [https://code.google.com/archive/a/apache-extras.org/p/cassandra-dbapi2|https://code.google.com/archive/a/apache-extras.org/p/cassandra-dbapi2_]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17271) Remove unused dependency of geomet from cqlsh.py
[
https://issues.apache.org/jira/browse/CASSANDRA-17271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17271:
Status: Review In Progress (was: Needs Committer)
> Remove unused dependency of geomet from cqlsh.py
>
>
> Key: CASSANDRA-17271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17271
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> The python library *geomet* is used (optionally) by a unit test in the python
> driver, but was made optional in v3.24.0 of the cassandra-driver:
> * 👉 Make geomet an optional dependency at runtime (PYTHON-1237)
> It's inclusion on the sys.path for cqlsh would appear unnecessary and unused.
>
> cqlsh.py:
> {quote}third_parties = ('futures-', 'six-', 'geomet-'){quote}
> {quote}for lib in third_parties:
> lib_zip = find_zip(lib)
> if lib_zip:
> sys.path.insert(0, lib_zip){quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17204) Upgrade to Logback 1.2.9 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17204:
Status: Ready to Commit (was: Review In Progress)
> Upgrade to Logback 1.2.9 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17247) Remove unused dependencies from pylib/requirements.txt
[
https://issues.apache.org/jira/browse/CASSANDRA-17247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17247:
Status: Review In Progress (was: Needs Committer)
> Remove unused dependencies from pylib/requirements.txt
> --
>
> Key: CASSANDRA-17247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17247
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17247-removed-obsolete-cql-dependency.patch
>
>
> The dependency 'cql' appears to be obsolete in requirements.txt and is not
> imported by the python code.
> The package 'cql' was last updated in 2012 and has been deprecated by its
> authors
> [https://pypi.org/project/cql|https://pypi.org/project/cql/] (see
> release history)
> _A DB-API 2.0 compliant client library for Cassandra/CQL_
> _This driver has been {*}deprecated{*}. Please use python-driver
> [https://github.com/datastax/python-driver] instead._
> above from homepage at
> [https://code.google.com/archive/a/apache-extras.org/p/cassandra-dbapi2|https://code.google.com/archive/a/apache-extras.org/p/cassandra-dbapi2_]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
