[jira] [Commented] (CASSANDRA-19637) LWT conditions behavior on collections is inconsistent
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853817#comment-17853817
]
Ekaterina Dimitrova commented on CASSANDRA-19637:
-
I left some minor comments on the 4.0 PR.
CI looks fine for 4.0, but we need the primary J8 builds for 4.0 and 4.1
because this is what we ship, where we run all the eclipse warnings, etc.
Was it confirmed that Accord follows the same rules for unfrozen collection?
Also, shall we confirm we want to fix this by changing behavior in patch
releases? I know the ticket was mentioned on the mailing list, but I don't
think the intentions were mentioned, so people really can confirm that is
acceptable.
Once we clear this, I will check the rest of the branches.
> LWT conditions behavior on collections is inconsistent
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> LWT conditions behaviour on collections is inconsistent in several ways
> around null values:
> 1)+Conditions comparing a collection column with a {{null}} value to a
> non-null have a different behaviour for frozen and non-frozen collection+.
> {code}UPDATE myTable SET l = ? WHERE k = 0 IF l < [1, 2]{code}
> If {{l}} is null the previous query will return {{[false, null]}} for a
> frozen collection and {{[true]}} for a non-frozen collection.
> 2) +Conditions on non-frozen collection treat empty differently from null+
> Due to the way multi-cell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multi-cell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA = []{code} the returned
> results will be {code}{false, null}{code}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations is
> to consider empty multi-cell collection input as {{null}} and reject the
> {{null}} input for non {{=}} and {{!=}} operators.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19637) LWT conditions behavior on collections is inconsistent
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19637:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova
Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Status: Review In Progress (was: Patch Available)
> LWT conditions behavior on collections is inconsistent
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> LWT conditions behaviour on collections is inconsistent in several ways
> around null values:
> 1)+Conditions comparing a collection column with a {{null}} value to a
> non-null have a different behaviour for frozen and non-frozen collection+.
> {code}UPDATE myTable SET l = ? WHERE k = 0 IF l < [1, 2]{code}
> If {{l}} is null the previous query will return {{[false, null]}} for a
> frozen collection and {{[true]}} for a non-frozen collection.
> 2) +Conditions on non-frozen collection treat empty differently from null+
> Due to the way multi-cell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multi-cell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA = []{code} the returned
> results will be {code}{false, null}{code}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations is
> to consider empty multi-cell collection input as {{null}} and reject the
> {{null}} input for non {{=}} and {{!=}} operators.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18831) Enable Cassandra to build and run under JDK21
[
https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853177#comment-17853177
]
Ekaterina Dimitrova commented on CASSANDRA-18831:
-
{quote}It looks like {{.measureDeep()}} on {{{}ConcurrentHashMap{}}}'s are
giving us size of the {{WeakReference}} and not following them even though we
have {{measureNonStrongReferences()}} specified during construction of the
{{{}MemoryMeter{}}}. I ran through all the unit tests in jamm w/JDK21 and the
only one that failed was hard-coded w/some assumptions about the internals of
data structures in the JDK, so I'm _assuming_ that things aren't horrendously
broken there. Probably warrants more investigation.
{quote}
Thanks for all your investigations and for posting your branch! Indeed, Jamm is
upgraded only to JDK17. Someone will need to take over upgrading it post JDK17,
verifying all new memory layout changes. Jamm is handled in issues in its repo,
but we also open a Cassandra ticket with the component jamm for visibility when
people work on it or just a ticket for the failures we see and post updates
about working on fixing jamm.
> Enable Cassandra to build and run under JDK21
> -
>
> Key: CASSANDRA-18831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18831
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Achilles Benetopoulos
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.x
>
> Attachments: jdk21-patch
>
>
> This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list
> of supported Java versions, and extends that work to enable building and
> running Cassandra under JDK21.
> The following commits comprise the changes included in the attached patch:
> -
> [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47]
> -
> [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897]
> -
> [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913]
> -
> [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19637) LWT conditions behavior on collections is inconsistent
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19637:
Fix Version/s: 4.0.x
4.1.x
5.0.x
5.x
> LWT conditions behavior on collections is inconsistent
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> LWT conditions behaviour on collections is inconsistent in several ways
> around null values:
> 1)+Conditions comparing a collection column with a {{null}} value to a
> non-null have a different behaviour for frozen and non-frozen collection+.
> {code}UPDATE myTable SET l = ? WHERE k = 0 IF l < [1, 2]{code}
> If {{l}} is null the previous query will return {{[false, null]}} for a
> frozen collection and {{[true]}} for a non-frozen collection.
> 2) +Conditions on non-frozen collection treat empty differently from null+
> Due to the way multi-cell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multi-cell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA = []{code} the returned
> results will be {code}{false, null}{code}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations is
> to consider empty multi-cell collection input as {{null}} and reject the
> {{null}} input for non {{=}} and {{!=}} operators.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852558#comment-17852558
]
Ekaterina Dimitrova commented on CASSANDRA-19604:
-
{quote}Should I create a Jira in CASSANDRA-19224 for SAI support for the new
{{BETWEEN}} operator?
{quote}
That would be great, thanks :)
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19604:
Status: Ready to Commit (was: Review In Progress)
Approved [GitHub Pull Request
#3345|https://github.com/apache/cassandra/pull/3345]
Thank you both! There are just 3 nits that can be addressed on commit or not.
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852217#comment-17852217
]
Ekaterina Dimitrova edited comment on CASSANDRA-19604 at 6/4/24 11:38 PM:
--
Making final pass of [GitHub Pull Request
#3345|https://github.com/apache/cassandra/pull/3345] , CI run:
[https://app.circleci.com/pipelines/github/blerer/cassandra/416/workflows/cc2cebdf-452f-46d8-aec7-ea342c686f96]
I made the JDK17 build locally and it passes.
We found all the test failures in previous runs or tickets.
New tickets are needed for:
* test_rename_column_atomicity
* bounceTest
* org.apache.cassandra.fuzz.sai.MultiNodeSAITest - timing out on too log
without output
* test_tracing_default_impl
Known failures:
test_stop_failure_policy - CASSANDRA-19100
org.apache.cassandra.simulator.test.HarrySimulatorTest - CASSANDRA-19279
updateTokensTest-oa_jdk11 - CASSANDRA-19089
testMessageDeliveryOnReconnect-oa_jdk11 - CASSANDRA-16677
org.apache.cassandra.db.ColumnsTest-oa_jdk11 - seems environmental, and it does
not fail locally.
was (Author: e.dimitrova):
Making final pass of [GitHub Pull Request
#3345|https://github.com/apache/cassandra/pull/3345] , CI run:
[https://app.circleci.com/pipelines/github/blerer/cassandra/416/workflows/cc2cebdf-452f-46d8-aec7-ea342c686f96]
I make the JDK17 build locally and it passes.
We found all the test failures in previous runs or tickets.
New tickets are needed for:
* test_rename_column_atomicity
* bounceTest
* org.apache.cassandra.fuzz.sai.MultiNodeSAITest - timing out on too log
without output
* test_tracing_default_impl
Known failures:
test_stop_failure_policy - CASSANDRA-19100
org.apache.cassandra.simulator.test.HarrySimulatorTest - CASSANDRA-19279
updateTokensTest-oa_jdk11 - CASSANDRA-19089
testMessageDeliveryOnReconnect-oa_jdk11 - CASSANDRA-16677
org.apache.cassandra.db.ColumnsTest-oa_jdk11 - seems environmental, and it does
not fail locally.
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852217#comment-17852217
]
Ekaterina Dimitrova edited comment on CASSANDRA-19604 at 6/4/24 11:38 PM:
--
Making final pass of [GitHub Pull Request
#3345|https://github.com/apache/cassandra/pull/3345] , CI run:
[https://app.circleci.com/pipelines/github/blerer/cassandra/416/workflows/cc2cebdf-452f-46d8-aec7-ea342c686f96]
I made the JDK17 build locally and it passes.
We found all the test failures in previous runs or tickets.
New tickets are needed for:
* test_rename_column_atomicity
* bounceTest
* org.apache.cassandra.fuzz.sai.MultiNodeSAITest - timing out on too log
without output
* test_tracing_default_impl
Known failures:
* test_stop_failure_policy - CASSANDRA-19100
* org.apache.cassandra.simulator.test.HarrySimulatorTest - CASSANDRA-19279
* updateTokensTest-oa_jdk11 - CASSANDRA-19089
* testMessageDeliveryOnReconnect-oa_jdk11 - CASSANDRA-16677
org.apache.cassandra.db.ColumnsTest-oa_jdk11 - seems environmental, and it does
not fail locally.
was (Author: e.dimitrova):
Making final pass of [GitHub Pull Request
#3345|https://github.com/apache/cassandra/pull/3345] , CI run:
[https://app.circleci.com/pipelines/github/blerer/cassandra/416/workflows/cc2cebdf-452f-46d8-aec7-ea342c686f96]
I made the JDK17 build locally and it passes.
We found all the test failures in previous runs or tickets.
New tickets are needed for:
* test_rename_column_atomicity
* bounceTest
* org.apache.cassandra.fuzz.sai.MultiNodeSAITest - timing out on too log
without output
* test_tracing_default_impl
Known failures:
test_stop_failure_policy - CASSANDRA-19100
org.apache.cassandra.simulator.test.HarrySimulatorTest - CASSANDRA-19279
updateTokensTest-oa_jdk11 - CASSANDRA-19089
testMessageDeliveryOnReconnect-oa_jdk11 - CASSANDRA-16677
org.apache.cassandra.db.ColumnsTest-oa_jdk11 - seems environmental, and it does
not fail locally.
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852217#comment-17852217
]
Ekaterina Dimitrova commented on CASSANDRA-19604:
-
Making final pass of [GitHub Pull Request
#3345|https://github.com/apache/cassandra/pull/3345] , CI run:
[https://app.circleci.com/pipelines/github/blerer/cassandra/416/workflows/cc2cebdf-452f-46d8-aec7-ea342c686f96]
I make the JDK17 build locally and it passes.
We found all the test failures in previous runs or tickets.
New tickets are needed for:
* test_rename_column_atomicity
* bounceTest
* org.apache.cassandra.fuzz.sai.MultiNodeSAITest - timing out on too log
without output
* test_tracing_default_impl
Known failures:
test_stop_failure_policy - CASSANDRA-19100
org.apache.cassandra.simulator.test.HarrySimulatorTest - CASSANDRA-19279
updateTokensTest-oa_jdk11 - CASSANDRA-19089
testMessageDeliveryOnReconnect-oa_jdk11 - CASSANDRA-16677
org.apache.cassandra.db.ColumnsTest-oa_jdk11 - seems environmental, and it does
not fail locally.
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16677) Test Failure: Fix flaky ConnectionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16677: Summary: Test Failure: Fix flaky ConnectionTest (was: Fix flaky ConnectionTest) > Test Failure: Fix flaky ConnectionTest > -- > > Key: CASSANDRA-16677 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16677 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode, Test/unit >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > Attachments: TEST-org.apache.cassandra.net.ConnectionTest.log.xz > > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/ > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069 > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19604:
Test and Documentation Plan: The patch adds unit tests that cover the new
functionality. (was: The patch add unit tests that cover the new
functionality.)
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18467) Update generate-idea-files for J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18467: Source Control Link: https://github.com/apache/cassandra/commit/ac259438763ed96c402bab771567df59d18ad280 (was: +underlined text+https://github.com/apache/cassandra/commit/ac259438763ed96c402bab771567df59d18ad280) > Update generate-idea-files for J17 > -- > > Key: CASSANDRA-18467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Jakub Zytka >Priority: Low > Fix For: 5.0-alpha1, 5.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > There was a discussion in CASSANDRA-18258 how to update generate-idea-files. > The final agreement was to create one target to cover both Java 11 and Java > 17. > It will be good to figure out CASSANDRA-18263 and reshuffle arguments and > tasks based on what we decide to use as gc in testing for both Java 11 and > Java 17. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18467) Update generate-idea-files for J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18467: Source Control Link: +underlined text+https://github.com/apache/cassandra/commit/ac259438763ed96c402bab771567df59d18ad280 (was: https://github.com/apache/cassandra/commit/ac259438763ed96c402bab771567df59d18ad280) > Update generate-idea-files for J17 > -- > > Key: CASSANDRA-18467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Jakub Zytka >Priority: Low > Fix For: 5.0-alpha1, 5.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > There was a discussion in CASSANDRA-18258 how to update generate-idea-files. > The final agreement was to create one target to cover both Java 11 and Java > 17. > It will be good to figure out CASSANDRA-18263 and reshuffle arguments and > tasks based on what we decide to use as gc in testing for both Java 11 and > Java 17. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19661) Cannot restart Cassandra 5 after creating a vector table and index
[
https://issues.apache.org/jira/browse/CASSANDRA-19661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852123#comment-17852123
]
Ekaterina Dimitrova edited comment on CASSANDRA-19661 at 6/4/24 4:57 PM:
-
Thanks [~sergrua] , does this mean you were able to reproduce it also on HEAD
and the issue was not fixed by chance since beta1?
was (Author: e.dimitrova):
Thanks [~sergrua] , does this mean you were able to reproduce it also on HEAD?
> Cannot restart Cassandra 5 after creating a vector table and index
> --
>
> Key: CASSANDRA-19661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19661
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Sergio Rua
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> I'm using llama-index and llama3 to train a model. I'm using a very simple
> code that reads some *.txt files from local and uploads them to Cassandra and
> then creates the index:
>
> {code:java}
> # Create the index from documents
> index = VectorStoreIndex.from_documents(
> documents,
> service_context=vector_store.service_context,
> storage_context=storage_context,
> show_progress=True,
> ) {code}
> This works well and I'm able to use a Chat app to get responses from the
> Cassandra data. however, right after, I cannot restart Cassandra. It'll break
> with the following error:
>
> {code:java}
> INFO [PerDiskMemtableFlushWriter_0:7] 2024-05-23 08:23:20,102
> Flushing.java:179 - Completed flushing
> /data/cassandra/data/gpt/docs_20240523-10c8eaa018d811ef8dadf75182f3e2b4/da-6-bti-Data.db
> (124.236MiB) for commitlog position
> CommitLogPosition(segmentId=1716452305636, position=15336)
> [...]
> WARN [MemtableFlushWriter:1] 2024-05-23 08:28:29,575
> MemtableIndexWriter.java:92 - [gpt.docs.idx_vector_docs] Aborting index
> memtable flush for
> /data/cassandra/data/gpt/docs-aea77a80184b11ef8dadf75182f3e2b4/da-3-bti...{code}
> {code:java}
> java.lang.IllegalStateException: null
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:496)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.VectorPostings.computeRowIds(VectorPostings.java:76)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.OnHeapGraph.writeData(OnHeapGraph.java:313)
> at
> org.apache.cassandra.index.sai.memory.VectorMemoryIndex.writeDirect(VectorMemoryIndex.java:272)
> at
> org.apache.cassandra.index.sai.memory.MemtableIndex.writeDirect(MemtableIndex.java:110)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.flushVectorIndex(MemtableIndexWriter.java:192)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.complete(MemtableIndexWriter.java:117)
> at
> org.apache.cassandra.index.sai.disk.StorageAttachedIndexWriter.complete(StorageAttachedIndexWriter.java:185)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.commit(SSTableWriter.java:289)
> at
> org.apache.cassandra.db.compaction.unified.ShardedMultiWriter.commit(ShardedMultiWriter.java:219)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1323)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1222)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
> The table created by the script is as follows:
>
> {noformat}
> CREATE TABLE gpt.docs (
> partition_id text,
> row_id text,
> attributes_blob text,
> body_blob text,
> vector vector,
> metadata_s map,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> AND additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> 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.UnifiedCompactionStrategy',
> 'scaling_parameters': 'T4', 'target_sstable_size': '1GiB'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
>
[jira] [Commented] (CASSANDRA-19661) Cannot restart Cassandra 5 after creating a vector table and index
[
https://issues.apache.org/jira/browse/CASSANDRA-19661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852123#comment-17852123
]
Ekaterina Dimitrova commented on CASSANDRA-19661:
-
Thanks [~sergrua] , does this mean you were able to reproduce it also on HEAD?
> Cannot restart Cassandra 5 after creating a vector table and index
> --
>
> Key: CASSANDRA-19661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19661
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Sergio Rua
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> I'm using llama-index and llama3 to train a model. I'm using a very simple
> code that reads some *.txt files from local and uploads them to Cassandra and
> then creates the index:
>
> {code:java}
> # Create the index from documents
> index = VectorStoreIndex.from_documents(
> documents,
> service_context=vector_store.service_context,
> storage_context=storage_context,
> show_progress=True,
> ) {code}
> This works well and I'm able to use a Chat app to get responses from the
> Cassandra data. however, right after, I cannot restart Cassandra. It'll break
> with the following error:
>
> {code:java}
> INFO [PerDiskMemtableFlushWriter_0:7] 2024-05-23 08:23:20,102
> Flushing.java:179 - Completed flushing
> /data/cassandra/data/gpt/docs_20240523-10c8eaa018d811ef8dadf75182f3e2b4/da-6-bti-Data.db
> (124.236MiB) for commitlog position
> CommitLogPosition(segmentId=1716452305636, position=15336)
> [...]
> WARN [MemtableFlushWriter:1] 2024-05-23 08:28:29,575
> MemtableIndexWriter.java:92 - [gpt.docs.idx_vector_docs] Aborting index
> memtable flush for
> /data/cassandra/data/gpt/docs-aea77a80184b11ef8dadf75182f3e2b4/da-3-bti...{code}
> {code:java}
> java.lang.IllegalStateException: null
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:496)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.VectorPostings.computeRowIds(VectorPostings.java:76)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.OnHeapGraph.writeData(OnHeapGraph.java:313)
> at
> org.apache.cassandra.index.sai.memory.VectorMemoryIndex.writeDirect(VectorMemoryIndex.java:272)
> at
> org.apache.cassandra.index.sai.memory.MemtableIndex.writeDirect(MemtableIndex.java:110)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.flushVectorIndex(MemtableIndexWriter.java:192)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.complete(MemtableIndexWriter.java:117)
> at
> org.apache.cassandra.index.sai.disk.StorageAttachedIndexWriter.complete(StorageAttachedIndexWriter.java:185)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.commit(SSTableWriter.java:289)
> at
> org.apache.cassandra.db.compaction.unified.ShardedMultiWriter.commit(ShardedMultiWriter.java:219)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1323)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1222)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
> The table created by the script is as follows:
>
> {noformat}
> CREATE TABLE gpt.docs (
> partition_id text,
> row_id text,
> attributes_blob text,
> body_blob text,
> vector vector,
> metadata_s map,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> AND additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> 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.UnifiedCompactionStrategy',
> 'scaling_parameters': 'T4', 'target_sstable_size': '1GiB'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND memtable = 'default'
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND
[jira] [Commented] (CASSANDRA-18584) CEP-29: NOT operator
[
https://issues.apache.org/jira/browse/CASSANDRA-18584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851803#comment-17851803
]
Ekaterina Dimitrova commented on CASSANDRA-18584:
-
{quote}I am working on a patch that refactor the relation/restrictions
hierarchy. It should makes the code easier to modify while making it also less
errors prone.
{quote}
That work was committed - CASSANDRA-19341
I took over the rebase from [~blerer].
The non-SAI part is ready, and the tests are clean. I have to finish the SAI
part, and I will post a branch for review.
> CEP-29: NOT operator
>
>
> Key: CASSANDRA-18584
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18584
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Interpreter, CQL/Semantics, CQL/Syntax, Feature/SAI
>Reporter: Piotr Kolaczkowski
>Assignee: Piotr Kolaczkowski
>Priority: Normal
>
> Implement new CQL operators:
> - NOT CONTAINS,
> - NOT CONTAINS KEY,
> - NOT IN
> - NOT LIKE
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851802#comment-17851802
]
Ekaterina Dimitrova commented on CASSANDRA-19604:
-
This seems almost ready. Left a few comments on the PR. I will do a final full
pass once the latest test failures and agreement around SAI filtering are
addressed. Thank you.
[~xvade], I believe [~blerer] is already looking into those things so nothing
is expected from you here! Thank you so much for your great work!
[~blerer] , I suggest we pull the NOT BETWEEN scope to a separate ticket.
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19100) commitlog_test.py::TestCommitLog::test_stop_failure_policy failed
[
https://issues.apache.org/jira/browse/CASSANDRA-19100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851792#comment-17851792
]
Ekaterina Dimitrova commented on CASSANDRA-19100:
-
Seen again here for trunk -
https://app.circleci.com/pipelines/github/blerer/cassandra/413/workflows/fdcfda35-d2f9-4d15-8c76-f6b381b09991/jobs/12274/tests
> commitlog_test.py::TestCommitLog::test_stop_failure_policy failed
> -
>
> Key: CASSANDRA-19100
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19100
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1121/workflows/fce907b1-0526-4d4d-beb5-b6620737a5f3/jobs/50905/tests
> {noformat}
> AssertionError: Cannot find the commitlog failure message in logs
> assert []
> self =
> def test_stop_failure_policy(self):
> """
> Test the stop commitlog failure policy (default one)
> """
> self.prepare()
>
> self._provoke_commitlog_failure()
> failure = self.node1.grep_log("Failed .+ commit log segments. Commit
> disk failure policy is stop; terminating thread")
> logger.debug(failure)
> > assert failure, "Cannot find the commitlog failure message in logs"
> E AssertionError: Cannot find the commitlog failure message in logs
> E assert []
> commitlog_test.py:325: AssertionError
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851701#comment-17851701 ] Ekaterina Dimitrova commented on CASSANDRA-19676: - We were just running tests for another patch. Seems like some of the failures match what you see here: [https://app.circleci.com/pipelines/github/blerer/cassandra/413/workflows/fdcfda35-d2f9-4d15-8c76-f6b381b09991] I guess something went south with some of the latest patches committed to trunk > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-02-17-25-25-071.png > > Time Spent: 20m > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16895) Build with Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16895:
Fix Version/s: 5.0
(was: 5.x)
> Build with Java 17
> --
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Epic
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0
>
>
> This ticket is intended to group all issues found to support Java 17 in the
> future.
> Upgrade steps:
> * [Dependencies
> |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to
> be updated (not all but at least those that require an update in order to
> work with Java 17)
> * More encapsulated JDK internal APIs. Some of the issues might be solved
> with the dependencies updates
> * Currently trunk compiles if we remove the Nashorn dependency (ant script
> tag, used for the test environment; UDFs) . The oracle recommendation to use
> Nashorn-core won't work for the project as it is under GPL 2.0. Most probably
> we will opt in for graal-sdk licensed under UPL
> * All tests to be cleaned
> * CI environment to be setup
> *NOTE:* GC tuning, performance testing were never agreed to be part of this
> ticket.
> Below is a snapshot of current CI failures with JDK17, it will be updated on
> a regular basis with a date of update
> *July 15th 2023*
> || ||Failing Test Classes||Ticket Numbers||
> | |_Python DTests_| |
> |1|-test_sjk-|CASSANDRA-18343|
> | |_Java Ditributed Tests_| |
> |1-6|-org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all
> tests,-
> -org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all
> tests,-
> -org.apache.cassandra.distributed.test.IPMembershipTest - both tests,-
> -org.apache.cassandra.distributed.test.MixedModeFuzzTest,-
> -org.apache.cassandra.distributed.test.ReprepareFuzzTest,-
> -org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest-|CASSANDRA-16304|
> |7,8|-org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> - all tests-
> -org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all
> tests-|Both tests suffer from CASSANDRA-18180 -
> *ready to commit; blocked on being ready to drop JDK8*
>
> fwiw, using the CASSANDRA-18180 branch, only the
> negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests.
>
> EDIT: We will need a ticket for this one post CASSANDRA-18180. TLSv1.1 failed
> to negotiate (netty complains about certificate_unknown). Changes in JDK17
> config to be checked - done
>
> EDIT2: CASSANDRA-18540|
> |-9-|-org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest
> - 2 tests-|CASSANDRA-18180 ready to commit; blocked on being ready to drop
> JDK8|
> | |_Unit Tests_| |
> |1|-org.apache.cassandra.repair.RepairJobTest - 1 test-|CASSANDRA-18329|
> |2|-org.apache.cassandra.security.SSLFactoryTest - all tests-|CASSANDRA-17992|
> |3,4|-org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest,-
> -org.apache.cassandra.utils.concurrent.RefCountedTest-|CASSANDRA-18329|
> |5,6|-org.apache.cassandra.cql3.validation.entities.UFJavaTest,-
> -org.apache.cassandra.cql3.validation.entities.UFSecurityTest-|CASSANDRA-18190;
> ready to commit; blocked on being ready to drop JDK8|
> |7|-org.apache.cassandra.cql3.EmptyValuesTest-|CASSANDRA-18436|
> |8|{-}org.apache.cassandra.transport.MessagePayloadTest{-}.jdk17-|CASSANDRA-18437|
> |9|-StandaloneSplitterWithCQLTesterTest/testSplittingMultipleSSTables-|CASSANDRA-18685|
> | |_Burn tests_| |
> |1|-org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-|CASSANDRA-18570|
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Status: Review In Progress (was: Patch Available) > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Reviewers: Benjamin Lerer, Ekaterina Dimitrova (was: Benjamin Lerer) > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Authors: Benjamin Lerer, Ekaterina Dimitrova (was: Ekaterina Dimitrova) > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19534) unbounded queues in native transport requests lead to node instability
[
https://issues.apache.org/jira/browse/CASSANDRA-19534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848777#comment-17848777
]
Ekaterina Dimitrova commented on CASSANDRA-19534:
-
{quote}+1 LGTM
(dropped a couple more little cleanup nits in the PR)
{quote}
Does this mean this is ready to commit? :D I am excited as this is one of the
last two 5.0 rc blockers
> unbounded queues in native transport requests lead to node instability
> --
>
> Key: CASSANDRA-19534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19534
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Jon Haddad
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Attachments: Scenario 1 - QUEUE + Backpressure.jpg, Scenario 1 -
> QUEUE.jpg, Scenario 1 - Stock.jpg, Scenario 2 - QUEUE + Backpressure.jpg,
> Scenario 2 - QUEUE.jpg, Scenario 2 - Stock.jpg, ci_summary.html,
> image-2024-05-03-16-08-10-101.png, screenshot-1.png, screenshot-2.png,
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png,
> screenshot-7.png, screenshot-8.png, screenshot-9.png
>
> Time Spent: 9h 50m
> Remaining Estimate: 0h
>
> When a node is under pressure, hundreds of thousands of requests can show up
> in the native transport queue, and it looks like it can take way longer to
> timeout than is configured. We should be shedding load much more
> aggressively and use a bounded queue for incoming work. This is extremely
> evident when we combine a resource consuming workload with a smaller one:
> Running 5.0 HEAD on a single node as of today:
> {noformat}
> # populate only
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --maxrlat 100 --populate
> 10m --rate 50k -n 1
> # workload 1 - larger reads
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --rate 200 -d 1d
> # second workload - small reads
> easy-cass-stress run KeyValue -p 1m --rate 20k -r .5 -d 24h{noformat}
> It appears our results don't time out at the requested server time either:
>
> {noformat}
> Writes Reads
> Deletes Errors
> Count Latency (p99) 1min (req/s) | Count Latency (p99) 1min (req/s) |
> Count Latency (p99) 1min (req/s) | Count 1min (errors/s)
> 950286 70403.93 634.77 | 789524 70442.07 426.02 |
> 0 0 0 | 9580484 18980.45
> 952304 70567.62 640.1 | 791072 70634.34 428.36 |
> 0 0 0 | 9636658 18969.54
> 953146 70767.34 640.1 | 791400 70767.76 428.36 |
> 0 0 0 | 9695272 18969.54
> 956833 71171.28 623.14 | 794009 71175.6 412.79 |
> 0 0 0 | 9749377 19002.44
> 959627 71312.58 656.93 | 795703 71349.87 435.56 |
> 0 0 0 | 9804907 18943.11{noformat}
>
> After stopping the load test altogether, it took nearly a minute before the
> requests were no longer queued.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-10715) Allow filtering on NULL
[
https://issues.apache.org/jira/browse/CASSANDRA-10715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-10715:
---
Assignee: Benjamin Lerer (was: Ekaterina Dimitrova)
> Allow filtering on NULL
> ---
>
> Key: CASSANDRA-10715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10715
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
> Environment: C* 3.0.0 | cqlsh | C# driver 3.0.0beta2 | Windows 2012 R2
>Reporter: Kishan Karunaratne
>Assignee: Benjamin Lerer
>Priority: Low
> Fix For: 5.x
>
> Attachments:
> 0001-Allow-null-values-in-filtered-searches-reuse-Operato.patch
>
>
> This is an issue I first noticed through the C# driver, but I was able to
> repro on cqlsh, leading me to believe this is a Cassandra bug.
> Given the following schema:
> {noformat}
> CREATE TABLE "TestKeySpace_4928dc892922"."coolMovies" (
> unique_movie_title text,
> movie_maker text,
> director text,
> list list,
> "mainGuy" text,
> "yearMade" int,
> PRIMARY KEY ((unique_movie_title, movie_maker), director)
> ) WITH CLUSTERING ORDER BY (director ASC)
> {noformat}
> Executing a SELECT with FILTERING on a non-PK column, using a NULL as the
> argument:
> {noformat}
> SELECT "mainGuy", "movie_maker", "unique_movie_title", "list", "director",
> "yearMade" FROM "coolMovies" WHERE "mainGuy" = null ALLOW FILTERING
> {noformat}
> returns a ReadFailure exception:
> {noformat}
> cqlsh:TestKeySpace_4c8f2cf8d5cc> SELECT "mainGuy", "movie_maker",
> "unique_movie_title", "list", "director", "yearMade" FROM "coolMovies" WHERE
> "mainGuy" = null ALLOW FILTERING;
> ←[0;1;31mTraceback (most recent call last):
> File "C:\Users\Kishan\.ccm\repository\3.0.0\bin\\cqlsh.py", line 1216, in
> perform_simple_statement
> result = future.result()
> File
> "C:\Users\Kishan\.ccm\repository\3.0.0\bin\..\lib\cassandra-driver-internal-only-3.0.0a3.post0-3f15725.zip\cassandra-driver-3.0.0a3.post0-3f15725\cassandra\cluster.py",
> line 3118, in result
> raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation
> failed - received 0 responses and 1 failures" info={'failures': 1,
> 'received_responses': 0, 'required_responses': 1, 'cons
> istency': 'ONE'}
> ←[0m
> {noformat}
> Cassandra log shows:
> {noformat}
> WARN [SharedPool-Worker-2] 2015-11-16 13:51:00,259
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-2,10,main]: {}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.filter.RowFilter$SimpleExpression.isSatisfiedBy(RowFilter.java:581)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToRow(RowFilter.java:243)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.transform.BaseRows.applyOne(BaseRows.java:95)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at org.apache.cassandra.db.transform.BaseRows.add(BaseRows.java:86)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.add(UnfilteredRows.java:21)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.transform.Transformation.add(Transformation.java:136)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.transform.Transformation.apply(Transformation.java:102)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:233)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:227)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:76)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:293)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:128)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:288)
>
[jira] [Updated] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19604:
Status: Review In Progress (was: Patch Available)
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846108#comment-17846108 ] Ekaterina Dimitrova commented on CASSANDRA-18106: - bq. We weren't running dtest-upgrade-large tests at all, so there was no need for jdk switching. (We'd forgotten about the --intensive flag on upgrade tests.) Good catch bq. Are these tests really testing something that is persisted (serialised), i.e. something that happens in 3.0 that persists and isn't a problem until two major version later in 5.0 ? That sounds more like serialisation tests (that don't even need to be upgrade tests). bq. ccm still supports jdk switching with JAVAx_HOME env vars, so if we need to we can still introduce these vars carefully for just these particular tests found in dtest-upgrade-large. (i.e. there's no change to undo here, we're still moving forward to a cleaner place…) That sounds like a topic for a new ticket? We should also add the missing --intensive flag to CircleCI config, too. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846092#comment-17846092
]
Ekaterina Dimitrova commented on CASSANDRA-18106:
-
{quote}From the comments it seems that both V3 and V4 will need to cross JDKs
{quote}
Not if we do not recommend that the JDK and Cassandra upgrade happen
simultaneously. Which we do not?
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846089#comment-17846089
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 5/13/24 9:59 PM:
--
{quote}We do have tests that need to change jdks. The dtest-upgrade-large* test
types have tests like
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
{quote}
I mentioned this back then, and if I remember correctly there was the argument
- we repeat test runs with the different branch upgrade test runs, we should
save resources?
If we consider change of jdks, we will be running the whole path when we run on
3.0, same on 3.11, same on 4.0, etc. Lots of repetition. Is this not an
argument anymore?
bq. Without the JAVAx_HOME variables set they skip steps that involve C*
versions that require a different jdk.
So this was intentional and those are not skipped when run with other branches
was (Author: e.dimitrova):
{quote}We do have tests that need to change jdks. The dtest-upgrade-large* test
types have tests like
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
{quote}
I mentioned this back then, and if I remember correctly there was the argument
- we repeat test runs with the different branch upgrade test runs, we should
save resources?
If we consider change of jdks, we will be running the whole path when we run on
3.0, same on 3.11, same on 4.0, etc. Lots of repetition. Is this not an
argument anymore?
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846089#comment-17846089
]
Ekaterina Dimitrova commented on CASSANDRA-18106:
-
{quote}We do have tests that need to change jdks. The dtest-upgrade-large* test
types have tests like
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
{quote}
I mentioned this back then, and if I remember correctly there was the argument
- we repeat test runs with the different branch upgrade test runs, we should
save resources?
If we consider change of jdks, we will be running the whole path when we run on
3.0, same on 3.11, same on 4.0, etc. Lots of repetition. Is this not an
argument anymore?
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845318#comment-17845318
]
Ekaterina Dimitrova commented on CASSANDRA-19604:
-
5.x, as this is a new feature it can only go to trunk. Updated the ticket fix
version
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19604:
Fix Version/s: 5.x
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845139#comment-17845139
]
Ekaterina Dimitrova commented on CASSANDRA-19604:
-
Thank you, [~xvade]! I believe you and [~blerer] already discussed the next
steps, which I agree with. Please let me know if you have any questions or
concerns. Also, as a reminder, CASSANDRA-19341 is now committed, so you can
rebase your patch on the latest Cassandra trunk branch.
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19628:
Status: Ready to Commit (was: Changes Suggested)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845025#comment-17845025
]
Ekaterina Dimitrova commented on CASSANDRA-19628:
-
bq. How does that look?
That's great +1 (y)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845019#comment-17845019
]
Ekaterina Dimitrova edited comment on CASSANDRA-19628 at 5/9/24 2:57 PM:
-
I have a suggestion, what do you think if we just point to the instruction
in-tree? - https://github.com/apache/cassandra/blob/trunk/pylib/README.asc
That one looks more up to date, plus we do not need to maintain instructions
for those tests in two places. People often forget to update the website.
About the current suggestion if we decide to go with it:
Without those configs set correctly, some of the tests will fail, and these
commands are mentioned as a procedure for running all tests. Can we correct the
config?
Also, a side note: the instruction claims we still use nosetest.
People best bet is to use cassandra-cqlsh-tests.sh which is mentioned in the
in-tree README
was (Author: e.dimitrova):
I have a suggestion, what do you think if we just point to the instruction
in-tree? - https://github.com/apache/cassandra/blob/trunk/pylib/README.asc
That one looks more up to date, plus we do not need to maintain instructions
for those tests in two places. People often forget to update the website.
About the current suggestion if we decide to go with it:
Without those configs set correctly, some of the tests will fail, and these
commands are mentioned as a procedure for running all tests. Can we correct the
config?
Also, a side note: the instruction claims we still use nosetest.
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19628:
Status: Changes Suggested (was: Review In Progress)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845019#comment-17845019
]
Ekaterina Dimitrova commented on CASSANDRA-19628:
-
I have a suggestion, what do you think if we just point to the instruction
in-tree? - https://github.com/apache/cassandra/blob/trunk/pylib/README.asc
That one looks more up to date, plus we do not need to maintain instructions
for those tests in two places. People often forget to update the website.
About the current suggestion if we decide to go with it:
Without those configs set correctly, some of the tests will fail, and these
commands are mentioned as a procedure for running all tests. Can we correct the
config?
Also, a side note: the instruction claims we still use nosetest.
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19628:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova
Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Status: Review In Progress (was: Patch Available)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844300#comment-17844300
]
Ekaterina Dimitrova edited comment on CASSANDRA-19341 at 5/7/24 1:47 PM:
-
[~smiklosovic], thank you for the ping and sorry for the noise, there were a
few empty lines removed by mistake in that test.
Ninja fixed to https://github.com/apache/cassandra-dtest.git
6dd7def9..1f81e1c9 trunk -> trunk
Tested the fixed cassandra-dtest trunk locally with all Cassandra branches 4.0+
was (Author: e.dimitrova):
[~smiklosovic], thank you for the ping and sorry for the noise, there were a
few empty lines removed by mistake in that test.
Ninja fixed to https://github.com/apache/cassandra-dtest.git
6dd7def9..1f81e1c9 trunk -> trunk
Tested the fixed branch locally on all branches 4.0+
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 32h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844300#comment-17844300
]
Ekaterina Dimitrova commented on CASSANDRA-19341:
-
[~smiklosovic], thank you for the ping and sorry for the noise, there were a
few empty lines removed by mistake in that test.
Ninja fixed to https://github.com/apache/cassandra-dtest.git
6dd7def9..1f81e1c9 trunk -> trunk
Tested the fixed branch locally on all branches 4.0+
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 32h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843844#comment-17843844
]
Ekaterina Dimitrova edited comment on CASSANDRA-19341 at 5/6/24 8:50 PM:
-
This was the latest CI run:
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436/jobs/11079/tests
- environmental, seen before. Considering the same tests passed with 11, we
did not see the need to rerun that job
The rest are known issues:
test_counter_node_down - CASSANDRA-19346
test_change_durable_writes - CASSANDRA-19601
test_cleanup - CASSANDRA-18908
org.apache.cassandra.simulator.test.HarrySimulatorTest - CASSANDRA-19279
New unit tests were not run in a loop as they are pretty deterministic.
Those that changed were changing primarily error messages text.
Thank you everyone!
was (Author: e.dimitrova):
This was the latest CI run:
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436/jobs/11079/tests
- environmental, seen before. Considering the same tests passed with 11, we
did not see the need to rerun that job
The rest are known issues:
test_counter_node_down - CASSANDRA-19346
test_change_durable_writes - CASSANDRA-19601
test_cleanup - CASSANDRA-18908
org.apache.cassandra.simulator.test.HarrySimulatorTest - CASSANDRA-19279
New unit tests were not run in a loop as they are pretty deterministic.
Thank you everyone!
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 32.5h
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Description: CASSANDRA-19341 added ColumnsExpression in restrictions. This ticket's target is to extend the kinds of ColumnsExpression and use them in conditions, too. Also, it should add a few other simplifications around ColumnCondition, which were suggested by [~blerer] was: CASSANDRA-19341 added ColumnsExpression in restrictions. This ticket's target is to extend the kinds of ColumnsExpression and use them in conditions, too. Also, it should add a few other simplifications around ColumnCondition, suggested by [~blerer] > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Change Category: Code Clarity Complexity: Normal Component/s: CQL/Interpreter Fix Version/s: 5.x Status: Open (was: Triage Needed) > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, > suggested by [~blerer] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19620) Refactor ColumnCondition post CASSANDRA-19341
Ekaterina Dimitrova created CASSANDRA-19620: --- Summary: Refactor ColumnCondition post CASSANDRA-19341 Key: CASSANDRA-19620 URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 Project: Cassandra Issue Type: Improvement Reporter: Ekaterina Dimitrova Assignee: Ekaterina Dimitrova CASSANDRA-19341 added ColumnsExpression in restrictions. This ticket's target is to extend the kinds of ColumnsExpression and use them in conditions, too. Also, it should add a few other simplifications around ColumnCondition, suggested by [~blerer] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843844#comment-17843844
]
Ekaterina Dimitrova commented on CASSANDRA-19341:
-
This was the latest CI run:
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436/jobs/11079/tests
- environmental, seen before. Considering the same tests passed with 11, we
did not see the need to rerun that job
The rest are known issues:
test_counter_node_down - CASSANDRA-19346
test_change_durable_writes - CASSANDRA-19601
test_cleanup - CASSANDRA-18908
org.apache.cassandra.simulator.test.HarrySimulatorTest - CASSANDRA-19279
New unit tests were not run in a loop as they are pretty deterministic.
Thank you everyone!
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 32.5h
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19619) Enforce contract for internal metrics naming
[
https://issues.apache.org/jira/browse/CASSANDRA-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843725#comment-17843725
]
Ekaterina Dimitrova commented on CASSANDRA-19619:
-
[~mmuzaf], this ticket is marked 5.0-rc blocker? Was this a mistake or is it a
blocker?
> Enforce contract for internal metrics naming
>
>
> Key: CASSANDRA-19619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19619
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Metrics have their internal representation which uniquely identifies a
> particular metric name. The name is formed as {{. type>..}}. For some metrics, the scope includes a
> metric name that is not necessary for uniqueness, this can be simplified.
> For example,
> {code}
> // AS IS
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits
> // TO BE
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
> {code}
> The metrics are filtered based on knowledge of how they are formatted, so
> having a metric scope without a built-in metric name also simplifies the way
> we filter metrics.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19614) Add java version to prepare_release.sh human check step
[ https://issues.apache.org/jira/browse/CASSANDRA-19614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843023#comment-17843023 ] Ekaterina Dimitrova commented on CASSANDRA-19614: - +1 > Add java version to prepare_release.sh human check step > --- > > Key: CASSANDRA-19614 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19614 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > With the many versions of java one may need to float these days, it would be > nice for prepare_release.sh to show the version you are using when it asks > the "Is this what you want?" question showing the latest commit, that way > there is a chance to correct things before it tags. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842740#comment-17842740
]
Ekaterina Dimitrova edited comment on CASSANDRA-19341 at 5/1/24 6:36 PM:
-
The simulator failures are known from
CASSANDRA-19279 and CASSANDRA-19280
I also checked the rest of the tests yesterday, and I found/filed tickets for
all of them (except testSimpleSnapshot, which fails locally for me with the
patch). I can write a full report for the failures <-> tickets when we finish.
was (Author: e.dimitrova):
The simulator failures are known from
CASSANDRA-19279 and CASSANDRA-19280
I also checked the rest of the tests yesterday, and I found/filed tickets for
all of them. I can write down a full report failures <-> tickets when we are
done.
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 22h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842740#comment-17842740
]
Ekaterina Dimitrova commented on CASSANDRA-19341:
-
The simulator failures are known from
CASSANDRA-19279 and CASSANDRA-19280
I also checked the rest of the tests yesterday, and I found/filed tickets for
all of them. I can write down a full report failures <-> tickets when we are
done.
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 22h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842737#comment-17842737
]
Ekaterina Dimitrova commented on CASSANDRA-19341:
-
FYI, testSimpleSnapshot is failing with this patch, and it is under
investigation.
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 22h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17298) Test Failure: org.apache.cassandra.cql3.MemtableSizeTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842731#comment-17842731
]
Ekaterina Dimitrova commented on CASSANDRA-17298:
-
I don't know about the local error you get, but this is about the one you see
in CI:
4.0 and 4.1 use the old version of jamm where there were issues with the
crawling, so I am not surprised measureDeep hit closed module. This cannot be
related to your patch. It is jamm issue.
> Test Failure: org.apache.cassandra.cql3.MemtableSizeTest
>
>
> Key: CASSANDRA-17298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17298
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-4.0/313/testReport/org.apache.cassandra.cql3/MemtableSizeTest/testTruncationReleasesLogSpace_2/]
> Failed 4 times in the last 30 runs. Flakiness: 27%, Stability: 86%
> Error Message
> Expected heap usage close to 49.930MiB, got 41.542MiB.
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Expected heap usage close to 49.930MiB,
> got 41.542MiB.
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testSize(MemtableSizeTest.java:130)
> at org.apache.cassandra.Util.runCatchingAssertionError(Util.java:644)
> at org.apache.cassandra.Util.flakyTest(Util.java:669)
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace(MemtableSizeTest.java:61)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> *UPDATE:* It was discovered that unit tests were running with
> memtable_allocation_type: offheap_objects when we ship C* with heap_buffers.
> So we changed that in CASSANDRA-19326, now we test with
> memtable_allocation_type: heap_buffers. As a result, this test now fails all
> the time on 4.0 and 4.1.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19602) Test Failure: Java upgrade tests failing
[
https://issues.apache.org/jira/browse/CASSANDRA-19602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19602:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Fix Version/s: 5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: Java upgrade tests failing
>
>
> Key: CASSANDRA-19602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19602
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> As seen below plenty of java upgrade tests are failing on trunk:
> {code:java}
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHarryTest.simpleUpgradeTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.CompactStorageHiddenColumnTest.testHiddenColumnWithCompactStorage-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityUpgradedCoordinatorTest.testAvailability-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairDeleteTest.mixedModeReadRepairDeleteRow-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairDeleteTest.mixedModeReadRepairDeletePartition-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.UpgradeTest.simpleUpgradeWithNetworkAndGossipTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 4/8 /
> org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHintsTest.upgradeWithHintsTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 4/8 /
> org.apache.cassandra.distributed.upgrade.CompactStorageImplicitNullInClusteringTest.testImplicitNullInClusteringWithCompactStorage-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 4/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityUpgradedReplicaTest.testAvailability-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 4/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairWriteTest.mixedModeReadRepairInsert-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 4/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairWriteTest.mixedModeReadRepairUpdate-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 5/8 /
> org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHostIdTest.upgradeHostIdUpdateTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 5/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingTest.testPagingWithCompactStorage-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 5/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeConsistencyV30Test.testConsistency-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 5/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeRepairTest.testRepairDuringMajorUpgrade-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeIgnoreHostsTest.upgradeIgnoreHostsTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageMultipleClusterings-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageSingleClustering-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageWithoutClustering-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeFrom3LoggedBatchTest.testSimpleStrategy-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeTTLOverflowAfterUpgradeTest.testTTLOverflowAfterUpgrade-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 7/8 /
> org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeIgnoreHostTest.upgradeIgnoreHostsTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 7/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageMultipleClusterings-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 7/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageSingleClustering-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 7/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageWithoutClustering-_jdk11_x86_64
>
[jira] [Created] (CASSANDRA-19602) Test Failure: Java upgrade tests failing
Ekaterina Dimitrova created CASSANDRA-19602:
---
Summary: Test Failure: Java upgrade tests failing
Key: CASSANDRA-19602
URL: https://issues.apache.org/jira/browse/CASSANDRA-19602
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
As seen below plenty of java upgrade tests are failing on trunk:
{code:java}
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHarryTest.simpleUpgradeTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.CompactStorageHiddenColumnTest.testHiddenColumnWithCompactStorage-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityUpgradedCoordinatorTest.testAvailability-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.MixedModeReadRepairDeleteTest.mixedModeReadRepairDeleteRow-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.MixedModeReadRepairDeleteTest.mixedModeReadRepairDeletePartition-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.UpgradeTest.simpleUpgradeWithNetworkAndGossipTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 4/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHintsTest.upgradeWithHintsTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 4/8 /
org.apache.cassandra.distributed.upgrade.CompactStorageImplicitNullInClusteringTest.testImplicitNullInClusteringWithCompactStorage-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 4/8 /
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityUpgradedReplicaTest.testAvailability-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 4/8 /
org.apache.cassandra.distributed.upgrade.MixedModeReadRepairWriteTest.mixedModeReadRepairInsert-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 4/8 /
org.apache.cassandra.distributed.upgrade.MixedModeReadRepairWriteTest.mixedModeReadRepairUpdate-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 5/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHostIdTest.upgradeHostIdUpdateTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 5/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingTest.testPagingWithCompactStorage-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 5/8 /
org.apache.cassandra.distributed.upgrade.MixedModeConsistencyV30Test.testConsistency-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 5/8 /
org.apache.cassandra.distributed.upgrade.MixedModeRepairTest.testRepairDuringMajorUpgrade-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeIgnoreHostsTest.upgradeIgnoreHostsTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageMultipleClusterings-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageSingleClustering-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageWithoutClustering-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.MixedModeFrom3LoggedBatchTest.testSimpleStrategy-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.MixedModeTTLOverflowAfterUpgradeTest.testTTLOverflowAfterUpgrade-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeIgnoreHostTest.upgradeIgnoreHostsTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageMultipleClusterings-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageSingleClustering-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageWithoutClustering-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.MixedModeFrom3ReplicationTest.testSimpleStrategy-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.MixedModeTTLOverflowDuringUpgradeTest.testTTLOverflowDuringUpgrade-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 8/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeTest.simpleUpgradeTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 8/8 /
[jira] [Created] (CASSANDRA-19601) Test failure: test_change_durable_writes
Ekaterina Dimitrova created CASSANDRA-19601:
---
Summary: Test failure: test_change_durable_writes
Key: CASSANDRA-19601
URL: https://issues.apache.org/jira/browse/CASSANDRA-19601
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Failing on trunk:
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1880/testReport/junit/dtest-latest.configuration_test/TestConfiguration/Tests___dtest_latest_jdk11_31_64___test_change_durable_writes/]
[https://app.circleci.com/pipelines/github/blerer/cassandra/400/workflows/893a0edb-9181-4981-b542-77228c8bc975/jobs/10941/tests]
{code:java}
AssertionError: Commitlog was written with durable writes disabled
assert 90112 == 86016
+90112
-86016
self =
@pytest.mark.timeout(60*30)
def test_change_durable_writes(self):
"""
@jira_ticket CASSANDRA-9560
Test that changes to the DURABLE_WRITES option on keyspaces is
respected in subsequent writes.
This test starts by writing a dataset to a cluster and asserting that
the commitlogs have been written to. The subsequent test depends on
the assumption that this dataset triggers an fsync.
After checking this assumption, the test destroys the cluster and
creates a fresh one. Then it tests that DURABLE_WRITES is respected by:
- creating a keyspace with DURABLE_WRITES set to false,
- using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
- writing a dataset to this keyspace that is known to trigger a
commitlog fsync,
- asserting that the commitlog has grown in size since the data was
written.
"""
cluster = self.cluster
cluster.set_batch_commitlog(enabled=True, use_batch_window =
cluster.version() < '5.0')
cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
cluster.populate(1).start()
durable_node = cluster.nodelist()[0]
durable_init_size = commitlog_size(durable_node)
durable_session = self.patient_exclusive_cql_connection(durable_node)
# test assumption that write_to_trigger_fsync actually triggers a
commitlog fsync
durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
{'class': 'SimpleStrategy', 'replication_factor': 1} "
"AND DURABLE_WRITES = true")
durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
int, b int, c int)')
logger.debug('commitlog size diff = ' +
str(commitlog_size(durable_node) - durable_init_size))
write_to_trigger_fsync(durable_session, 'ks', 'tab')
logger.debug('commitlog size diff = ' +
str(commitlog_size(durable_node) - durable_init_size))
assert commitlog_size(durable_node) > durable_init_size, \
"This test will not work in this environment;
write_to_trigger_fsync does not trigger fsync."
durable_session.shutdown()
cluster.stop()
cluster.clear()
cluster.set_batch_commitlog(enabled=True, use_batch_window =
cluster.version() < '5.0')
cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
cluster.start()
node = cluster.nodelist()[0]
session = self.patient_exclusive_cql_connection(node)
# set up a keyspace without durable writes, then alter it to use them
session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
'SimpleStrategy', 'replication_factor': 1} "
"AND DURABLE_WRITES = false")
session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
int, c int)')
init_size = commitlog_size(node)
write_to_trigger_fsync(session, 'ks', 'tab')
> assert commitlog_size(node) == init_size, "Commitlog was written with
> durable writes disabled"
E AssertionError: Commitlog was written with durable writes disabled
E assert 90112 == 86016
E +90112
E -86016
configuration_test.py:104: AssertionError
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19601) Test failure: test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19601:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Fix Version/s: 5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Test failure: test_change_durable_writes
>
>
> Key: CASSANDRA-19601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19601
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Failing on trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1880/testReport/junit/dtest-latest.configuration_test/TestConfiguration/Tests___dtest_latest_jdk11_31_64___test_change_durable_writes/]
> [https://app.circleci.com/pipelines/github/blerer/cassandra/400/workflows/893a0edb-9181-4981-b542-77228c8bc975/jobs/10941/tests]
> {code:java}
> AssertionError: Commitlog was written with durable writes disabled
> assert 90112 == 86016
> +90112
> -86016
> self =
> @pytest.mark.timeout(60*30)
> def test_change_durable_writes(self):
> """
> @jira_ticket CASSANDRA-9560
>
> Test that changes to the DURABLE_WRITES option on keyspaces is
> respected in subsequent writes.
>
> This test starts by writing a dataset to a cluster and asserting that
> the commitlogs have been written to. The subsequent test depends on
> the assumption that this dataset triggers an fsync.
>
> After checking this assumption, the test destroys the cluster and
> creates a fresh one. Then it tests that DURABLE_WRITES is respected
> by:
>
> - creating a keyspace with DURABLE_WRITES set to false,
> - using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
> - writing a dataset to this keyspace that is known to trigger a
> commitlog fsync,
> - asserting that the commitlog has grown in size since the data was
> written.
> """
> cluster = self.cluster
> cluster.set_batch_commitlog(enabled=True, use_batch_window =
> cluster.version() < '5.0')
>
> cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
>
> cluster.populate(1).start()
> durable_node = cluster.nodelist()[0]
>
> durable_init_size = commitlog_size(durable_node)
> durable_session = self.patient_exclusive_cql_connection(durable_node)
>
> # test assumption that write_to_trigger_fsync actually triggers a
> commitlog fsync
> durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
> {'class': 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = true")
> durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
> int, b int, c int)')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
> write_to_trigger_fsync(durable_session, 'ks', 'tab')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
>
> assert commitlog_size(durable_node) > durable_init_size, \
> "This test will not work in this environment;
> write_to_trigger_fsync does not trigger fsync."
>
> durable_session.shutdown()
> cluster.stop()
> cluster.clear()
>
> cluster.set_batch_commitlog(enabled=True, use_batch_window =
> cluster.version() < '5.0')
>
> cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
> cluster.start()
> node = cluster.nodelist()[0]
> session = self.patient_exclusive_cql_connection(node)
>
> # set up a keyspace without durable writes, then alter it to use them
> session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
> 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = false")
> session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
> int, c int)')
> init_size = commitlog_size(node)
> write_to_trigger_fsync(session, 'ks', 'tab')
> > assert commitlog_size(node) == init_size, "Commitlog was written with
> > durable writes disabled"
> E AssertionError: Commitlog was written with durable writes disabled
> E assert 90112 == 86016
> E +90112
> E -86016
> configuration_test.py:104: AssertionError
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CASSANDRA-19341) Relation and Restriction hierachies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19341:
Fix Version/s: 5.x
> Relation and Restriction hierachies are too complex and error prone
> ---
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 21h 50m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19341) Relation and Restriction hierachies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19341:
Reviewers: Berenguer Blasi, Ekaterina Dimitrova (was: Ekaterina Dimitrova)
> Relation and Restriction hierachies are too complex and error prone
> ---
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Time Spent: 21h 50m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19583) Make 0 work as 0+unit for all three config classes (DataStorageSpec, DurationSpec, DataRateSpec)
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19583:
Summary: Make 0 work as 0+unit for all three config classes
(DataStorageSpec, DurationSpec, DataRateSpec) (was: enable Make 0 work as
0+unit for all three config classes (DataStorageSpec, DurationSpec,
DataRateSpec))
> Make 0 work as 0+unit for all three config classes (DataStorageSpec,
> DurationSpec, DataRateSpec)
>
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Jon Haddad
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 without a unit attached for data, duration, and data spec
> config parameters, as 0 is always 0 no matter the unit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19583) enable Make 0 work as 0+unit for all three config classes (DataStorageSpec, DurationSpec, DataRateSpec)
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19583:
Description:
The inline docs say:
{noformat}
Setting this to 0 disables throttling.
{noformat}
However, on startup, we throw this error:
{noformat}
Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames omitted
{noformat}
We should allow 0 without a unit attached for data, duration, and data spec
config parameters, as 0 is always 0 no matter the unit.
was:
The inline docs say:
{noformat}
Setting this to 0 disables throttling.
{noformat}
However, on startup, we throw this error:
{noformat}
Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames omitted
{noformat}
We should allow 0 as per the inline doc.
> enable Make 0 work as 0+unit for all three config classes (DataStorageSpec,
> DurationSpec, DataRateSpec)
> ---
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Jon Haddad
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 without a unit attached for data, duration, and data spec
> config parameters, as 0 is always 0 no matter the unit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19583) setting compaction throughput to 0 throws a startup error
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842048#comment-17842048
]
Ekaterina Dimitrova edited comment on CASSANDRA-19583 at 4/29/24 3:53 PM:
--
{quote}0 can mean "unlimited", but "0MiB/s" indicates actually zero.
{quote}
This confused me.
{quote}To be clear, I'm suggesting we make "0" work, without a unit. I'm not
suggesting we change how 0MiB/s works. They can be equivalent.
{quote}
Thanks for clarifying.
Then let's change this ticket to improvement and change its description to
"enable 0 to work as 0+unit for all three config classes (DataStorageSpec,
DurationSpec, DataRateSpec)" and not particularly for the compaction throughput
config?
was (Author: e.dimitrova):
{quote}0 can mean "unlimited", but "0MiB/s" indicates actually zero.
{quote}
This confused me.
{quote}
To be clear, I'm suggesting we make "0" work, without a unit. I'm not
suggesting we change how 0MiB/s works. They can be equivalent.
{quote}
Thanks for clarifying.
Then let's change this ticket to improvement and change its description to
"enable 0 to work as 0+unit for all three cofig classes (DataStorageSpec,
DurationSpec, DataRateSpec)" and not particularly for the compaction throughput
config?
> setting compaction throughput to 0 throws a startup error
> -
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jon Haddad
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 as per the inline doc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19583) setting compaction throughput to 0 throws a startup error
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842048#comment-17842048
]
Ekaterina Dimitrova commented on CASSANDRA-19583:
-
{quote}0 can mean "unlimited", but "0MiB/s" indicates actually zero.
{quote}
This confused me.
{quote}
To be clear, I'm suggesting we make "0" work, without a unit. I'm not
suggesting we change how 0MiB/s works. They can be equivalent.
{quote}
Thanks for clarifying.
Then let's change this ticket to improvement and change its description to
"enable 0 to work as 0+unit for all three cofig classes (DataStorageSpec,
DurationSpec, DataRateSpec)" and not particularly for the compaction throughput
config?
> setting compaction throughput to 0 throws a startup error
> -
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jon Haddad
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 as per the inline doc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19583) setting compaction throughput to 0 throws a startup error
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842041#comment-17842041
]
Ekaterina Dimitrova commented on CASSANDRA-19583:
-
{quote} "0MiB/s" indicates actually zero.
{quote}
Indeed, this is something we saw with the old config pre-4.1 - there were cases
where 0 did not mean 0, or we used negatives or -1 to special case things,
which was very confusing IMHO.
Post-4.1 we encourage people to use guardrails or null for any special case
with the new config (as documented here -
[https://cassandra.apache.org/doc/4.1/cassandra/configuration/configuration.html,]
section {*}Notes for Cassandra Developers{*}). Unfortunately, we have to live
with the realities of some old configurations so we do not change
behavior/introduce regressions.
Compaction throughput is one of them - 0MiB/s always meant unlimited; the unit
was part of the config name, so we had to preserve the behavior. Also, it could
be unclear to special case 0 while having 0 with unit means something else.
Using null or guardrail sounds more deterministic. Last but not least, I think
it is too late to change the meaning of 0MiB/s for compaction throughput as it
was already released in 4.1 to mean "unlimited," and technically, it did not
change anything from before, where the unit was just in the name of the
parameter. We never had 0MiB/s meaning 0 for that property.
> setting compaction throughput to 0 throws a startup error
> -
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jon Haddad
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 as per the inline doc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19566) JSON encoded timestamp value does not always match non-JSON encoded value
[
https://issues.apache.org/jira/browse/CASSANDRA-19566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838985#comment-17838985
]
Ekaterina Dimitrova commented on CASSANDRA-19566:
-
Maybe I misunderstood something, isn’t Jenkins dev back to business after the
standalone Jenkins file was committed?
I see some runs here
[https://ci-cassandra.apache.org/job/Cassandra-5-devbranch/116/]
[~mck] ?
> JSON encoded timestamp value does not always match non-JSON encoded value
> -
>
> Key: CASSANDRA-19566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19566
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Bowen Song
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Description:
> "SELECT JSON ..." and "toJson(...)" on Cassandra 4.1.4 produces different
> date than "SELECT ..." for some timestamp type values.
>
> Steps to reproduce:
> {code:java}
> $ sudo docker pull cassandra:4.1.4
> $ sudo docker create --name cass cassandra:4.1.4
> $ sudo docker start cass
> $ # wait for the Cassandra instance becomes ready
> $ sudo docker exec -ti cass cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.1.0 | Cassandra 4.1.4 | CQL spec 3.4.6 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table tbl (id int, ts timestamp, primary key (id));
> cqlsh:test> insert into tbl (id, ts) values (1, -1376701920);
> cqlsh:test> select tounixtimestamp(ts), ts, tojson(ts) from tbl where id=1;
> system.tounixtimestamp(ts) | ts |
> system.tojson(ts)
> +-+
> -1376701920 | 1533-09-28 12:00:00.00+ | "1533-09-18
> 12:00:00.000Z"
> (1 rows)
> cqlsh:test> select json * from tbl where id=1;
> [json]
> -
> {"id": 1, "ts": "1533-09-18 12:00:00.000Z"}
> (1 rows)
> {code}
>
> Expected behaviour:
> The "select ts", "select tojson(ts)" and "select json *" should all produce
> the same date.
>
> Actual behaviour:
> The "select ts" produced the "1533-09-28" date but the "select tojson(ts)"
> and "select json *" produced the "1533-09-18" date.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838303#comment-17838303
]
Ekaterina Dimitrova commented on CASSANDRA-19565:
-
{quote} perhaps should continue that here
{quote}
That is what I would expect too
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas De Keulenaer
>Priority: Normal
> Fix For: 4.1.x
>
> Attachments: hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838287#comment-17838287
]
Ekaterina Dimitrova commented on CASSANDRA-19565:
-
{quote}I think updating something as far reaching as JNA in a minor release is
a tough sell, especially if we are only gaining cosmetics which we can obviate
the need for by changing the ownership in the packaging.
{quote}
+1 on what [~brandon.williams] said. If we can limit the amount of change to
only change of ownership with no side effects, I think the risk updating by
exception JNA in a patch release is not justified. It would require also @dev
discussion
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas De Keulenaer
>Priority: Normal
> Fix For: 4.1.x
>
> Attachments: hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18736) Streaming exception race creates corrupt transaction log files that prevent restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837338#comment-17837338
]
Ekaterina Dimitrova commented on CASSANDRA-18736:
-
Hey [~jonmeredith], I haven't tried myself, but I have people telling me they
reproduced the issue on 4.0.
I can try to ask for more details if that will help you.
> Streaming exception race creates corrupt transaction log files that prevent
> restart
> ---
>
> Key: CASSANDRA-18736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18736
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> On restart, Cassandra logs this message and terminates.
> {code:java}
> ERROR 2023-07-17T17:17:22,931 [main]
> org.apache.cassandra.db.lifecycle.LogTransaction:561 - Unexpected disk state:
> failed to read transaction log
> [nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log in
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043]
> Files and contents follow:
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log
> ABORT:[,0,0][737437348]
> ***This record should have been the last one in all replicas
>
> ADD:[/datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb-284490-big-,0,8][2493503833]
> {code}
> The root cause is a race during streaming exception handling.
> Although concurrent modification of to the {{LogTransaction}} was added for
> CASSANDRA-16225, there is nothing to prevent usage after the transaction is
> completed (committed/aborted) once it has been processed by
> {{TransactionTidier}} (after the last reference is released). Before the
> transaction is tidied, the {{LogFile}} keeps a list of records that are
> checked for completion before adding new entries. In {{TransactionTidier}}
> {{LogFile.records}} are cleared as no longer needed, however the
> LogTransaction/LogFile is still accessible to the stream.
> The changes in CASSANDRA-17273 added a parallel set of {{onDiskRecords}} that
> could be used to reliably recreate the transaction log at any new datadirs
> the same as the existing
> datadirs - regardless of the effect of
> {{LogTransaction.untrackNew/LogFile.remove}}
> If a streaming exception causes the LogTransaction to be aborted and tidied
> just before {{SimpleSSTableMultiWriter}} calls trackNew to add a new sstable.
> At the time of the call, the {{LogFile}} will not contain any {{LogReplicas}},
> {{LogFile.records}} will be empty, and {{LogFile.onDiskRecords}} will contain
> an {{ABORT}}.
> When {{LogTransaction.trackNew/LogFile.add}} is called, the check for
> completed transaction fails as records is empty, there are no replicas on the
> datadir, so {{maybeCreateReplicas}} creates a new txnlog file replica
> containing ABORT, then
> appends an ADD record.
> The LogFile has already been tidied after the abort so the txnlog file is not
> removed and sits on disk until a restart, causing the faiulre.
> There is a related exception caused with a different interleaving of aborts,
> after an sstable is added, however this is just a nuisance in the logs as the
> LogRelica is already created with an {{ADD}} record first.
> {code:java}
> java.lang.AssertionError:
> [ADD:[/datadir1/keyspace/table/nb-23314378-big-,0,8][1869379820]] is not
> tracked by 55be35b0-35d1-11ee-865d-8b1e3c48ca06
> at org.apache.cassandra.db.lifecycle.LogFile.remove(LogFile.java:388)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.untrackNew(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.untrackNew(LifecycleTransaction.java:577)
> at
> org.apache.cassandra.db.streaming.CassandraStreamReceiver$1.untrackNew(CassandraStreamReceiver.java:149)
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.abort(SimpleSSTableMultiWriter.java:95)
> at
> org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter.abort(RangeAwareSSTableWriter.java:191)
> at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:115)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:85)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:38)
> at
>
[jira] [Commented] (CASSANDRA-18736) Streaming exception race creates corrupt transaction log files that prevent restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837291#comment-17837291
]
Ekaterina Dimitrova commented on CASSANDRA-18736:
-
[~jonmeredith] , the fix versions mention 4.0, but I do not see a branch for
it. Do you plan to apply it on that branch too?
> Streaming exception race creates corrupt transaction log files that prevent
> restart
> ---
>
> Key: CASSANDRA-18736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18736
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> On restart, Cassandra logs this message and terminates.
> {code:java}
> ERROR 2023-07-17T17:17:22,931 [main]
> org.apache.cassandra.db.lifecycle.LogTransaction:561 - Unexpected disk state:
> failed to read transaction log
> [nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log in
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043]
> Files and contents follow:
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log
> ABORT:[,0,0][737437348]
> ***This record should have been the last one in all replicas
>
> ADD:[/datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb-284490-big-,0,8][2493503833]
> {code}
> The root cause is a race during streaming exception handling.
> Although concurrent modification of to the {{LogTransaction}} was added for
> CASSANDRA-16225, there is nothing to prevent usage after the transaction is
> completed (committed/aborted) once it has been processed by
> {{TransactionTidier}} (after the last reference is released). Before the
> transaction is tidied, the {{LogFile}} keeps a list of records that are
> checked for completion before adding new entries. In {{TransactionTidier}}
> {{LogFile.records}} are cleared as no longer needed, however the
> LogTransaction/LogFile is still accessible to the stream.
> The changes in CASSANDRA-17273 added a parallel set of {{onDiskRecords}} that
> could be used to reliably recreate the transaction log at any new datadirs
> the same as the existing
> datadirs - regardless of the effect of
> {{LogTransaction.untrackNew/LogFile.remove}}
> If a streaming exception causes the LogTransaction to be aborted and tidied
> just before {{SimpleSSTableMultiWriter}} calls trackNew to add a new sstable.
> At the time of the call, the {{LogFile}} will not contain any {{LogReplicas}},
> {{LogFile.records}} will be empty, and {{LogFile.onDiskRecords}} will contain
> an {{ABORT}}.
> When {{LogTransaction.trackNew/LogFile.add}} is called, the check for
> completed transaction fails as records is empty, there are no replicas on the
> datadir, so {{maybeCreateReplicas}} creates a new txnlog file replica
> containing ABORT, then
> appends an ADD record.
> The LogFile has already been tidied after the abort so the txnlog file is not
> removed and sits on disk until a restart, causing the faiulre.
> There is a related exception caused with a different interleaving of aborts,
> after an sstable is added, however this is just a nuisance in the logs as the
> LogRelica is already created with an {{ADD}} record first.
> {code:java}
> java.lang.AssertionError:
> [ADD:[/datadir1/keyspace/table/nb-23314378-big-,0,8][1869379820]] is not
> tracked by 55be35b0-35d1-11ee-865d-8b1e3c48ca06
> at org.apache.cassandra.db.lifecycle.LogFile.remove(LogFile.java:388)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.untrackNew(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.untrackNew(LifecycleTransaction.java:577)
> at
> org.apache.cassandra.db.streaming.CassandraStreamReceiver$1.untrackNew(CassandraStreamReceiver.java:149)
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.abort(SimpleSSTableMultiWriter.java:95)
> at
> org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter.abort(RangeAwareSSTableWriter.java:191)
> at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:115)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:85)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:38)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:53)
>
[jira] [Commented] (CASSANDRA-18831) Enable Cassandra to build and run under JDK21
[
https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836282#comment-17836282
]
Ekaterina Dimitrova commented on CASSANDRA-18831:
-
{quote}We bumped many of the dependencies already with 5.0
{quote}
{quote}Yep. Some of these I'm having to bump again were updated late last year
or .ea versions released in the past few months for JDK21 support since so much
more keeps getting locked down. Happening in spaces heavy with reflection (i.e.
testing, debugging, logging), not in production data serving paths, so I'm not
too worried about the introduction of the deps in their current forms.
{quote}
I agree with everything said. My point was more about the fact that you don't
have to update dependencies that haven't been touched in 5-6 years (there are
plenty of versions in between with breaking changes and long change logs to
consider). I hope that it makes it at least a bit easier and faster. Thanks
again for moving forward with this one!
> Enable Cassandra to build and run under JDK21
> -
>
> Key: CASSANDRA-18831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18831
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Achilles Benetopoulos
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.x
>
> Attachments: jdk21-patch
>
>
> This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list
> of supported Java versions, and extends that work to enable building and
> running Cassandra under JDK21.
> The following commits comprise the changes included in the attached patch:
> -
> [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47]
> -
> [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897]
> -
> [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913]
> -
> [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18831) Enable Cassandra to build and run under JDK21
[ https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836266#comment-17836266 ] Ekaterina Dimitrova commented on CASSANDRA-18831: - Thanks [~jmckenzie], I am happy to see this progressing! bq. I'll pursue getting that set up formally in the ASF space after we have general support merged That is what we were doing before, too - whatever can be merged and it is not breaking with the previous versions, gets merged. Some of the updates that were needed for JDK17 were committed from 4.1. Whatever will require a previous JDK version to be dropped (we maintain two) - it waits until the drop. The only issue is that there will be breakages until we have it in CI, as people do not test their patches on the new version, but we can't have everything. I was also fixing every now and then the broken trunk. We bumped many of the dependencies already with 5.0 > Enable Cassandra to build and run under JDK21 > - > > Key: CASSANDRA-18831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18831 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Achilles Benetopoulos >Assignee: Josh McKenzie >Priority: Normal > Fix For: 5.x > > Attachments: jdk21-patch > > > This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list > of supported Java versions, and extends that work to enable building and > running Cassandra under JDK21. > The following commits comprise the changes included in the attached patch: > - > [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47] > - > [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897] > - > [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913] > - > [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835001#comment-17835001 ] Ekaterina Dimitrova edited comment on CASSANDRA-19428 at 4/8/24 4:54 PM: - Opened tickets for the rest of the test failures and linked them here and in Butler. was (Author: e.dimitrova): Opened tickets for the rest of the test failures and linked them and in Butler. > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-beta2, 5.1-alpha, 5.1 > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835001#comment-17835001 ] Ekaterina Dimitrova commented on CASSANDRA-19428: - Opened tickets for the rest of the test failures and linked them and in Butler. > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-beta2, 5.1-alpha, 5.1 > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19540) Test Failure: test_sstablelevelreset
[
https://issues.apache.org/jira/browse/CASSANDRA-19540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19540:
Fix Version/s: 5.x
> Test Failure: test_sstablelevelreset
>
>
> Key: CASSANDRA-19540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19540
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> {code:java}
> self =
> def test_sstablelevelreset(self):
> """
> Insert data and call sstablelevelreset on a series of
> tables. Confirm level is reset to 0 using its output.
> Test a variety of possible errors and ensure response is resonable.
> @since 2.1.5
> @jira_ticket CASSANDRA-7614
> """
> cluster = self.cluster
> cluster.populate(1).start()
> node1 = cluster.nodelist()[0]
>
> # test by trying to run on nonexistent keyspace
> cluster.stop(gently=False)
> try:
> node1.run_sstablelevelreset("keyspace1", "standard1")
> except ToolError as e:
> assert re.search("ColumnFamily not found: keyspace1/standard1",
> str(e))
> # this should return exit code 1
> assert e.exit_status == 1, "Expected sstablelevelreset to have a
> return code of 1 == but instead return code was {}".format(
> e.exit_status)
>
> # now test by generating keyspace but not flushing sstables
> cluster.start()
> node1.stress(['write', 'n=100', 'no-warmup', '-schema',
> 'replication(factor=1)',
> '-rate', 'threads=8'])
> cluster.stop(gently=False)
>
> output, error, rc = node1.run_sstablelevelreset("keyspace1",
> "standard1")
> self._check_stderr_error(error)
> assert re.search("Found no sstables, did you give the correct
> keyspace", output)
> assert rc == 0, str(rc)
>
> # test by writing small amount of data and flushing (all sstables
> should be level 0)
> cluster.start()
> session = self.patient_cql_connection(node1)
> > session.execute(
> "ALTER TABLE keyspace1.standard1 with compaction={'class':
> 'LeveledCompactionStrategy', 'sstable_size_in_mb':1};")
> offline_tools_test.py:64:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042 coordinator_host=None>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
> request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042
> ../env3.8/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
> test_sstableofflinerelevel
> FLAKY
> offline_tools_test.TestOfflineTools
> test_resumable_decommission
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> The failure looks different in Jenkins:
>
[jira] [Updated] (CASSANDRA-19543) Test Failure: testConcurrentReadWriteWorkload
[
https://issues.apache.org/jira/browse/CASSANDRA-19543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19543:
Fix Version/s: 5.x
> Test Failure: testConcurrentReadWriteWorkload
> -
>
> Key: CASSANDRA-19543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19543
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Flaky on trunk, seen in Butler and here:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58940/tests#failed-test-0
> {code:java}
> java.lang.RuntimeException: Interrupting run because of an exception
> at
> org.apache.cassandra.harry.runner.Runner.mergeAndThrow(Runner.java:395)
> at
> org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.runInternal(Runner.java:305)
> at org.apache.cassandra.harry.runner.Runner.run(Runner.java:77)
> at
> org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest.testConcurrentReadWriteWorkload(ConcurrentQuiescentCheckerIntegrationTest.java:62)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: org.apache.cassandra.exceptions.ReadFailureException: Operation
> failed - received 0 responses and 1 failures: UNKNOWN from /127.0.0.1:7012
> at
> org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:161)
> at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:396)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:2071)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1941)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1818)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.execute(SinglePartitionReadCommand.java:479)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:75)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:483)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:540)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:347)
> at
> org.apache.cassandra.distributed.impl.Coordinator$1.hasNext(Coordinator.java:220)
> at
> org.apache.cassandra.distributed.api.QueryResults$1.hasNext(QueryResults.java:55)
> at
> org.apache.cassandra.distributed.api.QueryResults$IteratorQueryResult.hasNext(QueryResults.java:166)
> at
> org.apache.cassandra.distributed.api.QueryResult$1.hasNext(QueryResult.java:76)
> at com.google.common.collect.Iterators.addAll(Iterators.java:365)
> at com.google.common.collect.Lists.newArrayList(Lists.java:146)
> at com.google.common.collect.Iterators.toArray(Iterators.java:349)
> at
> org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:156)
> at
> org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:139)
> at
> org.apache.cassandra.harry.sut.SystemUnderTest.executeIdempotent(SystemUnderTest.java:54)
> at
> org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:328)
> at
> org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:322)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.lambda$validate$0(QuiescentChecker.java:72)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:78)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:72)
> at
> org.apache.cassandra.harry.visitors.RandomPartitionValidator.visit(RandomPartitionValidator.java:56)
> at
> org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.lambda$runInternal$0(Runner.java:296)
> at
> org.apache.cassandra.harry.runner.Runner.lambda$wrapInterrupt$3(Runner.java:368)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
>
[jira] [Updated] (CASSANDRA-19543) Test Failure: testConcurrentReadWriteWorkload
[
https://issues.apache.org/jira/browse/CASSANDRA-19543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19543:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Test/dtest/java
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: testConcurrentReadWriteWorkload
> -
>
> Key: CASSANDRA-19543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19543
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Flaky on trunk, seen in Butler and here:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58940/tests#failed-test-0
> {code:java}
> java.lang.RuntimeException: Interrupting run because of an exception
> at
> org.apache.cassandra.harry.runner.Runner.mergeAndThrow(Runner.java:395)
> at
> org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.runInternal(Runner.java:305)
> at org.apache.cassandra.harry.runner.Runner.run(Runner.java:77)
> at
> org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest.testConcurrentReadWriteWorkload(ConcurrentQuiescentCheckerIntegrationTest.java:62)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: org.apache.cassandra.exceptions.ReadFailureException: Operation
> failed - received 0 responses and 1 failures: UNKNOWN from /127.0.0.1:7012
> at
> org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:161)
> at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:396)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:2071)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1941)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1818)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.execute(SinglePartitionReadCommand.java:479)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:75)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:483)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:540)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:347)
> at
> org.apache.cassandra.distributed.impl.Coordinator$1.hasNext(Coordinator.java:220)
> at
> org.apache.cassandra.distributed.api.QueryResults$1.hasNext(QueryResults.java:55)
> at
> org.apache.cassandra.distributed.api.QueryResults$IteratorQueryResult.hasNext(QueryResults.java:166)
> at
> org.apache.cassandra.distributed.api.QueryResult$1.hasNext(QueryResult.java:76)
> at com.google.common.collect.Iterators.addAll(Iterators.java:365)
> at com.google.common.collect.Lists.newArrayList(Lists.java:146)
> at com.google.common.collect.Iterators.toArray(Iterators.java:349)
> at
> org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:156)
> at
> org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:139)
> at
> org.apache.cassandra.harry.sut.SystemUnderTest.executeIdempotent(SystemUnderTest.java:54)
> at
> org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:328)
> at
> org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:322)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.lambda$validate$0(QuiescentChecker.java:72)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:78)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:72)
> at
> org.apache.cassandra.harry.visitors.RandomPartitionValidator.visit(RandomPartitionValidator.java:56)
> at
> org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.lambda$runInternal$0(Runner.java:296)
> at
> org.apache.cassandra.harry.runner.Runner.lambda$wrapInterrupt$3(Runner.java:368)
> at
>
[jira] [Updated] (CASSANDRA-19542) Test Failure: test_resumable_decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19542:
Fix Version/s: 5.x
> Test Failure: test_resumable_decommission
> -
>
> Key: CASSANDRA-19542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19542
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> {code:java}
> self =
> @since('3.10')
> def test_resumable_decommission(self):
> """
> @jira_ticket CASSANDRA-12008
>
> Test decommission operation is resumable
> """
> self.fixture_dtest_setup.ignore_log_patterns = [r'Streaming error
> occurred',
> r'Error while
> decommissioning node',
> r'Remote peer
> 127.0.0.2 failed stream session',
> r'Remote peer
> \/?127.0.0.2:7000 failed stream session',
> r'peer 127.0.0.2:7000
> is probably down',]
> cluster = self.cluster
>
> cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
> 1})
> cluster.populate(3, install_byteman=True).start()
> node1, node2, node3 = cluster.nodelist()
>
> session = self.patient_cql_connection(node2)
> # reduce system_distributed RF to 2 so we don't require forceful
> decommission
> session.execute("ALTER KEYSPACE system_distributed WITH REPLICATION =
> {'class':'SimpleStrategy', 'replication_factor':'2'};")
> create_ks(session, 'ks', 2)
> create_cf(session, 'cf', columns={'c1': 'text', 'c2': 'text'})
> insert_c1c2(session, n=1, consistency=ConsistencyLevel.ALL)
>
> # Execute first rebuild, should fail
> with pytest.raises(ToolError):
> if cluster.version() >= '4.0':
> script = [mk_bman_path('4.0/decommission_failure_inject.btm')]
> else:
> script =
> [mk_bman_path('pre4.0/decommission_failure_inject.btm')]
> node2.byteman_submit(script)
> node2.nodetool('decommission')
>
> # Make sure previous ToolError is due to decommission
> node2.watch_log_for('Error while decommissioning node')
>
> # Decommission again
> mark = node2.mark_log()
> node2.nodetool('decommission')
>
> # Check decommision is done and we skipped transfereed ranges
> node2.watch_log_for('DECOMMISSIONED', from_mark=mark)
> node2.grep_log("Skipping transferred range .* of keyspace ks,
> endpoint {}".format(node2.address_for_current_version_slashy()),
> filename='debug.log')
>
> # Check data is correctly forwarded to node1 and node3
> cluster.remove(node2)
> node3.stop(gently=False)
> session = self.patient_exclusive_cql_connection(node1)
> session.execute('USE ks')
> for i in range(0, 1):
> query_c1c2(session, i, ConsistencyLevel.ONE)
> node1.stop(gently=False)
> node3.start()
> session.shutdown()
> mark = node3.mark_log()
> node3.watch_log_for('Starting listening for CQL clients',
> from_mark=mark)
> session = self.patient_exclusive_cql_connection(node3)
> session.execute('USE ks')
> for i in range(0, 1):
> > query_c1c2(session, i, ConsistencyLevel.ONE)
> topology_test.py:275:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:43: in query_c1c2
> assertions.assert_length_equal(rows, 1)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> object_with_length = [], expected_length = 1
> def assert_length_equal(object_with_length, expected_length):
> """
> Assert an object has a specific length.
> @param object_with_length The object whose length will be checked
> @param expected_length The expected length of the object
>
> Examples:
> assert_length_equal(res, nb_counter)
> """
> > assert len(object_with_length) == expected_length, \
> "Expected {} to have length {}, but instead is of length {}"\
> .format(object_with_length, expected_length,
> len(object_with_length))
> E AssertionError: Expected [] to have length 1, but instead is of
> length 0
> tools/assertions.py:267: AssertionError
> {code}
>
[jira] [Updated] (CASSANDRA-19542) Test Failure: test_resumable_decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19542:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Test/dtest/python
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_resumable_decommission
> -
>
> Key: CASSANDRA-19542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19542
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> {code:java}
> self =
> @since('3.10')
> def test_resumable_decommission(self):
> """
> @jira_ticket CASSANDRA-12008
>
> Test decommission operation is resumable
> """
> self.fixture_dtest_setup.ignore_log_patterns = [r'Streaming error
> occurred',
> r'Error while
> decommissioning node',
> r'Remote peer
> 127.0.0.2 failed stream session',
> r'Remote peer
> \/?127.0.0.2:7000 failed stream session',
> r'peer 127.0.0.2:7000
> is probably down',]
> cluster = self.cluster
>
> cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
> 1})
> cluster.populate(3, install_byteman=True).start()
> node1, node2, node3 = cluster.nodelist()
>
> session = self.patient_cql_connection(node2)
> # reduce system_distributed RF to 2 so we don't require forceful
> decommission
> session.execute("ALTER KEYSPACE system_distributed WITH REPLICATION =
> {'class':'SimpleStrategy', 'replication_factor':'2'};")
> create_ks(session, 'ks', 2)
> create_cf(session, 'cf', columns={'c1': 'text', 'c2': 'text'})
> insert_c1c2(session, n=1, consistency=ConsistencyLevel.ALL)
>
> # Execute first rebuild, should fail
> with pytest.raises(ToolError):
> if cluster.version() >= '4.0':
> script = [mk_bman_path('4.0/decommission_failure_inject.btm')]
> else:
> script =
> [mk_bman_path('pre4.0/decommission_failure_inject.btm')]
> node2.byteman_submit(script)
> node2.nodetool('decommission')
>
> # Make sure previous ToolError is due to decommission
> node2.watch_log_for('Error while decommissioning node')
>
> # Decommission again
> mark = node2.mark_log()
> node2.nodetool('decommission')
>
> # Check decommision is done and we skipped transfereed ranges
> node2.watch_log_for('DECOMMISSIONED', from_mark=mark)
> node2.grep_log("Skipping transferred range .* of keyspace ks,
> endpoint {}".format(node2.address_for_current_version_slashy()),
> filename='debug.log')
>
> # Check data is correctly forwarded to node1 and node3
> cluster.remove(node2)
> node3.stop(gently=False)
> session = self.patient_exclusive_cql_connection(node1)
> session.execute('USE ks')
> for i in range(0, 1):
> query_c1c2(session, i, ConsistencyLevel.ONE)
> node1.stop(gently=False)
> node3.start()
> session.shutdown()
> mark = node3.mark_log()
> node3.watch_log_for('Starting listening for CQL clients',
> from_mark=mark)
> session = self.patient_exclusive_cql_connection(node3)
> session.execute('USE ks')
> for i in range(0, 1):
> > query_c1c2(session, i, ConsistencyLevel.ONE)
> topology_test.py:275:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:43: in query_c1c2
> assertions.assert_length_equal(rows, 1)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> object_with_length = [], expected_length = 1
> def assert_length_equal(object_with_length, expected_length):
> """
> Assert an object has a specific length.
> @param object_with_length The object whose length will be checked
> @param expected_length The expected length of the object
>
> Examples:
> assert_length_equal(res, nb_counter)
> """
> > assert len(object_with_length) == expected_length, \
> "Expected {} to have length {}, but instead is of length {}"\
> .format(object_with_length, expected_length,
> len(object_with_length))
> E
[jira] [Created] (CASSANDRA-19543) Test Failure: testConcurrentReadWriteWorkload
Ekaterina Dimitrova created CASSANDRA-19543:
---
Summary: Test Failure: testConcurrentReadWriteWorkload
Key: CASSANDRA-19543
URL: https://issues.apache.org/jira/browse/CASSANDRA-19543
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Flaky on trunk, seen in Butler and here:
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58940/tests#failed-test-0
{code:java}
java.lang.RuntimeException: Interrupting run because of an exception
at
org.apache.cassandra.harry.runner.Runner.mergeAndThrow(Runner.java:395)
at
org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.runInternal(Runner.java:305)
at org.apache.cassandra.harry.runner.Runner.run(Runner.java:77)
at
org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest.testConcurrentReadWriteWorkload(ConcurrentQuiescentCheckerIntegrationTest.java:62)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Caused by: org.apache.cassandra.exceptions.ReadFailureException: Operation
failed - received 0 responses and 1 failures: UNKNOWN from /127.0.0.1:7012
at
org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:161)
at
org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:396)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:2071)
at
org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1941)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1818)
at
org.apache.cassandra.db.SinglePartitionReadCommand.execute(SinglePartitionReadCommand.java:479)
at
org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:75)
at
org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
at
org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:483)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:540)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:347)
at
org.apache.cassandra.distributed.impl.Coordinator$1.hasNext(Coordinator.java:220)
at
org.apache.cassandra.distributed.api.QueryResults$1.hasNext(QueryResults.java:55)
at
org.apache.cassandra.distributed.api.QueryResults$IteratorQueryResult.hasNext(QueryResults.java:166)
at
org.apache.cassandra.distributed.api.QueryResult$1.hasNext(QueryResult.java:76)
at com.google.common.collect.Iterators.addAll(Iterators.java:365)
at com.google.common.collect.Lists.newArrayList(Lists.java:146)
at com.google.common.collect.Iterators.toArray(Iterators.java:349)
at
org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:156)
at
org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:139)
at
org.apache.cassandra.harry.sut.SystemUnderTest.executeIdempotent(SystemUnderTest.java:54)
at
org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:328)
at
org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:322)
at
org.apache.cassandra.harry.model.QuiescentChecker.lambda$validate$0(QuiescentChecker.java:72)
at
org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:78)
at
org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:72)
at
org.apache.cassandra.harry.visitors.RandomPartitionValidator.visit(RandomPartitionValidator.java:56)
at
org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.lambda$runInternal$0(Runner.java:296)
at
org.apache.cassandra.harry.runner.Runner.lambda$wrapInterrupt$3(Runner.java:368)
at
org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19542) Test Failure: test_resumable_decommission
Ekaterina Dimitrova created CASSANDRA-19542:
---
Summary: Test Failure: test_resumable_decommission
Key: CASSANDRA-19542
URL: https://issues.apache.org/jira/browse/CASSANDRA-19542
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
{code:java}
self =
@since('3.10')
def test_resumable_decommission(self):
"""
@jira_ticket CASSANDRA-12008
Test decommission operation is resumable
"""
self.fixture_dtest_setup.ignore_log_patterns = [r'Streaming error
occurred',
r'Error while
decommissioning node',
r'Remote peer 127.0.0.2
failed stream session',
r'Remote peer
\/?127.0.0.2:7000 failed stream session',
r'peer 127.0.0.2:7000
is probably down',]
cluster = self.cluster
cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
1})
cluster.populate(3, install_byteman=True).start()
node1, node2, node3 = cluster.nodelist()
session = self.patient_cql_connection(node2)
# reduce system_distributed RF to 2 so we don't require forceful
decommission
session.execute("ALTER KEYSPACE system_distributed WITH REPLICATION =
{'class':'SimpleStrategy', 'replication_factor':'2'};")
create_ks(session, 'ks', 2)
create_cf(session, 'cf', columns={'c1': 'text', 'c2': 'text'})
insert_c1c2(session, n=1, consistency=ConsistencyLevel.ALL)
# Execute first rebuild, should fail
with pytest.raises(ToolError):
if cluster.version() >= '4.0':
script = [mk_bman_path('4.0/decommission_failure_inject.btm')]
else:
script =
[mk_bman_path('pre4.0/decommission_failure_inject.btm')]
node2.byteman_submit(script)
node2.nodetool('decommission')
# Make sure previous ToolError is due to decommission
node2.watch_log_for('Error while decommissioning node')
# Decommission again
mark = node2.mark_log()
node2.nodetool('decommission')
# Check decommision is done and we skipped transfereed ranges
node2.watch_log_for('DECOMMISSIONED', from_mark=mark)
node2.grep_log("Skipping transferred range .* of keyspace ks, endpoint
{}".format(node2.address_for_current_version_slashy()), filename='debug.log')
# Check data is correctly forwarded to node1 and node3
cluster.remove(node2)
node3.stop(gently=False)
session = self.patient_exclusive_cql_connection(node1)
session.execute('USE ks')
for i in range(0, 1):
query_c1c2(session, i, ConsistencyLevel.ONE)
node1.stop(gently=False)
node3.start()
session.shutdown()
mark = node3.mark_log()
node3.watch_log_for('Starting listening for CQL clients',
from_mark=mark)
session = self.patient_exclusive_cql_connection(node3)
session.execute('USE ks')
for i in range(0, 1):
> query_c1c2(session, i, ConsistencyLevel.ONE)
topology_test.py:275:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
tools/data.py:43: in query_c1c2
assertions.assert_length_equal(rows, 1)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
object_with_length = [], expected_length = 1
def assert_length_equal(object_with_length, expected_length):
"""
Assert an object has a specific length.
@param object_with_length The object whose length will be checked
@param expected_length The expected length of the object
Examples:
assert_length_equal(res, nb_counter)
"""
> assert len(object_with_length) == expected_length, \
"Expected {} to have length {}, but instead is of length {}"\
.format(object_with_length, expected_length,
len(object_with_length))
E AssertionError: Expected [] to have length 1, but instead is of length 0
tools/assertions.py:267: AssertionError
{code}
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19541) Test Failure: test_sstableofflinerelevel
[
https://issues.apache.org/jira/browse/CASSANDRA-19541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19541:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Component/s: CI
Test/dtest/python
Discovered By: User Report
Fix Version/s: 5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_sstableofflinerelevel
> -
>
> Key: CASSANDRA-19541
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19541
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> {code:java}
> self =
> def test_sstableofflinerelevel(self):
> """
> Generate sstables of varying levels.
> Reset sstables to L0 with sstablelevelreset
> Run sstableofflinerelevel and ensure tables are promoted correctly
> Also test a variety of bad inputs including nonexistent keyspace and
> sstables
> @since 2.1.5
> @jira_ticket CASSANDRA-8031
> """
> cluster = self.cluster
>
> cluster.set_configuration_options(values={'compaction_throughput_mb_per_sec':
> 0})
> cluster.populate(1).start()
> node1 = cluster.nodelist()[0]
>
> # NOTE - As of now this does not return when it encounters Exception
> and causes test to hang, temporarily commented out
> # test by trying to run on nonexistent keyspace
> # cluster.stop(gently=False)
> # output, error, rc = node1.run_sstableofflinerelevel("keyspace1",
> "standard1", output=True)
> # assert "java.lang.IllegalArgumentException: Unknown
> keyspace/columnFamily keyspace1.standard1" in error
> # # this should return exit code 1
> # assert rc, 1 == msg=str(rc)
> # cluster.start()
>
> # now test by generating keyspace but not flushing sstables
>
> node1.stress(['write', 'n=1', 'no-warmup',
> '-schema', 'replication(factor=1)',
> '-col', 'n=FIXED(10)', 'SIZE=FIXED(1024)',
> '-rate', 'threads=8'])
>
> cluster.stop(gently=False)
> try:
> output, error, _ = node1.run_sstableofflinerelevel("keyspace1",
> "standard1")
> except ToolError as e:
> assert re.search("No sstables to relevel for
> keyspace1.standard1", e.stdout)
> assert e.exit_status == 1, str(e.exit_status)
>
> # test by flushing (sstable should be level 0)
> cluster.start()
> session = self.patient_cql_connection(node1)
> logger.debug("Altering compaction strategy to LCS")
> > session.execute(
> "ALTER TABLE keyspace1.standard1 with compaction={'class':
> 'LeveledCompactionStrategy', 'sstable_size_in_mb':1, 'enabled':'false'};")
> offline_tools_test.py:147:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042 coordinator_host=None>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
[jira] [Created] (CASSANDRA-19541) Test Failure: test_sstableofflinerelevel
Ekaterina Dimitrova created CASSANDRA-19541:
---
Summary: Test Failure: test_sstableofflinerelevel
Key: CASSANDRA-19541
URL: https://issues.apache.org/jira/browse/CASSANDRA-19541
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
{code:java}
self =
def test_sstableofflinerelevel(self):
"""
Generate sstables of varying levels.
Reset sstables to L0 with sstablelevelreset
Run sstableofflinerelevel and ensure tables are promoted correctly
Also test a variety of bad inputs including nonexistent keyspace and
sstables
@since 2.1.5
@jira_ticket CASSANDRA-8031
"""
cluster = self.cluster
cluster.set_configuration_options(values={'compaction_throughput_mb_per_sec':
0})
cluster.populate(1).start()
node1 = cluster.nodelist()[0]
# NOTE - As of now this does not return when it encounters Exception
and causes test to hang, temporarily commented out
# test by trying to run on nonexistent keyspace
# cluster.stop(gently=False)
# output, error, rc = node1.run_sstableofflinerelevel("keyspace1",
"standard1", output=True)
# assert "java.lang.IllegalArgumentException: Unknown
keyspace/columnFamily keyspace1.standard1" in error
# # this should return exit code 1
# assert rc, 1 == msg=str(rc)
# cluster.start()
# now test by generating keyspace but not flushing sstables
node1.stress(['write', 'n=1', 'no-warmup',
'-schema', 'replication(factor=1)',
'-col', 'n=FIXED(10)', 'SIZE=FIXED(1024)',
'-rate', 'threads=8'])
cluster.stop(gently=False)
try:
output, error, _ = node1.run_sstableofflinerelevel("keyspace1",
"standard1")
except ToolError as e:
assert re.search("No sstables to relevel for keyspace1.standard1",
e.stdout)
assert e.exit_status == 1, str(e.exit_status)
# test by flushing (sstable should be level 0)
cluster.start()
session = self.patient_cql_connection(node1)
logger.debug("Altering compaction strategy to LCS")
> session.execute(
"ALTER TABLE keyspace1.standard1 with compaction={'class':
'LeveledCompactionStrategy', 'sstable_size_in_mb':1, 'enabled':'false'};")
offline_tools_test.py:147:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../env3.8/src/cassandra-driver/cassandra/cluster.py:2618: in execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state, host, execute_as).result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
def result(self):
"""
Return the final result or raise an Exception if errors were
encountered. If the final result or error has not been set
yet, this method will block until it is set, or the timeout
set for the request expires.
Timeout is specified in the Session request execution functions.
If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut` will
be raised.
This is a client-side timeout. For more information
about server-side coordinator timeouts, see
:class:`.policies.RetryPolicy`.
Example usage::
>>> future = session.execute_async("SELECT * FROM mycf")
>>> # do other stuff...
>>> try:
... rows = future.result()
... for row in rows:
... ... # process results
... except Exception:
... log.exception("Operation failed:")
"""
self._event.wait()
if self._final_result is not _NOT_SET:
return ResultSet(self, self._final_result)
else:
> raise self._final_exception
E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
request timeout. See Session.execute[_async](timeout)'},
last_host=127.0.0.1:9042
../env3.8/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
{code}
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19540) Test Failure: test_sstablelevelreset
[
https://issues.apache.org/jira/browse/CASSANDRA-19540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19540:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_sstablelevelreset
>
>
> Key: CASSANDRA-19540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19540
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> {code:java}
> self =
> def test_sstablelevelreset(self):
> """
> Insert data and call sstablelevelreset on a series of
> tables. Confirm level is reset to 0 using its output.
> Test a variety of possible errors and ensure response is resonable.
> @since 2.1.5
> @jira_ticket CASSANDRA-7614
> """
> cluster = self.cluster
> cluster.populate(1).start()
> node1 = cluster.nodelist()[0]
>
> # test by trying to run on nonexistent keyspace
> cluster.stop(gently=False)
> try:
> node1.run_sstablelevelreset("keyspace1", "standard1")
> except ToolError as e:
> assert re.search("ColumnFamily not found: keyspace1/standard1",
> str(e))
> # this should return exit code 1
> assert e.exit_status == 1, "Expected sstablelevelreset to have a
> return code of 1 == but instead return code was {}".format(
> e.exit_status)
>
> # now test by generating keyspace but not flushing sstables
> cluster.start()
> node1.stress(['write', 'n=100', 'no-warmup', '-schema',
> 'replication(factor=1)',
> '-rate', 'threads=8'])
> cluster.stop(gently=False)
>
> output, error, rc = node1.run_sstablelevelreset("keyspace1",
> "standard1")
> self._check_stderr_error(error)
> assert re.search("Found no sstables, did you give the correct
> keyspace", output)
> assert rc == 0, str(rc)
>
> # test by writing small amount of data and flushing (all sstables
> should be level 0)
> cluster.start()
> session = self.patient_cql_connection(node1)
> > session.execute(
> "ALTER TABLE keyspace1.standard1 with compaction={'class':
> 'LeveledCompactionStrategy', 'sstable_size_in_mb':1};")
> offline_tools_test.py:64:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042 coordinator_host=None>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
> request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042
> ../env3.8/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
> test_sstableofflinerelevel
> FLAKY
> offline_tools_test.TestOfflineTools
> test_resumable_decommission
> {code}
>
[jira] [Created] (CASSANDRA-19540) Test Failure: test_sstablelevelreset
Ekaterina Dimitrova created CASSANDRA-19540:
---
Summary: Test Failure: test_sstablelevelreset
Key: CASSANDRA-19540
URL: https://issues.apache.org/jira/browse/CASSANDRA-19540
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Ekaterina Dimitrova
{code:java}
self =
def test_sstablelevelreset(self):
"""
Insert data and call sstablelevelreset on a series of
tables. Confirm level is reset to 0 using its output.
Test a variety of possible errors and ensure response is resonable.
@since 2.1.5
@jira_ticket CASSANDRA-7614
"""
cluster = self.cluster
cluster.populate(1).start()
node1 = cluster.nodelist()[0]
# test by trying to run on nonexistent keyspace
cluster.stop(gently=False)
try:
node1.run_sstablelevelreset("keyspace1", "standard1")
except ToolError as e:
assert re.search("ColumnFamily not found: keyspace1/standard1",
str(e))
# this should return exit code 1
assert e.exit_status == 1, "Expected sstablelevelreset to have a
return code of 1 == but instead return code was {}".format(
e.exit_status)
# now test by generating keyspace but not flushing sstables
cluster.start()
node1.stress(['write', 'n=100', 'no-warmup', '-schema',
'replication(factor=1)',
'-rate', 'threads=8'])
cluster.stop(gently=False)
output, error, rc = node1.run_sstablelevelreset("keyspace1",
"standard1")
self._check_stderr_error(error)
assert re.search("Found no sstables, did you give the correct
keyspace", output)
assert rc == 0, str(rc)
# test by writing small amount of data and flushing (all sstables
should be level 0)
cluster.start()
session = self.patient_cql_connection(node1)
> session.execute(
"ALTER TABLE keyspace1.standard1 with compaction={'class':
'LeveledCompactionStrategy', 'sstable_size_in_mb':1};")
offline_tools_test.py:64:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../env3.8/src/cassandra-driver/cassandra/cluster.py:2618: in execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state, host, execute_as).result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
def result(self):
"""
Return the final result or raise an Exception if errors were
encountered. If the final result or error has not been set
yet, this method will block until it is set, or the timeout
set for the request expires.
Timeout is specified in the Session request execution functions.
If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut` will
be raised.
This is a client-side timeout. For more information
about server-side coordinator timeouts, see
:class:`.policies.RetryPolicy`.
Example usage::
>>> future = session.execute_async("SELECT * FROM mycf")
>>> # do other stuff...
>>> try:
... rows = future.result()
... for row in rows:
... ... # process results
... except Exception:
... log.exception("Operation failed:")
"""
self._event.wait()
if self._final_result is not _NOT_SET:
return ResultSet(self, self._final_result)
else:
> raise self._final_exception
E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
request timeout. See Session.execute[_async](timeout)'},
last_host=127.0.0.1:9042
../env3.8/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
test_sstableofflinerelevel
FLAKY
offline_tools_test.TestOfflineTools
test_resumable_decommission
{code}
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
The failure looks different in Jenkins:
https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/testReport/junit/dtest-latest.offline_tools_test/TestOfflineTools/Tests___dtest_latest_jdk11_35_64___test_sstablelevelreset/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19539) Test Failure: test_bootstrap_with_reset_bootstrap_state
[
https://issues.apache.org/jira/browse/CASSANDRA-19539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19539:
Component/s: Test/dtest/python
> Test Failure: test_bootstrap_with_reset_bootstrap_state
> ---
>
> Key: CASSANDRA-19539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19539
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Failing on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after 180.22/180
> seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> Head: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> Tail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when sending
> TCM_COMMIT_REQ, retrying on CandidateIterator{candidates=[/127.0.0.1:7000],
> checkLive=true}
> self =
> @since('2.2')
> def test_bootstrap_with_reset_bootstrap_state(self):
> """Test bootstrap with resetting bootstrap progress"""
> cluster = self.cluster
>
> cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
> 'True')
>
> cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
> 1})
> cluster.populate(2).start()
>
> node1 = cluster.nodes['node1']
> node1.stress(['write', 'n=100K', '-schema', 'replication(factor=2)'])
> node1.flush()
>
> # kill node1 in the middle of streaming to let it fail
> t = InterruptBootstrap(node1)
> t.start()
>
> # start bootstrapping node3 and wait for streaming
> node3 = new_node(cluster)
> try:
> node3.start()
> except NodeError:
> pass # node doesn't start as expected
> t.join()
> node1.start()
>
> # restart node3 bootstrap with resetting bootstrap progress
> node3.stop(signal_event=signal.SIGKILL)
> mark = node3.mark_log()
> node3.start(jvm_args=["-Dcassandra.reset_bootstrap_progress=true"])
> # check if we reset bootstrap state
> node3.watch_log_for("Resetting bootstrap progress to start fresh",
> from_mark=mark)
> # wait for node3 ready to query, 180s as the node needs to bootstrap
> > node3.wait_for_binary_interface(from_mark=mark, timeout=180)
> bootstrap_test.py:513:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:709: in
> wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173092.936025, timeout = 180
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\n Head: INFO [main] 2024-04-03 19:37:59,845...00: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}\n"
> node = 'node3'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after
> 180.22/180 seconds Missing: ['Starting listening for CQL clients'] not found
> in system.log:
> EHead: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> ETail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19538) Test Failure: test_assassinate_valid_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19538:
Component/s: Test/dtest/python
> Test Failure: test_assassinate_valid_node
> -
>
> Key: CASSANDRA-19538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Failing consistently on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120
> seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> Tail: ... some nodes were not ready
> INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484
> - Setup task failed with error, rescheduling
> self =
> def test_assassinate_valid_node(self):
> """
> @jira_ticket CASSANDRA-16588
> Test that after taking two non-seed nodes down and assassinating
> one of them, the other can come back up.
> """
> cluster = self.cluster
>
> cluster.populate(5).start()
> node1 = cluster.nodelist()[0]
> node3 = cluster.nodelist()[2]
>
> self.cluster.set_configuration_options({
> 'seed_provider': [{'class_name':
> 'org.apache.cassandra.locator.SimpleSeedProvider',
>'parameters': [{'seeds': node1.address()}]
> }]
> })
>
> non_seed_nodes = cluster.nodelist()[-2:]
> for node in non_seed_nodes:
> node.stop()
>
> assassination_target = non_seed_nodes[0]
> logger.debug("Assassinating non-seed node
> {}".format(assassination_target.address()))
> out, err, _ = node1.nodetool("assassinate
> {}".format(assassination_target.address()))
> assert_stderr_clean(err)
>
> logger.debug("Starting non-seed nodes")
> for node in non_seed_nodes:
> > node.start()
> gossip_test.py:78:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
> node.watch_log_for_alive(self, from_mark=mark)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in
> watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173052.8186479, timeout = 120
> msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1]
> 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 - Setup task failed
> with error, rescheduling\n"
> node = 'node1'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
> 120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
> system.log:
> EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> ETail: ... some nodes were not ready
> E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
> CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19539) Test Failure: test_bootstrap_with_reset_bootstrap_state
[
https://issues.apache.org/jira/browse/CASSANDRA-19539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19539:
Fix Version/s: 5.x
> Test Failure: test_bootstrap_with_reset_bootstrap_state
> ---
>
> Key: CASSANDRA-19539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19539
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Failing on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after 180.22/180
> seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> Head: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> Tail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when sending
> TCM_COMMIT_REQ, retrying on CandidateIterator{candidates=[/127.0.0.1:7000],
> checkLive=true}
> self =
> @since('2.2')
> def test_bootstrap_with_reset_bootstrap_state(self):
> """Test bootstrap with resetting bootstrap progress"""
> cluster = self.cluster
>
> cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
> 'True')
>
> cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
> 1})
> cluster.populate(2).start()
>
> node1 = cluster.nodes['node1']
> node1.stress(['write', 'n=100K', '-schema', 'replication(factor=2)'])
> node1.flush()
>
> # kill node1 in the middle of streaming to let it fail
> t = InterruptBootstrap(node1)
> t.start()
>
> # start bootstrapping node3 and wait for streaming
> node3 = new_node(cluster)
> try:
> node3.start()
> except NodeError:
> pass # node doesn't start as expected
> t.join()
> node1.start()
>
> # restart node3 bootstrap with resetting bootstrap progress
> node3.stop(signal_event=signal.SIGKILL)
> mark = node3.mark_log()
> node3.start(jvm_args=["-Dcassandra.reset_bootstrap_progress=true"])
> # check if we reset bootstrap state
> node3.watch_log_for("Resetting bootstrap progress to start fresh",
> from_mark=mark)
> # wait for node3 ready to query, 180s as the node needs to bootstrap
> > node3.wait_for_binary_interface(from_mark=mark, timeout=180)
> bootstrap_test.py:513:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:709: in
> wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173092.936025, timeout = 180
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\n Head: INFO [main] 2024-04-03 19:37:59,845...00: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}\n"
> node = 'node3'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after
> 180.22/180 seconds Missing: ['Starting listening for CQL clients'] not found
> in system.log:
> EHead: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> ETail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19539) Test Failure: test_bootstrap_with_reset_bootstrap_state
[
https://issues.apache.org/jira/browse/CASSANDRA-19539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19539:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_bootstrap_with_reset_bootstrap_state
> ---
>
> Key: CASSANDRA-19539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19539
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Failing on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after 180.22/180
> seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> Head: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> Tail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when sending
> TCM_COMMIT_REQ, retrying on CandidateIterator{candidates=[/127.0.0.1:7000],
> checkLive=true}
> self =
> @since('2.2')
> def test_bootstrap_with_reset_bootstrap_state(self):
> """Test bootstrap with resetting bootstrap progress"""
> cluster = self.cluster
>
> cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
> 'True')
>
> cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
> 1})
> cluster.populate(2).start()
>
> node1 = cluster.nodes['node1']
> node1.stress(['write', 'n=100K', '-schema', 'replication(factor=2)'])
> node1.flush()
>
> # kill node1 in the middle of streaming to let it fail
> t = InterruptBootstrap(node1)
> t.start()
>
> # start bootstrapping node3 and wait for streaming
> node3 = new_node(cluster)
> try:
> node3.start()
> except NodeError:
> pass # node doesn't start as expected
> t.join()
> node1.start()
>
> # restart node3 bootstrap with resetting bootstrap progress
> node3.stop(signal_event=signal.SIGKILL)
> mark = node3.mark_log()
> node3.start(jvm_args=["-Dcassandra.reset_bootstrap_progress=true"])
> # check if we reset bootstrap state
> node3.watch_log_for("Resetting bootstrap progress to start fresh",
> from_mark=mark)
> # wait for node3 ready to query, 180s as the node needs to bootstrap
> > node3.wait_for_binary_interface(from_mark=mark, timeout=180)
> bootstrap_test.py:513:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:709: in
> wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173092.936025, timeout = 180
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\n Head: INFO [main] 2024-04-03 19:37:59,845...00: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}\n"
> node = 'node3'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after
> 180.22/180 seconds Missing: ['Starting listening for CQL clients'] not found
> in system.log:
> EHead: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> ETail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19539) Test Failure: test_bootstrap_with_reset_bootstrap_state
Ekaterina Dimitrova created CASSANDRA-19539:
---
Summary: Test Failure: test_bootstrap_with_reset_bootstrap_state
Key: CASSANDRA-19539
URL: https://issues.apache.org/jira/browse/CASSANDRA-19539
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Failing on trunk:
{code:java}
ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after 180.22/180 seconds
Missing: ['Starting listening for CQL clients'] not found in system.log:
Head: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
Tail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when sending
TCM_COMMIT_REQ, retrying on CandidateIterator{candidates=[/127.0.0.1:7000],
checkLive=true}
self =
@since('2.2')
def test_bootstrap_with_reset_bootstrap_state(self):
"""Test bootstrap with resetting bootstrap progress"""
cluster = self.cluster
cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
'True')
cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
1})
cluster.populate(2).start()
node1 = cluster.nodes['node1']
node1.stress(['write', 'n=100K', '-schema', 'replication(factor=2)'])
node1.flush()
# kill node1 in the middle of streaming to let it fail
t = InterruptBootstrap(node1)
t.start()
# start bootstrapping node3 and wait for streaming
node3 = new_node(cluster)
try:
node3.start()
except NodeError:
pass # node doesn't start as expected
t.join()
node1.start()
# restart node3 bootstrap with resetting bootstrap progress
node3.stop(signal_event=signal.SIGKILL)
mark = node3.mark_log()
node3.start(jvm_args=["-Dcassandra.reset_bootstrap_progress=true"])
# check if we reset bootstrap state
node3.watch_log_for("Resetting bootstrap progress to start fresh",
from_mark=mark)
# wait for node3 ready to query, 180s as the node needs to bootstrap
> node3.wait_for_binary_interface(from_mark=mark, timeout=180)
bootstrap_test.py:513:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:709: in
wait_for_binary_interface
self.watch_log_for("Starting listening for CQL clients", **kwargs)
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
start = 1712173092.936025, timeout = 180
msg = "Missing: ['Starting listening for CQL clients'] not found in
system.log:\n Head: INFO [main] 2024-04-03 19:37:59,845...00: TIMEOUT when
sending TCM_COMMIT_REQ, retrying on
CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}\n"
node = 'node3'
@staticmethod
def raise_if_passed(start, timeout, msg, node=None):
if start + timeout < time.time():
> raise TimeoutError.create(start, timeout, msg, node)
E ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after
180.22/180 seconds Missing: ['Starting listening for CQL clients'] not found in
system.log:
EHead: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
ETail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when sending
TCM_COMMIT_REQ, retrying on CandidateIterator{candidates=[/127.0.0.1:7000],
checkLive=true}
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
{code}
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19538) Test Failure: test_assassinate_valid_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19538:
Fix Version/s: 5.x
> Test Failure: test_assassinate_valid_node
> -
>
> Key: CASSANDRA-19538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Failing consistently on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120
> seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> Tail: ... some nodes were not ready
> INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484
> - Setup task failed with error, rescheduling
> self =
> def test_assassinate_valid_node(self):
> """
> @jira_ticket CASSANDRA-16588
> Test that after taking two non-seed nodes down and assassinating
> one of them, the other can come back up.
> """
> cluster = self.cluster
>
> cluster.populate(5).start()
> node1 = cluster.nodelist()[0]
> node3 = cluster.nodelist()[2]
>
> self.cluster.set_configuration_options({
> 'seed_provider': [{'class_name':
> 'org.apache.cassandra.locator.SimpleSeedProvider',
>'parameters': [{'seeds': node1.address()}]
> }]
> })
>
> non_seed_nodes = cluster.nodelist()[-2:]
> for node in non_seed_nodes:
> node.stop()
>
> assassination_target = non_seed_nodes[0]
> logger.debug("Assassinating non-seed node
> {}".format(assassination_target.address()))
> out, err, _ = node1.nodetool("assassinate
> {}".format(assassination_target.address()))
> assert_stderr_clean(err)
>
> logger.debug("Starting non-seed nodes")
> for node in non_seed_nodes:
> > node.start()
> gossip_test.py:78:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
> node.watch_log_for_alive(self, from_mark=mark)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in
> watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173052.8186479, timeout = 120
> msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1]
> 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 - Setup task failed
> with error, rescheduling\n"
> node = 'node1'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
> 120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
> system.log:
> EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> ETail: ... some nodes were not ready
> E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
> CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19538) Test Failure: test_assassinate_valid_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19538:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_assassinate_valid_node
> -
>
> Key: CASSANDRA-19538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Failing consistently on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120
> seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> Tail: ... some nodes were not ready
> INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484
> - Setup task failed with error, rescheduling
> self =
> def test_assassinate_valid_node(self):
> """
> @jira_ticket CASSANDRA-16588
> Test that after taking two non-seed nodes down and assassinating
> one of them, the other can come back up.
> """
> cluster = self.cluster
>
> cluster.populate(5).start()
> node1 = cluster.nodelist()[0]
> node3 = cluster.nodelist()[2]
>
> self.cluster.set_configuration_options({
> 'seed_provider': [{'class_name':
> 'org.apache.cassandra.locator.SimpleSeedProvider',
>'parameters': [{'seeds': node1.address()}]
> }]
> })
>
> non_seed_nodes = cluster.nodelist()[-2:]
> for node in non_seed_nodes:
> node.stop()
>
> assassination_target = non_seed_nodes[0]
> logger.debug("Assassinating non-seed node
> {}".format(assassination_target.address()))
> out, err, _ = node1.nodetool("assassinate
> {}".format(assassination_target.address()))
> assert_stderr_clean(err)
>
> logger.debug("Starting non-seed nodes")
> for node in non_seed_nodes:
> > node.start()
> gossip_test.py:78:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
> node.watch_log_for_alive(self, from_mark=mark)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in
> watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173052.8186479, timeout = 120
> msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1]
> 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 - Setup task failed
> with error, rescheduling\n"
> node = 'node1'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
> 120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
> system.log:
> EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> ETail: ... some nodes were not ready
> E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
> CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19538) Test Failure: test_assassinate_valid_node
Ekaterina Dimitrova created CASSANDRA-19538:
---
Summary: Test Failure: test_assassinate_valid_node
Key: CASSANDRA-19538
URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Failing consistently on trunk:
{code:java}
ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120 seconds
Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
Tail: ... some nodes were not ready
INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 -
Setup task failed with error, rescheduling
self =
def test_assassinate_valid_node(self):
"""
@jira_ticket CASSANDRA-16588
Test that after taking two non-seed nodes down and assassinating
one of them, the other can come back up.
"""
cluster = self.cluster
cluster.populate(5).start()
node1 = cluster.nodelist()[0]
node3 = cluster.nodelist()[2]
self.cluster.set_configuration_options({
'seed_provider': [{'class_name':
'org.apache.cassandra.locator.SimpleSeedProvider',
'parameters': [{'seeds': node1.address()}]
}]
})
non_seed_nodes = cluster.nodelist()[-2:]
for node in non_seed_nodes:
node.stop()
assassination_target = non_seed_nodes[0]
logger.debug("Assassinating non-seed node
{}".format(assassination_target.address()))
out, err, _ = node1.nodetool("assassinate
{}".format(assassination_target.address()))
assert_stderr_clean(err)
logger.debug("Starting non-seed nodes")
for node in non_seed_nodes:
> node.start()
gossip_test.py:78:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
node.watch_log_for_alive(self, from_mark=mark)
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in watch_log_for_alive
self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
filename=filename)
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
start = 1712173052.8186479, timeout = 120
msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n Head:
INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1] 2024-04-03
19:39:30,454 CassandraRoleManager.java:484 - Setup task failed with error,
rescheduling\n"
node = 'node1'
@staticmethod
def raise_if_passed(start, timeout, msg, node=None):
if start + timeout < time.time():
> raise TimeoutError.create(start, timeout, msg, node)
E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
system.log:
EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
ETail: ... some nodes were not ready
E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
{code}
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833770#comment-17833770 ] Ekaterina Dimitrova commented on CASSANDRA-19428: - Tickets opened and linked here: !https://issues.apache.org/jira/secure/viewavatar?size=xsmall=21133=issuetype|width=16,height=16! CASSANDRA-19522 Test Failure: test_simple_decommission !https://issues.apache.org/jira/secure/viewavatar?size=xsmall=21133=issuetype|width=16,height=16! CASSANDRA-19523 Test Failure: testMixedVersionBlockDecom !https://issues.apache.org/jira/secure/viewavatar?size=xsmall=21133=issuetype|width=16,height=16! CASSANDRA-19524 Test Failure: testIncompleteState > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-beta2, 5.1-alpha, 5.1 > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19524) Test Failure: testIncompleteState
[
https://issues.apache.org/jira/browse/CASSANDRA-19524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19524:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: testIncompleteState
> -
>
> Key: CASSANDRA-19524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19524
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58956/tests#failed-test-0]
> {code:java}
> junit.framework.AssertionFailedError at
> org.apache.cassandra.gms.NewGossiperTest.testIncompleteState(NewGossiperTest.java:141)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19524) Test Failure: testIncompleteState
[
https://issues.apache.org/jira/browse/CASSANDRA-19524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19524:
Fix Version/s: 5.x
> Test Failure: testIncompleteState
> -
>
> Key: CASSANDRA-19524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19524
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58956/tests#failed-test-0]
> {code:java}
> junit.framework.AssertionFailedError at
> org.apache.cassandra.gms.NewGossiperTest.testIncompleteState(NewGossiperTest.java:141)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19524) Test Failure: testIncompleteState
Ekaterina Dimitrova created CASSANDRA-19524:
---
Summary: Test Failure: testIncompleteState
Key: CASSANDRA-19524
URL: https://issues.apache.org/jira/browse/CASSANDRA-19524
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58956/tests#failed-test-0]
{code:java}
junit.framework.AssertionFailedError at
org.apache.cassandra.gms.NewGossiperTest.testIncompleteState(NewGossiperTest.java:141)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19523) Test Failure: testMixedVersionBlockDecom
[
https://issues.apache.org/jira/browse/CASSANDRA-19523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19523:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: testMixedVersionBlockDecom
>
>
> Key: CASSANDRA-19523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19523
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58954/tests#failed-test-0]
> {code:java}
> java.lang.RuntimeException: java.util.concurrent.TimeoutException at
> org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79) at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:546) at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
> at
> org.apache.cassandra.distributed.test.ring.DecommissionTest.testMixedVersionBlockDecom(DecommissionTest.java:173)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.util.concurrent.TimeoutException at
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:538){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19523) Test Failure: testMixedVersionBlockDecom
[
https://issues.apache.org/jira/browse/CASSANDRA-19523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19523:
Fix Version/s: 5.x
> Test Failure: testMixedVersionBlockDecom
>
>
> Key: CASSANDRA-19523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19523
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58954/tests#failed-test-0]
> {code:java}
> java.lang.RuntimeException: java.util.concurrent.TimeoutException at
> org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79) at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:546) at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
> at
> org.apache.cassandra.distributed.test.ring.DecommissionTest.testMixedVersionBlockDecom(DecommissionTest.java:173)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.util.concurrent.TimeoutException at
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:538){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19523) Test Failure: testMixedVersionBlockDecom
Ekaterina Dimitrova created CASSANDRA-19523:
---
Summary: Test Failure: testMixedVersionBlockDecom
Key: CASSANDRA-19523
URL: https://issues.apache.org/jira/browse/CASSANDRA-19523
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58954/tests#failed-test-0]
{code:java}
java.lang.RuntimeException: java.util.concurrent.TimeoutException at
org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79) at
org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:546) at
org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
at
org.apache.cassandra.distributed.test.ring.DecommissionTest.testMixedVersionBlockDecom(DecommissionTest.java:173)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Caused by: java.util.concurrent.TimeoutException at
org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
at
org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:538){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19522) Test Failure: test_simple_decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19522:
Fix Version/s: 5.x
> Test Failure: test_simple_decommission
> --
>
> Key: CASSANDRA-19522
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19522
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Locally it fails for me:
> test_simple_decommission failed; it passed 0 out of the required 1 times.
>
> Subprocess ['nodetool', '-h', 'localhost', '-p', '7200', 'decommission']
> exited with non-zero status; exit status: 1;
> stdout: nodetool: Can not commit transformation: "INVALID"(Not enough live
> nodes to maintain replication factor after decommission.).
> See 'nodetool help' or 'nodetool help '.
> It failed in CircleCI in a different way once and I cannot reproduce it
> anymore in CircleCI. It passed many times there:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-5]
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [GossipTasks:1] 2024-04-03
> 19:44:52,473 MessagingService.java:501 - Cannot send the message
> (from:/127.0.0.2:7000, type:GOSSIP verb:GOSSIP_DIGEST_SYN) to
> /127.0.0.1:7000, as messaging service is shutting down']" Unexpected error
> found in node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [GossipTasks:1] 2024-04-03 19:44:52,473 MessagingService.java:501 - Cannot
> send the message (from:/127.0.0.2:7000, type:GOSSIP verb:GOSSIP_DIGEST_SYN)
> to /127.0.0.1:7000, as messaging service is shutting down']{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19522) Test Failure: test_simple_decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19522:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_simple_decommission
> --
>
> Key: CASSANDRA-19522
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19522
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Locally it fails for me:
> test_simple_decommission failed; it passed 0 out of the required 1 times.
>
> Subprocess ['nodetool', '-h', 'localhost', '-p', '7200', 'decommission']
> exited with non-zero status; exit status: 1;
> stdout: nodetool: Can not commit transformation: "INVALID"(Not enough live
> nodes to maintain replication factor after decommission.).
> See 'nodetool help' or 'nodetool help '.
> It failed in CircleCI in a different way once and I cannot reproduce it
> anymore in CircleCI. It passed many times there:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-5]
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [GossipTasks:1] 2024-04-03
> 19:44:52,473 MessagingService.java:501 - Cannot send the message
> (from:/127.0.0.2:7000, type:GOSSIP verb:GOSSIP_DIGEST_SYN) to
> /127.0.0.1:7000, as messaging service is shutting down']" Unexpected error
> found in node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [GossipTasks:1] 2024-04-03 19:44:52,473 MessagingService.java:501 - Cannot
> send the message (from:/127.0.0.2:7000, type:GOSSIP verb:GOSSIP_DIGEST_SYN)
> to /127.0.0.1:7000, as messaging service is shutting down']{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
