[jira] [Commented] (CASSANDRA-19637) LWT conditions on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847362#comment-17847362
]
Benjamin Lerer commented on CASSANDRA-19637:
[~dcapwell] did you try with an unfrozen collection ?
> LWT conditions on MultiCell collections return invalid results
> --
>
> 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
>
> Due to the way multicell 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 multicell 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 multicell 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-19637) LWT conditions on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846979#comment-17846979
]
Benjamin Lerer commented on CASSANDRA-19637:
[~maedhroz] You might be interested about that one for Accord.
> LWT conditions on MultiCell collections return invalid results
> --
>
> 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
>
> Due to the way multicell 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 multicell 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 multicell 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 on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: Code Inspection
Severity: Low
Assignee: Benjamin Lerer
Status: Open (was: Triage Needed)
> LWT conditions on MultiCell collections return invalid results
> --
>
> 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
>
> Due to the way multicell 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 multicell 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 multicell 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 on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Description:
Due to the way multicell 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 multicell 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 multicell collection input as {{null}} and reject the {{null}}
input for non {{=}} and {{!=}} operators.
was:
Due to the way multicell 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 multicell 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 multicell collection input as {{null}} and reject the {{null}}
input for non {{=}} and {{!=}} operator.
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell 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 multicell 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 multicell 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 on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Description:
Due to the way multicell 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 multicell 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 multicell collection input as {{null}} and reject the {{null}}
input for non {{=}} and {{!=}} operator.
was:
Due to the way multicell 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 multicell 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 multicell collection input as {{null}}.
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell 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 multicell 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 multicell collection input as {{null}} and reject the
> {{null}} input for non {{=}} and {{!=}} 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] [Updated] (CASSANDRA-19637) LWT conditions on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Description:
Due to the way multicell 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 multicell 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 multicell collection input as {{null}}.
was:
Due to the way multicell 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 multicell 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 like
is to consider empty multicell collection input as {{null}}.
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell 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 multicell 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 multicell collection input as {{null}}.
>
--
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 on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Description:
Due to the way multicell 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 multicell 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 {false, null}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations like
is to consider empty multicell collection input as {{null}}.
was:
Due to the way multicell 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 multicell 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 en 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 {false, null}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations like
is to consider empty multicell collection input as {{null}}.
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell 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 multicell 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 {false, null}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations
> like is to consider empty multicell collection input as {{null}}.
>
--
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 on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Description:
Due to the way multicell 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 multicell 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 like
is to consider empty multicell collection input as {{null}}.
was:
Due to the way multicell 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 multicell 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 {false, null}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations like
is to consider empty multicell collection input as {{null}}.
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell 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 multicell 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
> like is to consider empty multicell collection input as {{null}}.
>
--
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-19637) LWT conditions on MultiCell collections return invalid results
Benjamin Lerer created CASSANDRA-19637:
--
Summary: LWT conditions on MultiCell collections return invalid
results
Key: CASSANDRA-19637
URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
Project: Cassandra
Issue Type: Bug
Components: CQL/Semantics
Reporter: Benjamin Lerer
Due to the way multicell 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 multicell 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 en 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 {false, null}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations like
is to consider empty multicell collection input as {{null}}.
--
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
]
Benjamin Lerer updated CASSANDRA-19604:
---
Test and Documentation Plan: The patch add unit tests that cover the new
functionality.
Status: Patch Available (was: In Progress)
> 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: 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-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:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19341:
---
Source Control Link:
https://github.com/apache/cassandra/commit/534da538d229a5b4fc1d9ef7cc8b37ead455191c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Patch committed into trunk at 534da538d229a5b4fc1d9ef7cc8b37ead455191c.
DTest committed into the trunk branch at
6dd7def99467952d1df6a451d2e74861cf6599de
> 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-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:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19341:
---
Fix Version/s: 5.1
(was: 5.x)
> 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-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:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19341:
---
Status: Ready to Commit (was: Review In Progress)
> 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: 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-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:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19341:
---
Summary: Relation and Restriction hierarchies are too complex and error
prone (was: Relation and Restriction hierachies are too complex and error
prone)
> 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] [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=17842563#comment-17842563
]
Benjamin Lerer edited comment on CASSANDRA-19604 at 5/1/24 7:20 AM:
Mentor: [~blerer], [~e.dimitrova]
was (Author: blerer):
Mentor: [~blerer], [~edimitrova]
> 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).
> +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
]
Benjamin Lerer updated CASSANDRA-19604:
---
Change Category: Semantic
Complexity: Normal
Reviewers: Benjamin Lerer, Ekaterina Dimitrova
Status: Open (was: Triage Needed)
Mentor: [~blerer], [~edimitrova]
> 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).
> +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] [Created] (CASSANDRA-19604) Add support for BETWEEN operator
Benjamin Lerer created CASSANDRA-19604:
--
Summary: 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
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).
+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-19556) Guardrail to block DDL/DCL queries
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842318#comment-17842318 ] Benjamin Lerer commented on CASSANDRA-19556: I agree that having the methods in the base classes make sense. :-) > Guardrail to block DDL/DCL queries > -- > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- 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
]
Benjamin Lerer updated CASSANDRA-19341:
---
Test and Documentation Plan: The patch adds new tests for some of the new
classes and relies on existing tests to validate the changes.
Status: Patch Available (was: Open)
CI results:
[J11|https://app.circleci.com/pipelines/github/blerer/cassandra/390/workflows/7c475c9c-9936-4def-9ec5-936859cfcc21],
[J17|https://app.circleci.com/pipelines/github/blerer/cassandra/390/workflows/2655f762-5fba-45ef-946e-5db7637873a4]
DTests changes: https://github.com/apache/cassandra-dtest/pull/259
> 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: 20m
> 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
]
Benjamin Lerer updated CASSANDRA-19341:
---
Change Category: Code Clarity
Complexity: Normal
Status: Open (was: Triage Needed)
> 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: 10m
> 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
> chirurgical 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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-19417: --- Status: Review In Progress (was: Needs Committer) > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-19417: --- Status: Ready to Commit (was: Review In Progress) > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826013#comment-17826013 ] Benjamin Lerer commented on CASSANDRA-19417: Yes, I was +1 on the patch as long as the nits were addressed and CI looked good. We can commit. > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824313#comment-17824313 ] Benjamin Lerer commented on CASSANDRA-19417: The patch looks good to me. Outside of the nits that were raised. We would also need a CI run. > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- 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-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
]
Benjamin Lerer reassigned CASSANDRA-19341:
--
Assignee: Benjamin Lerer
> 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
>
> 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
> chirurgical 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] [Created] (CASSANDRA-19341) Relation and Restriction hierachies are too complex and error prone
Benjamin Lerer created CASSANDRA-19341:
--
Summary: 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
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
chirurgical 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-18584) CEP-29: NOT operator
[ https://issues.apache.org/jira/browse/CASSANDRA-18584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810974#comment-17810974 ] Benjamin Lerer commented on CASSANDRA-18584: 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. I believe that this refactoring would also simplify the current patch. I have not opened a ticket yet but I will. > 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] [Updated] (CASSANDRA-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18813:
---
Source Control Link:
https://github.com/apache/cassandra/commit/34fa4e279ac136d6e673be9540b9f322f414bf7f
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into trunk at 34fa4e279ac136d6e673be9540b9f322f414bf7f
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 8.5h
> Remaining Estimate: 0h
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
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-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18813:
---
Status: Ready to Commit (was: Review In Progress)
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 8.5h
> Remaining Estimate: 0h
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
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-19050) Enhanced usage of test method names in CQLTester for better test debugging
[
https://issues.apache.org/jira/browse/CASSANDRA-19050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807668#comment-17807668
]
Benjamin Lerer commented on CASSANDRA-19050:
The patches look good to me.
> Enhanced usage of test method names in CQLTester for better test debugging
> --
>
> Key: CASSANDRA-19050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19050
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> All views, tables, ks,... created in CQLTester are of the form {{table_00}}:
> - While debugging tests and flakies this makes it really hard to match logs
> to test methods.
> - Some async operations can spill log lines from a previous test method into
> the next's log lines which is incredibly confusing
> - It's hard on the eyes and easy to mix up
> - When comparing logs from 2 different branches, envs,... it's really hard to
> match logs
> The proposed solution is for {{CQLTester}} to decorate these with the test
> name.
--
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-19050) Enhanced usage of test method names in CQLTester for better test debugging
[
https://issues.apache.org/jira/browse/CASSANDRA-19050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805577#comment-17805577
]
Benjamin Lerer commented on CASSANDRA-19050:
The patch had a minor issue. The new version is
[here|https://github.com/blerer/cassandra/commit/a650fbce6a5092bc9004ca47fe25a424623b1d6e].
The unit test run is
[green|https://app.circleci.com/pipelines/github/blerer/cassandra/370/workflows/8fbcb82b-a5c4-4ac8-baf7-e54909209eaa].
> Enhanced usage of test method names in CQLTester for better test debugging
> --
>
> Key: CASSANDRA-19050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19050
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> All views, tables, ks,... created in CQLTester are of the form {{table_00}}:
> - While debugging tests and flakies this makes it really hard to match logs
> to test methods.
> - Some async operations can spill log lines from a previous test method into
> the next's log lines which is incredibly confusing
> - It's hard on the eyes and easy to mix up
> - When comparing logs from 2 different branches, envs,... it's really hard to
> match logs
> The proposed solution is for {{CQLTester}} to decorate these with the test
> name.
--
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-19050) Enhanced usage of test method names in CQLTester for better test debugging
[
https://issues.apache.org/jira/browse/CASSANDRA-19050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805499#comment-17805499
]
Benjamin Lerer edited comment on CASSANDRA-19050 at 1/11/24 10:44 AM:
--
I updated the patch to deal with that
[here|https://github.com/blerer/cassandra/commit/f41c39f4ca7c29d602b56ce2296632a853c7fe7c].
Another option would have been to switch to a 3 digits approach.
was (Author: blerer):
I updated the patch to deal with that. Another option would have been to switch
to a 3 digits approach.
> Enhanced usage of test method names in CQLTester for better test debugging
> --
>
> Key: CASSANDRA-19050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19050
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> All views, tables, ks,... created in CQLTester are of the form {{table_00}}:
> - While debugging tests and flakies this makes it really hard to match logs
> to test methods.
> - Some async operations can spill log lines from a previous test method into
> the next's log lines which is incredibly confusing
> - It's hard on the eyes and easy to mix up
> - When comparing logs from 2 different branches, envs,... it's really hard to
> match logs
> The proposed solution is for {{CQLTester}} to decorate these with the test
> name.
--
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-19050) Enhanced usage of test method names in CQLTester for better test debugging
[
https://issues.apache.org/jira/browse/CASSANDRA-19050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805499#comment-17805499
]
Benjamin Lerer edited comment on CASSANDRA-19050 at 1/11/24 10:45 AM:
--
I updated the patch to deal with that
[here|https://github.com/blerer/cassandra/commit/f41c39f4ca7c29d602b56ce2296632a853c7fe7c].
Another option would have been to switch to a 3 digits approach.
[CI|https://app.circleci.com/pipelines/github/blerer/cassandra/369/workflows/1bc6228e-27de-4a5d-aca5-317e2fdd3a39]
was (Author: blerer):
I updated the patch to deal with that
[here|https://github.com/blerer/cassandra/commit/f41c39f4ca7c29d602b56ce2296632a853c7fe7c].
Another option would have been to switch to a 3 digits approach.
> Enhanced usage of test method names in CQLTester for better test debugging
> --
>
> Key: CASSANDRA-19050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19050
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> All views, tables, ks,... created in CQLTester are of the form {{table_00}}:
> - While debugging tests and flakies this makes it really hard to match logs
> to test methods.
> - Some async operations can spill log lines from a previous test method into
> the next's log lines which is incredibly confusing
> - It's hard on the eyes and easy to mix up
> - When comparing logs from 2 different branches, envs,... it's really hard to
> match logs
> The proposed solution is for {{CQLTester}} to decorate these with the test
> name.
--
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-19050) Enhanced usage of test method names in CQLTester for better test debugging
[
https://issues.apache.org/jira/browse/CASSANDRA-19050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805244#comment-17805244
]
Benjamin Lerer commented on CASSANDRA-19050:
[~bereng] I posted my suggestion
[here|https://github.com/blerer/cassandra/commit/3b32229b2bb0d8aaa7ed1a676e9d453d203f212c].
Ignore the change to the {{java.util}} imports.
> Enhanced usage of test method names in CQLTester for better test debugging
> --
>
> Key: CASSANDRA-19050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19050
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> All views, tables, ks,... created in CQLTester are of the form {{table_00}}:
> - While debugging tests and flakies this makes it really hard to match logs
> to test methods.
> - Some async operations can spill log lines from a previous test method into
> the next's log lines which is incredibly confusing
> - It's hard on the eyes and easy to mix up
> - When comparing logs from 2 different branches, envs,... it's really hard to
> match logs
> The proposed solution is for {{CQLTester}} to decorate these with the test
> name.
--
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-19050) Enhanced usage of test method names in CQLTester for better test debugging
[
https://issues.apache.org/jira/browse/CASSANDRA-19050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790572#comment-17790572
]
Benjamin Lerer commented on CASSANDRA-19050:
I had a talk with [~bereng] as I would like to propose a different approach for
the patch today or tomorrow.
> Enhanced usage of test method names in CQLTester for better test debugging
> --
>
> Key: CASSANDRA-19050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19050
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> All views, tables, ks,... created in CQLTester are of the form {{table_00}}:
> - While debugging tests and flakies this makes it really hard to match logs
> to test methods.
> - Some async operations can spill log lines from a previous test method into
> the next's log lines which is incredibly confusing
> - It's hard on the eyes and easy to mix up
> - When comparing logs from 2 different branches, envs,... it's really hard to
> match logs
> The proposed solution is for {{CQLTester}} to decorate these with the test
> name.
--
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-19034) SelectTest fails when run with SAI index
[
https://issues.apache.org/jira/browse/CASSANDRA-19034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19034:
---
Fix Version/s: 5.0-beta
(was: 5.0-rc)
> SelectTest fails when run with SAI index
>
>
> Key: CASSANDRA-19034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19034
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Branimir Lambov
>Priority: Normal
> Fix For: 5.0-beta
>
>
> When run with SAI index, the following two tests error out:
> {code}
> [junit-timeout] Testcase:
> testContainsKeyAndContainsWithIndexOnMapValue(org.apache.cassandra.cql3.validation.operations.SelectTest)-_jdk11:
>FAILED
> [junit-timeout] Got less rows than expected. Expected 1 but got 0
> [junit-timeout] junit.framework.AssertionFailedError: Got less rows than
> expected. Expected 1 but got 0
> [junit-timeout] at
> org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1849)
> [junit-timeout] at
> org.apache.cassandra.cql3.validation.operations.SelectTest.lambda$testContainsKeyAndContainsWithIndexOnMapValue$9(SelectTest.java:625)
> [junit-timeout] at
> org.apache.cassandra.cql3.CQLTester.beforeAndAfterFlush(CQLTester.java:2238)
> [junit-timeout] at
> org.apache.cassandra.cql3.validation.operations.SelectTest.testContainsKeyAndContainsWithIndexOnMapValue(SelectTest.java:618)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Testcase:
> testFilterWithIndexForContains(org.apache.cassandra.cql3.validation.operations.SelectTest)-_jdk11:
> FAILED
> [junit-timeout] Invalid value for row 1 column 0 (k1 of type int), expected
> <1> but got <0>
> [junit-timeout] Invalid value for row 1 column 2 (v of type set),
> expected <{4, 5, 6}> but got <{2, 3, 4}>
> [junit-timeout]
> [junit-timeout] junit.framework.AssertionFailedError: Invalid value for row 1
> column 0 (k1 of type int), expected <1> but got <0>
> [junit-timeout] Invalid value for row 1 column 2 (v of type set),
> expected <{4, 5, 6}> but got <{2, 3, 4}>
> [junit-timeout]
> [junit-timeout] at
> org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1826)
> [junit-timeout] at
> org.apache.cassandra.cql3.validation.operations.SelectTest.lambda$testFilterWithIndexForContains$6(SelectTest.java:543)
> [junit-timeout] at
> org.apache.cassandra.cql3.CQLTester.beforeAndAfterFlush(CQLTester.java:2240)
> [junit-timeout] at
> org.apache.cassandra.cql3.validation.operations.SelectTest.testFilterWithIndexForContains(SelectTest.java:542)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> The latter seems to be giving the results in the wrong order, and the order
> flips when the data is flushed.
> Caught during preparation of _latest config that would switch default to SAI
> (CASSANDRA-18753).
--
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-18927) Fix potential race condition in IndexViewManager during invalidation
[
https://issues.apache.org/jira/browse/CASSANDRA-18927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18927:
---
Fix Version/s: 5.0-beta
(was: 5.0-rc)
> Fix potential race condition in IndexViewManager during invalidation
>
>
> Key: CASSANDRA-18927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18927
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.0-beta
>
>
> There is a potential race condition in the {{IndexViewManager.invalidate}}
> method:
> {code:java}
> public void invalidate()
> {
> View currentView = view.get();
> for (SSTableIndex index : currentView)
> {
> index.markObsolete();
> }
> view.set(new View(context, Collections.emptyList()));
> } {code}
> We should {{getAndSet}} the view before marking the indexes as obsolete. This
> would avoid indexes potentially being made obsolete when being accessed.
--
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-19011) Harry-found exception in during SAI query
[
https://issues.apache.org/jira/browse/CASSANDRA-19011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19011:
---
Fix Version/s: 5.0-beta
(was: 5.0-rc)
> Harry-found exception in during SAI query
> -
>
> Key: CASSANDRA-19011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19011
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-beta
>
>
> Schema:
> {code:java}
> CREATE TABLE IF NOT EXISTS distributed_test_keyspace.tbl1 (pk1 bigint,ck1
> bigint,v1 ascii,v2 bigint, PRIMARY KEY (pk1, ck1)) WITH CLUSTERING ORDER BY
> (ck1 ASC);
> CREATE CUSTOM INDEX v1_sai_idx ON distributed_test_keyspace.tbl1 (v1) USING
> 'StorageAttachedIndex' WITH OPTIONS = {'case_sensitive': 'false',
> 'normalize': 'true', 'ascii': 'true'}; ;
> CREATE CUSTOM INDEX v2_sai_idx ON distributed_test_keyspace.tbl1 (v2) USING
> 'StorageAttachedIndex';
> {code}
> {code:java}
> java.lang.AssertionError: skipped to an item smaller than the target;
> iterator:
> org.apache.cassandra.index.sai.disk.IndexSearchResultIterator@f399f79, target
> key: PrimaryKey: { token: 8384965201802291970, partition:
> DecoratedKey(8384965201802291970, c4bc1c50f9e76a50), clustering:
> CLUSTERING:8b4b4c5991a4ea10 } , returned key: PrimaryKey: { token:
> 8384965201802291970, partition: DecoratedKey(8384965201802291970,
> c4bc1c50f9e76a50), clustering: CLUSTERING:89f1cf92658cb668 }
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIntersectionIterator.computeNext(KeyRangeIntersectionIterator.java:95)
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIntersectionIterator.computeNext(KeyRangeIntersectionIterator.java:39)
> at
> org.apache.cassandra.utils.AbstractGuavaIterator.tryToComputeNext(AbstractGuavaIterator.java:122)
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIterator.tryToComputeNext(KeyRangeIterator.java:129)
> at
> org.apache.cassandra.utils.AbstractGuavaIterator.hasNext(AbstractGuavaIterator.java:116)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextKey(StorageAttachedIndexSearcher.java:274)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextKeyInRange(StorageAttachedIndexSearcher.java:203)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextSelectedKeyInRange(StorageAttachedIndexSearcher.java:234)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextRowIterator(StorageAttachedIndexSearcher.java:188)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.computeNext(StorageAttachedIndexSearcher.java:169)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.computeNext(StorageAttachedIndexSearcher.java:111)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:91)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:338)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:201)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:186)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:346)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2186)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2581)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> relocated.shaded.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
>
> Unfortunately, there's no tooling for shrinking around SAI just yet, but I
> have a programmatic repro using INSERT and DELETE statements. I will do my
> best to post it asap, but thought this can already be useful for visibility.
--
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-18166) Improve the code model around IndexContext
[ https://issues.apache.org/jira/browse/CASSANDRA-18166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18166: --- Fix Version/s: 5.0-beta (was: 5.0-rc) > Improve the code model around IndexContext > -- > > Key: CASSANDRA-18166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18166 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Labels: SAI > Fix For: 5.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > We currently have a situation where we need to create an IndexContext that is > for a non-indexed column and therefore is never going to be used for indexing > or searching. This results in the IndexContext having to check for this at > points in the code with assertions. The reason for this that, even when the > column is non-indexed, we need to have information about the column for the > purpose of post-filtering. > It would make sense to split out the column / index information needed for > filtering from the indexing / searching requirements such that we could avoid > unnecessary assertions in the 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-18314) Lift MessagingService.minimum_version to 40
[ https://issues.apache.org/jira/browse/CASSANDRA-18314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18314: --- Fix Version/s: 5.0-beta (was: 5.0-alpha1) > Lift MessagingService.minimum_version to 40 > --- > > Key: CASSANDRA-18314 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18314 > Project: Cassandra > Issue Type: Task > Components: Messaging/Internode >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0, 5.0-beta > > Time Spent: 15h 20m > Remaining Estimate: 0h > > MessagingService's VERSION_30 and VERSION_3014 don't have to be supported in > Cassandra 5.0 anymore. > (Cassandra 5.0 currently is still using VERSION_40) > Patch: > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/18314/trunk > Raises the question whether backward compatibility to the previous major is > defined by the Cassandra version or by the internal component version > (MessagingService). -- 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-18314) Lift MessagingService.minimum_version to 40
[ https://issues.apache.org/jira/browse/CASSANDRA-18314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18314: --- Resolution: (was: Fixed) Status: Open (was: Resolved) Reopening following [~aleksey] comment. > Lift MessagingService.minimum_version to 40 > --- > > Key: CASSANDRA-18314 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18314 > Project: Cassandra > Issue Type: Task > Components: Messaging/Internode >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0, 5.0-alpha1 > > Time Spent: 15h 20m > Remaining Estimate: 0h > > MessagingService's VERSION_30 and VERSION_3014 don't have to be supported in > Cassandra 5.0 anymore. > (Cassandra 5.0 currently is still using VERSION_40) > Patch: > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/18314/trunk > Raises the question whether backward compatibility to the previous major is > defined by the Cassandra version or by the internal component version > (MessagingService). -- 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-18994) SAI range query does not play together with "IN"
[
https://issues.apache.org/jira/browse/CASSANDRA-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18994:
---
Fix Version/s: 5.0-beta
> SAI range query does not play together with "IN"
>
>
> Key: CASSANDRA-18994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18994
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Stefan Miklosovic
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.0-beta
>
>
> I am using schema from the website's quickstart.
> {code}
> cqlsh> DESCRIBE KEYSPACE cycling ;
> CREATE KEYSPACE cycling WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE cycling.cyclist_semi_pro (
> id int PRIMARY KEY,
> affiliation text,
> age int,
> country text,
> firstname text,
> lastname text,
> registration date
> ) WITH 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.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> 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 incremental_backups = true
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> CREATE CUSTOM INDEX age_sai_idx ON cycling.cyclist_semi_pro (age) USING
> 'StorageAttachedIndex';
> CREATE CUSTOM INDEX country_sai_idx ON cycling.cyclist_semi_pro (country)
> USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii': 'true',
> 'case_sensitive': 'false', 'normalize': 'true'};
> CREATE CUSTOM INDEX lastname_sai_idx ON cycling.cyclist_semi_pro (lastname)
> USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii': 'true',
> 'case_sensitive': 'false', 'normalize': 'true'};
> CREATE CUSTOM INDEX registration_sai_idx ON cycling.cyclist_semi_pro
> (registration) USING 'StorageAttachedIndex';
> {code}
> Then I do:
> {code}
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE lastname in ('Cantona',
> 'Boyd');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> execute this query as it might involve data filtering and thus may have
> unpredictable performance. If you want to execute this query despite the
> performance unpredictability, use ALLOW FILTERING"
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE lastname in ('Cantona',
> 'Boyd') ALLOW FILTERING;
> id | affiliation | age | country | firstname | lastname | registration
> +-+-+-+---+--+--
> 5 | Como Velocità | 24 | ITA | Irene | Cantona | 2012-07-22
> 20 | London Cyclists | 18 | GBR |Leslie | Boyd | 2012-12-15
> {code}
> But check this:
> {code}
> cqlsh> SELECT * FROM cycling.cyclist_semi_pro WHERE registration >
> '2010-01-01' AND registration < '2015-12-31' and lastname in ('Cantona',
> 'Boyd') allow filtering;
> ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read]
> message="Operation failed - received 0 responses and 1 failures: UNKNOWN from
> localhost/127.0.0.1:7000" info={'consistency': 'ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 1, 'error_code_map': {'127.0.0.1':
> '0x'}}
> {code}
> and in the logs:
> {code}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.index.sai.plan.Expression.add(Expression.java:171)
> at
> org.apache.cassandra.index.sai.plan.Operation.buildIndexExpressions(Operation.java:136)
> at
> org.apache.cassandra.index.sai.plan.Operation$AndNode.analyze(Operation.java:303)
> at
> org.apache.cassandra.index.sai.plan.Operation$Node.doTreeAnalysis(Operation.java:266)
> at
> org.apache.cassandra.index.sai.plan.Operation$Node.analyzeTree(Operation.java:251)
> at
> org.apache.cassandra.index.sai.plan.Operation.buildIterator(Operation.java:185)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.(StorageAttachedIndexSearcher.java:151)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher.search(StorageAttachedIndexSearcher.java:107)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:431)
> at
>
[jira] [Updated] (CASSANDRA-18930) Test failure: dtest-novnode.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ssl_client_auth_required_fail
[
https://issues.apache.org/jira/browse/CASSANDRA-18930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18930:
---
Fix Version/s: 5.0-rc
(was: 5.x)
> Test failure:
> dtest-novnode.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ssl_client_auth_required_fail
>
> --
>
> Key: CASSANDRA-18930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18930
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Seen on trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1744/testReport/dtest-novnode.sslnodetonode_test/TestNodeToNodeSSLEncryption/test_ssl_client_auth_required_fail/]
> {code:java}
> Error Message
> assert False
> Stacktrace
> self = 0x7f45f37786d0> def test_ssl_client_auth_required_fail(self): """peers need
> to perform mutual auth (cient auth required), but do not supply the local
> cert""" credNode1 = sslkeygen.generate_credentials("127.0.0.1") credNode2 =
> sslkeygen.generate_credentials("127.0.0.2") self.setup_nodes(credNode1,
> credNode2, client_auth=True) self.fixture_dtest_setup.allow_log_errors = True
> self.cluster.start(no_wait=True) time.sleep(2) found =
> self._grep_msg(self.node1, _LOG_ERR_HANDSHAKE, _LOG_ERR_GENERAL) > assert
> found E assert False sslnodetonode_test.py:83: 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-18947) Test failure: dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
[
https://issues.apache.org/jira/browse/CASSANDRA-18947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18947:
---
Fix Version/s: 5.0-rc
(was: 5.0.x)
> Test failure:
> dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
> --
>
> Key: CASSANDRA-18947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18947
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/72/testReport/dtest-novnode.disk_balance_test/TestDiskBalance/test_disk_balance_stress/
> h3.
> {code:java}
> Error Message
> AssertionError: values not within 10.00% of the max: (2534183, 2762123,
> 2423706) (node1)
> Stacktrace
> self = def
> test_disk_balance_stress(self): cluster = self.cluster if
> self.dtest_config.use_vnodes:
> cluster.set_configuration_options(values={'num_tokens': 256})
> cluster.populate(4).start() node1 = cluster.nodes['node1']
> node1.stress(['write', 'n=50k', 'no-warmup', '-rate', 'threads=100',
> '-schema', 'replication(factor=3)',
> 'compaction(strategy=SizeTieredCompactionStrategy,enabled=false)'])
> cluster.flush() # make sure the data directories are balanced: for node in
> cluster.nodelist(): > self.assert_balanced(node) disk_balance_test.py:48: _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> disk_balance_test.py:186: in assert_balanced assert_almost_equal(*new_sums,
> error=0.1, error_message=node.name) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ args = (2534183, 2762123, 2423706)
> kwargs = {'error': 0.1, 'error_message': 'node1'}, error = 0.1, vmax =
> 2762123 vmin = 2423706, error_message = 'node1' def
> assert_almost_equal(*args, **kwargs): """ Assert variable number of arguments
> all fall within a margin of error. @params *args variable number of numerical
> arguments to check @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default '' Examples:
> assert_almost_equal(sizes[2], init_size) assert_almost_equal(ttl_session1,
> ttl_session2[0][0], error=0.005) """ error = kwargs['error'] if 'error' in
> kwargs else 0.16 vmax = max(args) vmin = min(args) error_message = '' if
> 'error_message' not in kwargs else kwargs['error_message'] assert vmin > vmax
> * (1.0 - error) or vmin == vmax, \ > "values not within {:.2f}% of the max:
> {} ({})".format(error * 100, args, error_message) E AssertionError: values
> not within 10.00% of the max: (2534183, 2762123, 2423706) (node1)
> tools/assertions.py:206: 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-18911) KeyCacheTest is failing with sstable_preemptive_open_interval < 0
[ https://issues.apache.org/jira/browse/CASSANDRA-18911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18911: --- Fix Version/s: 5.0-beta (was: 5.0) > KeyCacheTest is failing with sstable_preemptive_open_interval < 0 > - > > Key: CASSANDRA-18911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18911 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.0-beta, 5.1 > > > Discovered by [~maedhroz] -- 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-18963) Test Failure: sstableutil_test.TestSSTableUtil
[
https://issues.apache.org/jira/browse/CASSANDRA-18963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18963:
---
Fix Version/s: 5.0-beta
(was: 5.0-rc)
> Test Failure: sstableutil_test.TestSSTableUtil
> --
>
> Key: CASSANDRA-18963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18963
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-beta
>
>
> Seems flaky
> [https://app.circleci.com/pipelines/github/driftx/cassandra/1342/workflows/9554c7b5-dd60-4f08-8db5-c954febc8ad6/jobs/58957/tests]
> *
> h4. test_abortedcompaction
> sstableutil_test.TestSSTableUtil
>
> {code:java}
> self = def
> test_abortedcompaction(self): """ @jira_ticket CASSANDRA-7066 @jira_ticket
> CASSANDRA-11497 Check that we can cleanup temporary files after a compaction
> is aborted. """ log_file_name = 'debug.log' cluster = self.cluster
> cluster.populate(1).start() node = cluster.nodelist()[0] numrecords = 25
> self._create_data(node, KeyspaceName, TableName, numrecords) finalfiles,
> tmpfiles = self._check_files(node, KeyspaceName, TableName) assert
> len(finalfiles) > 0, "Expected to find some final files" assert 0 ==
> len(tmpfiles), "Expected no tmp files" t = InterruptCompaction(node,
> TableName, filename=log_file_name, delay=2) t.start() try:
> logger.debug("Compacting...") node.compact() except ToolError: pass #
> expected to fail t.join() finalfiles =
> _normcase_all(self._invoke_sstableutil(KeyspaceName, TableName,
> type='final')) tmpfiles =
> _normcase_all(self._invoke_sstableutil(KeyspaceName, TableName, type='tmp'))
> # In most cases we should end up with some temporary files to clean up, but
> it may happen # that no temporary files are created if compaction finishes
> too early or starts too late # see CASSANDRA-11497 logger.debug("Got {} final
> files and {} tmp files after compaction was interrupted"
> .format(len(finalfiles), len(tmpfiles)))
> self._invoke_sstableutil(KeyspaceName, TableName, cleanup=True)
> self._check_files(node, KeyspaceName, TableName, finalfiles, []) # restart to
> make sure not data is lost logger.debug("Restarting node...") >
> node.start(wait_for_binary_proto=True) sstableutil_test.py:97: _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:914: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:702: in
> wait_for_binary_interface self.watch_log_for("Starting listening for CQL
> clients", **kwargs) ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:599:
> in watch_log_for self.raise_node_error_if_cassandra_process_is_terminated() _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> self = def
> raise_node_error_if_cassandra_process_is_terminated(self): if not
> self._is_pid_running(): msg = "C* process with {pid} is
> terminated".format(pid=self.pid) common.debug(msg) > raise NodeError(msg) E
> ccmlib.node.NodeError: C* process with 19530 is terminated
> ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:683: NodeError{code}
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node1] 'ERROR [SSTableBatchOpen:1] 2023-10-19
> 22:25:07,449 DefaultFSErrorHandler.java:129 - Exiting forcefully due to file
> system exception on startup, disk failure policy
> "stop"\norg.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /tmp/dtest-ahz16wrh/test/node1/data0/system/prepared_statements-18a9c2576a0c3841ba718cd529849fef/nc-4-big\n\tat
>
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:111)\n\tat
>
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)\n\tat
>
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:353)\n\tat
>
> org.apache.cassandra.io.sstable.format.SSTableReader.lambda$openAll$4(SSTableReader.java:414)\n\tat
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)\n\tat
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)\n\tat
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)\n\tat
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)\nCaused by:
>
[jira] [Updated] (CASSANDRA-18710) Test failure: org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize-.jdk17 (from org.apache.cassandra.io.DiskSpaceMetricsTest-.jdk17)
[
https://issues.apache.org/jira/browse/CASSANDRA-18710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18710:
---
Fix Version/s: 5.0-beta
(was: 5.0-rc)
> Test failure:
> org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize-.jdk17 (from
> org.apache.cassandra.io.DiskSpaceMetricsTest-.jdk17)
> --
>
> Key: CASSANDRA-18710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18710
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-beta, 5.0.x, 5.x
>
> Attachments: org.apache.cassandra.io.DiskSpaceMetricsTest.txt
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1644/testReport/org.apache.cassandra.io/DiskSpaceMetricsTest/testFlushSize__jdk17/]
> h3.
> {code:java}
> Error Message
> expected:<7200.0> but was:<1367.83970468544>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<7200.0> but
> was:<1367.83970468544> at
> org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize(DiskSpaceMetricsTest.java:119)
> 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-18934) Downgrade to 4.1 fails due to schema changes
[
https://issues.apache.org/jira/browse/CASSANDRA-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18934:
---
Fix Version/s: (was: 5.0-beta)
> Downgrade to 4.1 fails due to schema changes
>
>
> Key: CASSANDRA-18934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18934
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: David Capwell
>Priority: Normal
> Fix For: 5.x
>
>
> We are required to support 5.0 downgrading to 4.1 as a migration step, but we
> don’t have tests to show this is working… I wrote a quick test to make sure a
> change we needed in Accord wouldn’t block the downgrade and see that we fail
> right now.
> {code}
> ERROR 20:56:39 Exiting due to error while processing commit log during
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
> Unexpected error deserializing mutation; saved to
> /var/folders/h1/s_3p1x3s3hl0hltbpck67m0hgn/T/mutation418421767150092dat.
> This may be caused by replaying a mutation against a table with the same
> name but incompatible schema. Exception follows: java.lang.RuntimeException:
> Unknown column compaction_properties during deserialization
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:464)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:397)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:244)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:147)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:191)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:223)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:204)
> {code}
> This was caused by a schema change in CASSANDRA-18061
> {code}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one
> * or more contributor license agreements. See the NOTICE file
> * distributed with this work for additional information
> * regarding copyright ownership. The ASF licenses this file
> * to you under the Apache License, Version 2.0 (the
> * "License"); you may not use this file except in compliance
> * with the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.cassandra.distributed.upgrade;
> import java.io.IOException;
> import java.io.File;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.junit.Test;
> import org.apache.cassandra.distributed.api.IUpgradeableInstance;
> public class DowngradeTest extends UpgradeTestBase
> {
> @Test
> public void test() throws Throwable
> {
> AtomicBoolean first = new AtomicBoolean(true);
> new TestCase()
> .nodes(1)
> .withConfig(c -> {
> if (first.compareAndSet(true, false))
> c.set("storage_compatibility_mode", "CASSANDRA_4");
> })
> .downgradeTo(v41)
> .setup(cluster -> {})
> // Uncomment if you want to test what happens after reading the commit log,
> which fails right now
> //.runBeforeNodeRestart((cluster, nodeId) -> {
> //IUpgradeableInstance inst = cluster.get(nodeId);
> //File f = new File((String)
> inst.config().get("commitlog_directory"));
> //deleteRecursive(f);
> //})
> .runAfterClusterUpgrade(cluster -> {})
> .run();
> }
> private void deleteRecursive(File f)
> {
> if (f.isDirectory())
> {
> File[] children = f.listFiles();
> if (children != null)
> {
> for (File c : children)
> deleteRecursive(c);
> }
> }
> f.delete();
> }
> }
> {code}
> {code}
> diff --git
> a/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java
>
> b/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java
> index 5ee8780204..b4111e3b44 100644
> ---
> a/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java
> +++
>
[jira] [Updated] (CASSANDRA-18944) Test failure: org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18944:
---
Fix Version/s: 5.0-rc
(was: 5.0.x)
> Test failure:
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
> -
>
> Key: CASSANDRA-18944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18944
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> The simulator test
> {{org.apache.cassandra.simulator.test.ShortPaxosSimulationTest#simulationTest}}
> is flaky on 5.0 and trunk:
> *
> https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/332/workflows/946e28f4-2dec-4384-ac38-de011093f6c6/jobs/25735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3253/workflows/e48b49e9-cf36-412a-a811-d813031e6f01/jobs/83735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3254/workflows/69f451ef-fb39-48e4-b1d1-40ee4141b0c1/jobs/83739/tests
> {code}
> org.apache.cassandra.simulator.SimulationException: Failed on seed
> 0xb01206bb3b021127
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.net.NoPayload cannot be cast to class
> org.apache.cassandra.gms.GossipShutdown (org.apache.cassandra.net.NoPayload
> and org.apache.cassandra.gms.GossipShutdown are in unnamed module of loader
> org.apache.cassandra.distributed.shared.InstanceClassLoader @68801feb)
> at
> org.apache.cassandra.gms.GossipShutdown$Serializer.serialize(GossipShutdown.java:41)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:722)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:427)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$registerOutboundFilter$5(Instance.java:370)
> at
> org.apache.cassandra.net.OutboundSink$Filtered.accept(OutboundSink.java:54)
> at org.apache.cassandra.net.OutboundSink.accept(OutboundSink.java:70)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:449)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:419)
> at
> org.apache.cassandra.gms.Gossiper.unsafeSendShutdown(Gossiper.java:2634)
> at
> org.apache.cassandra.simulator.cluster.OnInstanceSendShutdown.lambda$invokableSendShutdown$1(OnInstanceSendShutdown.java:48)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at
> org.apache.cassandra.concurrent.SyncFutureTask$1.call(SyncFutureTask.java:46)
> at
> org.apache.cassandra.concurrent.SyncFutureTask.run(SyncFutureTask.java:68)
> at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$AbstractSingleThreadedExecutorPlus.lambda$new$0(InterceptingExecutor.java:584)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> The test failure can easily be reproduced on CircleCI with:
> {code}
> .circleci/generate.sh -sp \
> -e
> REPEATED_SIMULATOR_DTESTS=org.apache.cassandra.simulator.test.ShortPaxosSimulationTest
> \
> -e REPEATED_SIMULATOR_DTESTS_COUNT=100
> {code}
> Flakiness seems ~18%.
> The test failure is not reported on Butler because simulator tests are not
> run by Jenkins.
--
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-18902) Test failure: org.apache.cassandra.distributed.test.MigrationCoordinatorTest.explicitEndpointIgnore
[ https://issues.apache.org/jira/browse/CASSANDRA-18902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18902: --- Fix Version/s: 5.0-rc (was: 5.0.x) > Test failure: > org.apache.cassandra.distributed.test.MigrationCoordinatorTest.explicitEndpointIgnore > --- > > Key: CASSANDRA-18902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18902 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Priority: Normal > Fix For: 5.0-rc, 5.x > > > Repeated run from `cassandra-4.1` > [https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/941/workflows/46fc6cb7-135e-4862-b9d3-6996c0993de8] > -- 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-18895) Test failure: https://ci-cassandra.apache.org/job/Cassandra-5.0/47/testReport/org.apache.cassandra.distributed.test/MessageFiltersTest/hintSerializationTest__jdk17/
[
https://issues.apache.org/jira/browse/CASSANDRA-18895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18895:
---
Fix Version/s: 5.0-rc
(was: 5.0.x)
> Test failure:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/47/testReport/org.apache.cassandra.distributed.test/MessageFiltersTest/hintSerializationTest__jdk17/
>
>
> Key: CASSANDRA-18895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18895
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc
>
>
> h3.
> {code:java}
> https://ci-cassandra.apache.org/job/Cassandra-5.0/47/testReport/org.apache.cassandra.distributed.test/MessageFiltersTest/hintSerializationTest__jdk17/{code}
> {code:java}
> Error Message
> Uncaught exceptions were thrown during test
> Stacktrace
> org.apache.cassandra.distributed.shared.ShutdownException: Uncaught
> exceptions were thrown during test at
> org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:1104)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1090)
> at
> org.apache.cassandra.distributed.test.MessageFiltersTest.hintSerializationTest(MessageFiltersTest.java:297)
> 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)
> Suppressed: java.lang.IllegalStateException: Can't use shutdown instances,
> delegate is null at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegate(AbstractCluster.java:285)
> at
> org.apache.cassandra.distributed.impl.DelegatingInvokableInstance.transfer(DelegatingInvokableInstance.java:49)
> at
> org.apache.cassandra.distributed.api.IInvokableInstance.acceptsOnInstance(IInvokableInstance.java:49)
> at
> org.apache.cassandra.distributed.test.MessageFiltersTest.lambda$hintSerializationTest$11(MessageFiltersTest.java:287)
> at
> org.apache.cassandra.distributed.impl.MessageFilters$Filter.matches(MessageFilters.java:137)
> at
> org.apache.cassandra.distributed.impl.MessageFilters.permit(MessageFilters.java:61)
> at
> org.apache.cassandra.distributed.impl.MessageFilters.permitInbound(MessageFilters.java:37)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$registerInboundFilter$4(Instance.java:361)
> at org.apache.cassandra.net.InboundSink$Filtered.accept(InboundSink.java:63)
> at org.apache.cassandra.net.InboundSink$Filtered.accept(InboundSink.java:50)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97) at
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45) at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:430)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143) at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> {code}
>
> {code:java}
> ERROR 12:39:56 uncaught exception in thread
> Thread[node1_MemtablePostFlush:1,5,MemtablePostFlush]
> java.util.concurrent.RejectedExecutionException: MemtableReclaimMemory has
> shut down at
> org.apache.cassandra.concurrent.ThreadPoolExecutorBase.lambda$static$0(ThreadPoolExecutorBase.java:49)
> at
> org.apache.cassandra.concurrent.ThreadPoolExecutorJMXAdapter.lambda$rejectedExecutionHandler$0(ThreadPoolExecutorJMXAdapter.java:238)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
> at
> org.apache.cassandra.concurrent.ThreadPoolExecutorPlus.addTask(ThreadPoolExecutorPlus.java:50)
> at
> org.apache.cassandra.concurrent.ThreadPoolExecutorPlus.execute(ThreadPoolExecutorPlus.java:57)
> at
> org.apache.cassandra.utils.concurrent.ListenerList.safeExecute(ListenerList.java:166)
> at
> org.apache.cassandra.utils.concurrent.ListenerList.notifyListener(ListenerList.java:157)
> at
> org.apache.cassandra.utils.concurrent.ListenerList$RunnableWithExecutor.notifySelf(ListenerList.java:345)
> at
> org.apache.cassandra.utils.concurrent.ListenerList.lambda$notifyExclusive$0(ListenerList.java:124)
> at
>
[jira] [Updated] (CASSANDRA-18934) Downgrade to 4.1 fails due to schema changes
[
https://issues.apache.org/jira/browse/CASSANDRA-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18934:
---
Fix Version/s: 5.0-beta
(was: 5.0.x)
> Downgrade to 4.1 fails due to schema changes
>
>
> Key: CASSANDRA-18934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18934
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: David Capwell
>Priority: Normal
> Fix For: 5.0-beta, 5.x
>
>
> We are required to support 5.0 downgrading to 4.1 as a migration step, but we
> don’t have tests to show this is working… I wrote a quick test to make sure a
> change we needed in Accord wouldn’t block the downgrade and see that we fail
> right now.
> {code}
> ERROR 20:56:39 Exiting due to error while processing commit log during
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
> Unexpected error deserializing mutation; saved to
> /var/folders/h1/s_3p1x3s3hl0hltbpck67m0hgn/T/mutation418421767150092dat.
> This may be caused by replaying a mutation against a table with the same
> name but incompatible schema. Exception follows: java.lang.RuntimeException:
> Unknown column compaction_properties during deserialization
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:464)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:397)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:244)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:147)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:191)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:223)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:204)
> {code}
> This was caused by a schema change in CASSANDRA-18061
> {code}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one
> * or more contributor license agreements. See the NOTICE file
> * distributed with this work for additional information
> * regarding copyright ownership. The ASF licenses this file
> * to you under the Apache License, Version 2.0 (the
> * "License"); you may not use this file except in compliance
> * with the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.cassandra.distributed.upgrade;
> import java.io.IOException;
> import java.io.File;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.junit.Test;
> import org.apache.cassandra.distributed.api.IUpgradeableInstance;
> public class DowngradeTest extends UpgradeTestBase
> {
> @Test
> public void test() throws Throwable
> {
> AtomicBoolean first = new AtomicBoolean(true);
> new TestCase()
> .nodes(1)
> .withConfig(c -> {
> if (first.compareAndSet(true, false))
> c.set("storage_compatibility_mode", "CASSANDRA_4");
> })
> .downgradeTo(v41)
> .setup(cluster -> {})
> // Uncomment if you want to test what happens after reading the commit log,
> which fails right now
> //.runBeforeNodeRestart((cluster, nodeId) -> {
> //IUpgradeableInstance inst = cluster.get(nodeId);
> //File f = new File((String)
> inst.config().get("commitlog_directory"));
> //deleteRecursive(f);
> //})
> .runAfterClusterUpgrade(cluster -> {})
> .run();
> }
> private void deleteRecursive(File f)
> {
> if (f.isDirectory())
> {
> File[] children = f.listFiles();
> if (children != null)
> {
> for (File c : children)
> deleteRecursive(c);
> }
> }
> f.delete();
> }
> }
> {code}
> {code}
> diff --git
> a/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java
>
> b/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java
> index 5ee8780204..b4111e3b44 100644
> ---
> a/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java
> +++
>
[jira] [Updated] (CASSANDRA-18883) CEP-15: Support State Eviction
[ https://issues.apache.org/jira/browse/CASSANDRA-18883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18883: --- Fix Version/s: 5.x (was: 5.0) > CEP-15: Support State Eviction > -- > > Key: CASSANDRA-18883 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18883 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Caleb Rackliffe >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 5.x > > > Permit the state machine to erase transactions that are known to be applied > across the cluster. -- 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-18963) Test Failure: sstableutil_test.TestSSTableUtil
[
https://issues.apache.org/jira/browse/CASSANDRA-18963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18963:
---
Fix Version/s: 5.0-rc
(was: 5.0.x)
> Test Failure: sstableutil_test.TestSSTableUtil
> --
>
> Key: CASSANDRA-18963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18963
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Seems flaky
> [https://app.circleci.com/pipelines/github/driftx/cassandra/1342/workflows/9554c7b5-dd60-4f08-8db5-c954febc8ad6/jobs/58957/tests]
> *
> h4. test_abortedcompaction
> sstableutil_test.TestSSTableUtil
>
> {code:java}
> self = def
> test_abortedcompaction(self): """ @jira_ticket CASSANDRA-7066 @jira_ticket
> CASSANDRA-11497 Check that we can cleanup temporary files after a compaction
> is aborted. """ log_file_name = 'debug.log' cluster = self.cluster
> cluster.populate(1).start() node = cluster.nodelist()[0] numrecords = 25
> self._create_data(node, KeyspaceName, TableName, numrecords) finalfiles,
> tmpfiles = self._check_files(node, KeyspaceName, TableName) assert
> len(finalfiles) > 0, "Expected to find some final files" assert 0 ==
> len(tmpfiles), "Expected no tmp files" t = InterruptCompaction(node,
> TableName, filename=log_file_name, delay=2) t.start() try:
> logger.debug("Compacting...") node.compact() except ToolError: pass #
> expected to fail t.join() finalfiles =
> _normcase_all(self._invoke_sstableutil(KeyspaceName, TableName,
> type='final')) tmpfiles =
> _normcase_all(self._invoke_sstableutil(KeyspaceName, TableName, type='tmp'))
> # In most cases we should end up with some temporary files to clean up, but
> it may happen # that no temporary files are created if compaction finishes
> too early or starts too late # see CASSANDRA-11497 logger.debug("Got {} final
> files and {} tmp files after compaction was interrupted"
> .format(len(finalfiles), len(tmpfiles)))
> self._invoke_sstableutil(KeyspaceName, TableName, cleanup=True)
> self._check_files(node, KeyspaceName, TableName, finalfiles, []) # restart to
> make sure not data is lost logger.debug("Restarting node...") >
> node.start(wait_for_binary_proto=True) sstableutil_test.py:97: _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:914: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:702: in
> wait_for_binary_interface self.watch_log_for("Starting listening for CQL
> clients", **kwargs) ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:599:
> in watch_log_for self.raise_node_error_if_cassandra_process_is_terminated() _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> self = def
> raise_node_error_if_cassandra_process_is_terminated(self): if not
> self._is_pid_running(): msg = "C* process with {pid} is
> terminated".format(pid=self.pid) common.debug(msg) > raise NodeError(msg) E
> ccmlib.node.NodeError: C* process with 19530 is terminated
> ../env3.6/lib/python3.6/site-packages/ccmlib/node.py:683: NodeError{code}
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node1] 'ERROR [SSTableBatchOpen:1] 2023-10-19
> 22:25:07,449 DefaultFSErrorHandler.java:129 - Exiting forcefully due to file
> system exception on startup, disk failure policy
> "stop"\norg.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /tmp/dtest-ahz16wrh/test/node1/data0/system/prepared_statements-18a9c2576a0c3841ba718cd529849fef/nc-4-big\n\tat
>
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:111)\n\tat
>
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)\n\tat
>
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:353)\n\tat
>
> org.apache.cassandra.io.sstable.format.SSTableReader.lambda$openAll$4(SSTableReader.java:414)\n\tat
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)\n\tat
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)\n\tat
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)\n\tat
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)\nCaused by:
>
[jira] [Updated] (CASSANDRA-18950) Test failure: dtest.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ca_mismatch
[
https://issues.apache.org/jira/browse/CASSANDRA-18950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18950:
---
Fix Version/s: 5.0-rc
(was: 5.x)
> Test failure:
> dtest.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ca_mismatch
> ---
>
> Key: CASSANDRA-18950
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18950
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1746/testReport/dtest.sslnodetonode_test/TestNodeToNodeSSLEncryption/test_ca_mismatch/]
>
> {code:java}
> self = 0x7f45da997710> def test_ca_mismatch(self): """CA mismatch should cause nodes
> to fail to connect""" credNode1 = sslkeygen.generate_credentials("127.0.0.1")
> credNode2 = sslkeygen.generate_credentials("127.0.0.2") # mismatching CA!
> self.setup_nodes(credNode1, credNode2)
> self.fixture_dtest_setup.allow_log_errors = True
> self.cluster.start(no_wait=True) found = self._grep_msg(self.node1,
> _LOG_ERR_HANDSHAKE) self.cluster.stop() > assert found E assert False
> sslnodetonode_test.py:115: 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-18710) Test failure: org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize-.jdk17 (from org.apache.cassandra.io.DiskSpaceMetricsTest-.jdk17)
[
https://issues.apache.org/jira/browse/CASSANDRA-18710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18710:
---
Fix Version/s: 5.0-rc
(was: 5.0-beta)
> Test failure:
> org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize-.jdk17 (from
> org.apache.cassandra.io.DiskSpaceMetricsTest-.jdk17)
> --
>
> Key: CASSANDRA-18710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18710
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
> Attachments: org.apache.cassandra.io.DiskSpaceMetricsTest.txt
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1644/testReport/org.apache.cassandra.io/DiskSpaceMetricsTest/testFlushSize__jdk17/]
> h3.
> {code:java}
> Error Message
> expected:<7200.0> but was:<1367.83970468544>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<7200.0> but
> was:<1367.83970468544> at
> org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize(DiskSpaceMetricsTest.java:119)
> 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-18949) Test failure: org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18949:
---
Fix Version/s: 5.0-rc
(was: 5.x)
> Test failure:
> org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
> ---
>
> Key: CASSANDRA-18949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18949
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1747/testReport/org.apache.cassandra.tools.nodetool/ClearSnapshotTest/testClearSnapshot_RemoveByName__jdk11_arch_x86_64_python2_7/]
> h3.
> {code:java}
> Error Message
> [bin/nodetool, -p, 36753, -h, 127.0.0.1, snapshot, -t, some-name] exited with
> code 2 stderr: error: Unknown keyspace keyspace_04 -- StackTrace --
> java.lang.AssertionError: Unknown keyspace keyspace_04 at
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324) at
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162) at
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)
> at
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:162) at
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151) at
> com.google.common.collect.Iterators$6.transform(Iterators.java:828) at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:52)
> at
> org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4356)
> at
> org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4221)
> 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)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at
> jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260) at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:809)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:827)
> at java.base/jdk.internal.reflect.GeneratedMethodAccessor16.invoke(Unknown
> Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200) at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197) at
> java.base/java.security.AccessController.doPrivileged(Native Method) at
> java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
> at
[jira] [Updated] (CASSANDRA-18919) Test failure: org.apache.cassandra.io.sstable.VerifyTest.testMutateRepair-.jdk11
[
https://issues.apache.org/jira/browse/CASSANDRA-18919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18919:
---
Fix Version/s: 5.0-rc
(was: 5.0.x)
> Test failure:
> org.apache.cassandra.io.sstable.VerifyTest.testMutateRepair-.jdk11
>
>
> Key: CASSANDRA-18919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18919
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc
>
>
>
> {code:java}
> org.apache.cassandra.io.sstable.VerifyTest.testMutateRepair-.jdk11 (from
> org.apache.cassandra.io.sstable.VerifyTest-.jdk11)
> Failing for the past 1 build (Since #60 ) Took 0.42 sec. Failed 1 times
> in the last 16 runs. Flakiness: 6%, Stability: 93% Stacktrace
> java.io.EOFException at
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:180)
> at
> org.apache.cassandra.io.util.RebufferingInputStream.readPrimitiveSlowly(RebufferingInputStream.java:142)
> at
> org.apache.cassandra.io.util.RebufferingInputStream.readLong(RebufferingInputStream.java:231)
> at
> org.apache.cassandra.io.sstable.VerifyTest.testMutateRepair(VerifyTest.java:538)
> 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}
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/60/testReport/org.apache.cassandra.io.sstable/VerifyTest/testMutateRepair__jdk11/
>
--
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-18635) Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18635:
---
Fix Version/s: 5.0-rc
> Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
> ---
>
> Key: CASSANDRA-18635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18635
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1095/workflows/6114e2e3-8dcc-4bb0-b664-ae7d82c3349f/jobs/33405/tests
> {noformat}
> junit.framework.AssertionFailedError: expected:<0> but was:<2>
> at
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.upgradeSSTablesInterruptsOngoingCompaction(UpgradeSSTablesTest.java:86)
> {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] [Updated] (CASSANDRA-18811) Set right client auth for creating SSL context in mTLS optional mode
[ https://issues.apache.org/jira/browse/CASSANDRA-18811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18811: --- Fix Version/s: 5.0.x (was: 5.0-beta) > Set right client auth for creating SSL context in mTLS optional mode > > > Key: CASSANDRA-18811 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18811 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.1.x, 5.0.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Adding a new value `optional` for require_client_auth in Encryption options. > when require_client_auth is optional, the SSL context that is created will > allow client connections that provide a client certificate along with the > client connections that do not provide certificates. -- 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-18811) Set right client auth for creating SSL context in mTLS optional mode
[ https://issues.apache.org/jira/browse/CASSANDRA-18811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18811: --- Fix Version/s: 5.0-beta (was: 5.0-alpha) > Set right client auth for creating SSL context in mTLS optional mode > > > Key: CASSANDRA-18811 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18811 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.1.x, 5.0-beta, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Adding a new value `optional` for require_client_auth in Encryption options. > when require_client_auth is optional, the SSL context that is created will > allow client connections that provide a client certificate along with the > client connections that do not provide certificates. -- 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-18948) Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18948:
---
Fix Version/s: 5.0-rc
(was: 5.0.x)
> Test failure:
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
>
> ---
>
> Key: CASSANDRA-18948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18948
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/71/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testReplayLogic_compression_jdk17_arch_x86_64_python2_7/
> h3.
> {code:java}
> Error Message
> Missing old CDCIndexData in new set after replay:
> CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData in new set of
> indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214
> Stacktrace
> junit.framework.AssertionFailedError: Missing old CDCIndexData in new set
> after replay: CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData
> in new set of indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214 at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic(CommitLogSegmentManagerCDCTest.java:319)
> 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-18798) Appending to list in Accord transactions uses insertion timestamp
[
https://issues.apache.org/jira/browse/CASSANDRA-18798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18798:
---
Fix Version/s: (was: 5.0-beta)
> Appending to list in Accord transactions uses insertion timestamp
> -
>
> Key: CASSANDRA-18798
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18798
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Jaroslaw Kijanowski
>Assignee: Henrik Ingo
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-2023-09-26-20-05-25-846.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Given the following schema:
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS accord WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 3};
> CREATE TABLE IF NOT EXISTS accord.list_append(id int PRIMARY KEY,contents
> LIST);
> TRUNCATE accord.list_append;{code}
> And the following two possible queries executed by 10 threads in parallel:
> {code:java}
> BEGIN TRANSACTION
> LET row = (SELECT * FROM list_append WHERE id = ?);
> SELECT row.contents;
> COMMIT TRANSACTION;"
> BEGIN TRANSACTION
> UPDATE list_append SET contents += ? WHERE id = ?;
> COMMIT TRANSACTION;"
> {code}
> there seems to be an issue with transaction guarantees. Here's an excerpt in
> the edn format from a test.
> {code:java}
> {:type :invoke :process 8 :value [[:append 5 352]] :tid 3 :n 52
> :time 1692607285967116627}
> {:type :invoke :process 9 :value [[:r 5 nil]] :tid 1 :n 54
> :time 1692607286078732473}
> {:type :invoke :process 6 :value [[:append 5 553]] :tid 5 :n 53
> :time 1692607286133833428}
> {:type :invoke :process 7 :value [[:append 5 455]] :tid 4 :n 55
> :time 1692607286149702511}
> {:type :ok :process 8 :value [[:append 5 352]] :tid 3 :n 52
> :time 1692607286156314099}
> {:type :invoke :process 5 :value [[:r 5 nil]] :tid 9 :n 52
> :time 1692607286167090389}
> {:type :ok :process 9 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352]]] :tid 1 :n 54 :time 1692607286168657534}
> {:type :invoke :process 1 :value [[:r 5 nil]] :tid 0 :n 51
> :time 1692607286201762938}
> {:type :ok :process 7 :value [[:append 5 455]] :tid 4 :n 55
> :time 1692607286245571513}
> {:type :invoke :process 7 :value [[:r 5 nil]] :tid 4 :n 56
> :time 1692607286245655775}
> {:type :ok :process 5 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 455]]] :tid 9 :n 52 :time 1692607286253928906}
> {:type :invoke :process 5 :value [[:r 5 nil]] :tid 9 :n 53
> :time 1692607286254095215}
> {:type :ok :process 6 :value [[:append 5 553]] :tid 5 :n 53
> :time 1692607286266263422}
> {:type :ok :process 1 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 0 :n 51 :time 1692607286271617955}
> {:type :ok :process 7 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 4 :n 56 :time 1692607286271816933}
> {:type :ok :process 5 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 9 :n 53 :time 1692607286281483026}
> {:type :invoke :process 9 :value [[:r 5 nil]] :tid 1 :n 56
> :time 1692607286284097561}
> {:type :ok :process 9 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 1 :n 56 :time 1692607286306445242}
> {code}
> Processes process 6 and process 7 are appending the values 553 and 455
> respectively. 455 succeeded and a read by process 5 confirms that. But then
> also 553 is appended and a read by process 1 confirms that as well, however
> it sees 553 before 455.
> process 5 reads [...
[jira] [Updated] (CASSANDRA-18945) Unified Compaction Strategy is creating too many sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18945:
---
Fix Version/s: 5.0-beta
(was: 5.x)
(was: 5.0)
> Unified Compaction Strategy is creating too many sstables
> -
>
> Key: CASSANDRA-18945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18945
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Branimir Lambov
>Assignee: Ethan Brown
>Priority: Normal
> Fix For: 5.0-beta
>
> Attachments: file_ucs_shenandoah.html, file_ucs_shenandoah_3.html,
> file_ucs_shenandoah_off_heap_memtable.html,
> file_ucs_shenandoah_on_heap_memtable_2.html,
> file_ucs_shenandoah_on_heap_memtable_3.html, key-value-oss.html
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The unified compaction strategy currently aims to create sstables with close
> to the same size, defaulting to 1 GiB. Unfortunately tests show that
> Cassandra starts to have performance problems when the number of sstables
> grows to the order of a thousand, and in particular that even 1 TiB of data
> with the default configuration is creating too many sstables for efficient
> processing. This matters even more for SAI, where the number of sstables in
> the system can have a proportional effect on the complexity of operations.
> It is quite easy to create a configuration option that allows sstables to
> take some part of the data growth by adding a multiplier to [the shard count
> calculation|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md#sharding]
> formula, replacing
> {{2 ^ round(log2(d / (t * b))) * b}}
> with
> {{2 ^ round((1 - 휆) * log2(d / (t * b))) * b}},
> where 휆 is a parameter whose value is between 0 and 1.
> With this, a 휆 of 0.5 would mean that shard count and sstable size grow in
> parallel at the square root of the data size growth. 0 would result in no
> growth, and 1 in always using the same number of shards.
> It may also be valuable to introduce a threshold for engaging the base shard
> count to avoid splitting lowest-level sstables into fragments that are too
> small.
> Once both of these are in place, we can set defaults that better suit all
> node densities, including 10 TiB and beyond, for example:
> - target size of 1 GiB
> - 휆 of 1/3
> - base shard count of 4
> - minimum size 100 MiB
--
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-18534) Make sstable format configurable per table
[
https://issues.apache.org/jira/browse/CASSANDRA-18534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18534:
---
Fix Version/s: 5.x
(was: 5.0)
> Make sstable format configurable per table
> --
>
> Key: CASSANDRA-18534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18534
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema, Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Some SSTable format settings need to be configurable per table for better
> efficiency. This includes:
> - {{row_index_granularity}}
> - {{bloom_filter_fp_chance}}
> - {{crc_check_chance}}
> - {{min/max_index_interval}}
> Some of these are currently configurable using direct properties of tables.
> Having them as format properties makes better sense and should also support
> specifying useable combinations of settings, e.g.
> {code:java}
> CREATE TABLE ... WITH sstable_format = "bti-fast";
> CREATE TABLE ... WITH sstable_format = "bti-small";
> {code}
> where {{bti-fast}} and {{bti-small}} can be defined in {{cassandra.yaml}}
> e.g. as
> {code:java}
> sstable.format.options:
> - bti-fast:
> row_index_granularity: 1kiB
> bloom_filter_fp_chance: 0.01
> - bti-small:
> row_index_granularity: 32kiB
> bloom_filter_fp_chance: 0.1
> {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-18330) Delivery of CEP-21: Transactional Cluster Metadata
[ https://issues.apache.org/jira/browse/CASSANDRA-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18330: --- Reviewers: Benjamin Lerer, Ekaterina Dimitrova, Jacek Lewandowski > Delivery of CEP-21: Transactional Cluster Metadata > -- > > Key: CASSANDRA-18330 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18330 > Project: Cassandra > Issue Type: Epic > Components: Cluster/Membership, Cluster/Schema >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > -- 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-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apac
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774832#comment-17774832
]
Benjamin Lerer edited comment on CASSANDRA-18747 at 10/13/23 9:08 AM:
--
I looked at the code of 4.0 and 4.1 and thinking a bit more about it, I do not
understand why the keyspaces were split into several groups.
Some methods look also wrong. There seem to be some confusions between what is
called distributed keyspaces, non-system keyspaces and local keyspaces.
It feels to me that we should revisit that code more carefully.
was (Author: blerer):
I looked at the code of 4.0 and 4.1 and thinking a bit more about it, I do not
understand why the keyspaces were split into several groups.
Some methods look also wrong. There seems to be some confusions between what is
called distributed keyspaces, non-system keyspaces and local keyspaces.
It feels to me that we should revisit that code more carefully.
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
>
[jira] [Comment Edited] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apac
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774832#comment-17774832
]
Benjamin Lerer edited comment on CASSANDRA-18747 at 10/13/23 9:08 AM:
--
I looked at the code of 4.0 and 4.1 and thinking a bit more about it, I do not
understand why the keyspaces were split into several groups.
Some methods look also wrong. There seems to be some confusions between what is
called distributed keyspaces, non-system keyspaces and local keyspaces.
It feels to me that we should revisit that code more carefully.
was (Author: blerer):
I looked at the code of 4.0 and 4.1 and thinking a bit more about it, I do not
understand why the keyspaces were split into several groups.
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch -
>
[jira] [Commented] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apache.ca
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774832#comment-17774832
]
Benjamin Lerer commented on CASSANDRA-18747:
I looked at the code of 4.0 and 4.1 and thinking a bit more about it, I do not
understand why the keyspaces were split into several groups.
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2475/workflows/2086619e-0f21-464b-a866-84aca516b5e5/jobs/36716/tests]
> test_gcgs_validation -
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1666/testReport/junit/dtest.materialized_views_test/TestMaterializedViews/test_gcgs_validation/]
--
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:
[jira] [Updated] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apache.cass
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18747:
---
Status: Changes Suggested (was: Ready to Commit)
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2475/workflows/2086619e-0f21-464b-a866-84aca516b5e5/jobs/36716/tests]
> test_gcgs_validation -
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1666/testReport/junit/dtest.materialized_views_test/TestMaterializedViews/test_gcgs_validation/]
--
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-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apache.ca
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774828#comment-17774828
]
Benjamin Lerer commented on CASSANDRA-18747:
It seems to me that the proposed solution is going in the opposite direction of
where it should go. The issue mainly comes from the fact that we have
duplicated some information in a multithreaded code. Rather than making that
logic more complex we should simplify it an remove the duplication. Looking at
where those 2 variables are used and how they get used I really do not see the
need for the {{distributedAndLocalKeyspaces}} variable. Am I missing something?
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2475/workflows/2086619e-0f21-464b-a866-84aca516b5e5/jobs/36716/tests]
> test_gcgs_validation -
>
[jira] [Commented] (CASSANDRA-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765520#comment-17765520
]
Benjamin Lerer commented on CASSANDRA-18813:
I updated the patch which now:
* removes the {{MultiItemTerminal}} and {{MultiColumnRaw}} interfaces
* represents IN bind marker as {{Terms}} instead of having 2 different
representations (a list of terms and a single {{MultiItemTerminal}}).
* replaces the {{AbstractMarker}} hierachy by the {{Marker}} class
* introduces a new {{MultiElementType}} that becomes a super class of all the
{{CollectionTypes}}, {{TupleType}}, {{UserType}} and {{VectorType}}
(standardizing the {{pack}} and {{unpack}} method names and their modifiers)
* It replaces the {{Value}} and {{DelayedValue}} implementations for the
{{Lists}}, {{Sets}}, {{Maps}}, {{Tuples}}, {{UserTypes}} and {{Vectors}}
classes by the {{MultiElements}} Value and {{DelayedValue}} classes.
CI [Java
11|https://app.circleci.com/pipelines/github/blerer/cassandra/358/workflows/efc7db24-d110-4f45-a273-c71e685b39a5]
and [Java
17|https://app.circleci.com/pipelines/github/blerer/cassandra/358/workflows/deec9a8e-132c-484c-b8dc-496d4a837072]
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
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-16787) Copy from csv file with duration type fields fails to import
[
https://issues.apache.org/jira/browse/CASSANDRA-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763609#comment-17763609
]
Benjamin Lerer commented on CASSANDRA-16787:
The people working on the driver have been a bit overloaded those last years.
Hopefully, things will change once the python driver is donated (hopefully this
year).
I do not personally mind letting this ticket open.
> Copy from csv file with duration type fields fails to import
>
>
> Key: CASSANDRA-16787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16787
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Brijesh Dungarakoti
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: error_cassandra_copy_from_1.JPG,
> error_cassandra_copy_from_2.JPG
>
>
> Getting error:
> {code:java}
> cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv'
> WITH HEADER = FALSE AND NULL='null';
> Using 3 child processes
> Starting copy of users.user_credentials_by_email with columns [email,
> la_duration].
> Failed to make batch statement: Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.)_
> Failed to import 1 rows: TypeError - Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.), given up
> without retries
> Failed to process 1 rows; failed rows written to
> import_users_user_credentials_by_email.err
> Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s
> 0 rows imported from 1 files in 0.431 seconds (0 skipped).
> {code}
> *To Reproduce:*
> {code:java}
> CREATE KEYSPACE users WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor' : 1 } AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (
> email text,
> la_duration duration,
> PRIMARY KEY(email)
> );
> {code}
> create users.csv file with:
> {code:java}
> l...@la.com,8m26s482ms
> {code}
> Run:
> {code:java}
> COPY users.user_credentials_by_email FROM 'users.csv' WITH HEADER = FALSE AND
> NULL='null';
> {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] [Commented] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762716#comment-17762716
]
Benjamin Lerer commented on CASSANDRA-18322:
Rather than doing some type checks on the statement, will it not make sense to
add a {{shouldUseFullyQualifiedTableName}} method to {{CQLStatement}} ? We
could also do it the other way around by flagging statements that do not need
to be prepared.
It seems to me that the patch missed the {{BatchStatement}}.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
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-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18322:
---
Reviewers: Benjamin Lerer
Status: Review In Progress (was: Needs Committer)
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
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-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18813:
---
Test and Documentation Plan: The refactoring does not change the logic and
relies on the existing tests
Status: Patch Available (was: Open)
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
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-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760915#comment-17760915
]
Benjamin Lerer commented on CASSANDRA-18813:
PR:
[https://github.com/apache/cassandra/pull/2655|https://github.com/apache/cassandra/pull/2655]
CI [Java
11|https://app.circleci.com/pipelines/github/blerer/cassandra/350/workflows/cfab461e-8d9c-4f1e-acc1-00d03f11cd53]
and [Java
17|https://app.circleci.com/pipelines/github/blerer/cassandra/350/workflows/311ea931-f109-419c-a358-98fdcb612575]
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
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-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18813:
---
Change Category: Code Clarity
Complexity: Normal
Fix Version/s: 5.x
Reviewers: Ekaterina Dimitrova
Status: Open (was: Triage Needed)
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
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-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18813:
---
Summary: Simplify the bind marker and Term logic (was: Simplify the Bind
Marker and Term logic)
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
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-18813) Simplify the Bind Marker and Term logic
Benjamin Lerer created CASSANDRA-18813:
--
Summary: Simplify the Bind Marker and Term logic
Key: CASSANDRA-18813
URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
Project: Cassandra
Issue Type: Improvement
Components: CQL/Interpreter
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
The current logic around {{Term}} and {{Terms}} classes is confusing specially
with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to handle
different use cases that could be handled simply with the {{Term}} interface.
On top of that IN marker add to the confusion because the are represented as
single Term where in practice they are a set of terms. Representing them as a
{{Terms}} could simplify the way we handle IN restrictions.
The goal of this ticket is:
* to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
* Represents IN bind marker as {{Terms}} instead of having 2 different
representations (a list of terms and a single {{MultiItemTerminal}}.
* Simplify the {{AbstractMarker}} hierachy
--
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-18579) No link to source packages
[ https://issues.apache.org/jira/browse/CASSANDRA-18579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18579: --- Status: Ready to Commit (was: Review In Progress) > No link to source packages > -- > > Key: CASSANDRA-18579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18579 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Sebb >Assignee: Michael Semb Wever >Priority: Normal > Labels: policy > > I could not find a link to download source releases. > They should be provided alongside the binary releases. -- 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-18579) No link to source packages
[ https://issues.apache.org/jira/browse/CASSANDRA-18579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754969#comment-17754969 ] Benjamin Lerer commented on CASSANDRA-18579: Thanks [~mck]. The patch looks good to me. > No link to source packages > -- > > Key: CASSANDRA-18579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18579 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Sebb >Assignee: Michael Semb Wever >Priority: Normal > Labels: policy > > I could not find a link to download source releases. > They should be provided alongside the binary releases. -- 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-18579) No link to source packages
[ https://issues.apache.org/jira/browse/CASSANDRA-18579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18579: --- Reviewers: Benjamin Lerer, Benjamin Lerer Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer) Status: Review In Progress (was: Patch Available) > No link to source packages > -- > > Key: CASSANDRA-18579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18579 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Sebb >Assignee: Michael Semb Wever >Priority: Normal > Labels: policy > > I could not find a link to download source releases. > They should be provided alongside the binary releases. -- 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-18579) No link to source packages
[ https://issues.apache.org/jira/browse/CASSANDRA-18579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754148#comment-17754148 ] Benjamin Lerer commented on CASSANDRA-18579: There is a link to the source package for all the versions. Unfortunately it is true that these links are accessible through the archive link which is confusing. > No link to source packages > -- > > Key: CASSANDRA-18579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18579 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Sebb >Priority: Normal > > I could not find a link to download source releases. > They should be provided alongside the binary releases. -- 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-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753947#comment-17753947 ] Benjamin Lerer commented on CASSANDRA-15254: It is :-) > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: Configuration Registry Diagram.png > > Time Spent: 19h 50m > Remaining Estimate: 0h > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/operations. -- 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-17163) High CAS failures in MemtablePool.SubPool.tryAllocate
[
https://issues.apache.org/jira/browse/CASSANDRA-17163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17163:
---
Resolution: Duplicate
Status: Resolved (was: Open)
> High CAS failures in MemtablePool.SubPool.tryAllocate
> -
>
> Key: CASSANDRA-17163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17163
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> In a cluster using {{memtable_allocation_type: offheap_buffers}} which handle
> a high amount of writes we are seeing some high contentions on
> {{MemtablePool.SubPool.tryAllocate}}.
> {code}"MutationStage-561" #5457 daemon prio=5 os_prio=0
> tid=0x7f35dd3cfa50 nid=0x1407a runnable [0x7f2357fd5000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.tryAllocate(MemtablePool.java:159)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.allocate(MemtableAllocator.java:175)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.allocate(SlabAllocator.java:89)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.allocate(ContextAllocator.java:57)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.clone(ContextAllocator.java:47)
> at org.apache.cassandra.db.rows.BufferCell.copy(BufferCell.java:140)
> at
> org.apache.cassandra.utils.memory.AbstractAllocator$CloningBTreeRowBuilder.addCell(AbstractAllocator.java:89)
> at org.apache.cassandra.db.rows.Rows.copy(Rows.java:49)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:370)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:333)
> at org.apache.cassandra.utils.btree.BTree.buildLeaf(BTree.java:195)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:208)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:227)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:254)
> at org.apache.cassandra.utils.btree.BTree.build(BTree.java:177)
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:283)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDeltaInternal(AtomicBTreePartition.java:143)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(AtomicBTreePartition.java:184)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:295)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1335)
> at
> org.apache.cassandra.db.CassandraTableWriteHandler.write(CassandraTableWriteHandler.java:40)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:661)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:513)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:220)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:229)
> at
> org.apache.cassandra.service.StorageProxy$$Lambda$1019/640627333.run(Unknown
> Source)
> at
> org.apache.cassandra.service.StorageProxy$4.runMayThrow(StorageProxy.java:1544)
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable$1.runMayThrow(StorageProxy.java:2314)
> at
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2352)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {code}
> This issue is similar to CASSANDRA-15922.
--
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-18702) Add jmh microbenchmarks to eclipse IDE
[ https://issues.apache.org/jira/browse/CASSANDRA-18702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18702: --- Reviewers: Benjamin Lerer > Add jmh microbenchmarks to eclipse IDE > -- > > Key: CASSANDRA-18702 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18702 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.x > > > Currently jmh tests are not being picked up by the Eclipse IDE. -- 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-18708) Test failure: org.apache.cassandra.tools.StandaloneSplitterWithCQLTesterTest.testNoSnapshotOption-.jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-18708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18708:
---
Reviewers: Benjamin Lerer
> Test failure:
> org.apache.cassandra.tools.StandaloneSplitterWithCQLTesterTest.testNoSnapshotOption-.jdk17
>
>
> Key: CASSANDRA-18708
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18708
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1650/testReport/junit/org.apache.cassandra.tools/StandaloneSplitterWithCQLTesterTest/testNoSnapshotOption__jdk17/]
> h3.
> {code:java}
> Error Message
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> final sun.nio.fs.UnixFileSystem sun.nio.fs.UnixPath.fs accessible: module
> java.base does not "opens sun.nio.fs" to unnamed module @1f28c152 at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172) at
> org.apache.cassandra.utils.concurrent.Ref.getFields(Ref.java:656) at
> org.apache.cassandra.utils.concurrent.Ref$Visitor.traverse(Ref.java:613) at
> org.apache.cassandra.utils.concurrent.Ref$Visitor.run(Ref.java:568) at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at
> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> {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] [Commented] (CASSANDRA-18655) Unfinalise AbstractVirtualTable.select(..) for downstream patches
[
https://issues.apache.org/jira/browse/CASSANDRA-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742328#comment-17742328
]
Benjamin Lerer commented on CASSANDRA-18655:
After thinking a bit more about it, I realised that I am confused by this
ticket.
This ticket is not a proposal for a new virtual table implementation. It is
just a request for removing some {{final}} keywords. As there is no mechanims
to dynamically add virtual tables or virtual keyspaces to the virtual schema
this change is simply useless and confusing.
If we want to allow to plug-in virtual tables, I think that the proposal hould
be done as a CEP where the scope of what we want to allow as well as the API is
clearly defined.
> Unfinalise AbstractVirtualTable.select(..) for downstream patches
> -
>
> Key: CASSANDRA-18655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18655
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> In AbstractVirtualTable the select methods are final. This prevents
> downstream C* engineers from implementing their own virtual tables where the
> select needs to be overridden.
> This is not a C* API and is not intended for C* users and operators.
> Extension of these methods should also clearly marked as experimental with no
> maintenance or compatibility provided from any release to another (including
> patch versions).
> The original proposal for Virtual Tables (CASSANDRA-7622) was to have a table
> "backed by an API, rather than data explicitly managed and stored as
> sstables". A number of people on the ticket supported the eventual idea of
> user-defined Virtual Tables. The consensus was that an incremental approach
> should be taken, where this should not be part of the initial implementation,
> and that use-cases and careful consideration around API security and
> compatibility would be needed.
> The next incremental approach can be to permit downstream patches to
> experiment against an explicitly labelled experimental (non-stable) internal
> code (so to protect the C* community from security and compatibility
> concerns). Such experiments will help smoke out and promote more grounded
> discussions for further work, if so found and desired.
> The patch is two lines: to remove the final keyword from both select(..)
> methods; and adding whatever comment/annotation we need to state their
> experimental/non-stable state and limited audience.
--
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-18655) Unfinalise AbstractVirtualTable.select(..) for downstream patches
[
https://issues.apache.org/jira/browse/CASSANDRA-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740954#comment-17740954
]
Benjamin Lerer commented on CASSANDRA-18655:
If people wish to create their own VirtualTable implementation they can simply
extend the {{VirtualTable}} interface. The {{final}} keyword in
{{AbstractVirtualTable}} is to prevent people extending that class to misuse
it.
??The consensus was that an incremental approach should be taken, where this
should not be part of the initial implementation, and that use-cases and
careful consideration around API security and compatibility would be needed.??
I do not recall such consensus. On the other hand I recall long discussions
that blocked the ticket for around 2 years. In the end the choice was made to
use Virtual tables only for exposing local node internal information and that
is what the current implementation support.
> Unfinalise AbstractVirtualTable.select(..) for downstream patches
> -
>
> Key: CASSANDRA-18655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18655
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> In AbstractVirtualTable the select methods are final. This prevents
> downstream C* engineers from implementing their own virtual tables where the
> select needs to be overridden.
> This is not a C* API and is not intended for C* users and operators.
> Extension of these methods should also clearly marked as experimental with no
> maintenance or compatibility provided from any release to another (including
> patch versions).
> The original proposal for Virtual Tables (CASSANDRA-7622) was to have a table
> "backed by an API, rather than data explicitly managed and stored as
> sstables". A number of people on the ticket supported the eventual idea of
> user-defined Virtual Tables. The consensus was that an incremental approach
> should be taken, where this should not be part of the initial implementation,
> and that use-cases and careful consideration around API security and
> compatibility would be needed.
> The next incremental approach can be to permit downstream patches to
> experiment against an explicitly labelled experimental (non-stable) internal
> code (so to protect the C* community from security and compatibility
> concerns). Such experiments will help smoke out and promote more grounded
> discussions for further work, if so found and desired.
> The patch is two lines: to remove the final keyword from both select(..)
> methods; and adding whatever comment/annotation we need to state their
> experimental/non-stable state and limited audience.
--
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-18584) CEP-29: NOT operator
[ https://issues.apache.org/jira/browse/CASSANDRA-18584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18584: --- Reviewers: Benjamin Lerer > 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] [Updated] (CASSANDRA-18584) CEP-29: NOT operator
[ https://issues.apache.org/jira/browse/CASSANDRA-18584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18584: --- Change Category: Semantic Complexity: Normal Status: Open (was: Triage Needed) > 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-11745) Add bytes limit to queries and paging
[
https://issues.apache.org/jira/browse/CASSANDRA-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730489#comment-17730489
]
Benjamin Lerer commented on CASSANDRA-11745:
After quickly skimming the patch, it feels to me that the is a difference
between the original goal of this ticket and of the patch. My understanding of
[~slebresne] explanation was that the goal of this patch is about allowing the
user to LIMIT by byte and _page_ by byte. What the patch does is to introduce
a way to page by bytes instead of by rows but it seems to use that mechanism
only for 2 scenarios which are internal paging for {{aggregation}}/{{group by}}
queries and for rebuilding secondary indices. The values for those have to be
configured within the config file. It is valuable but different from the
original goal even if the functionality can probably be reused to build those
other functionalities. So we should probably open another ticket with a clear
description of the goal and moved the patch there to avoid confusing people.
The patch being significant in terms of changes. The review will take some time
in my side.
> Add bytes limit to queries and paging
> -
>
> Key: CASSANDRA-11745
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11745
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Richard Low
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For some data models, values may be of very different sizes. When querying
> data, limit by count doesn’t work well and leads to timeouts. It would be
> much better to limit by size of the response, probably by stopping at the
> first row that goes above the limit. This applies to paging too so you can
> safely page through such data without timeout worries.
--
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-11745) Add bytes limit to queries and paging
[ https://issues.apache.org/jira/browse/CASSANDRA-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-11745: --- Reviewers: Benjamin Lerer, Josh McKenzie (was: Josh McKenzie) > Add bytes limit to queries and paging > - > > Key: CASSANDRA-11745 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11745 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Richard Low >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > For some data models, values may be of very different sizes. When querying > data, limit by count doesn’t work well and leads to timeouts. It would be > much better to limit by size of the response, probably by stopping at the > first row that goes above the limit. This applies to paging too so you can > safely page through such data without timeout worries. -- 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-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer edited comment on CASSANDRA-17047 at 6/6/23 12:57 PM:
-
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
was (Author: blerer):
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
>
[jira] [Comment Edited] (CASSANDRA-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer edited comment on CASSANDRA-17047 at 6/6/23 12:56 PM:
-
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
was (Author: blerer):
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
>
[jira] [Comment Edited] (CASSANDRA-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer edited comment on CASSANDRA-17047 at 6/6/23 12:55 PM:
-
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
was (Author: blerer):
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11,
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
>
[jira] [Commented] (CASSANDRA-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer commented on CASSANDRA-17047:
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11,
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[main/:na]
> ...
> {code}
> Note that it doesn't matter if we {{SELECT *}} or {{SELECT id, v1}}
> CASSANDRA-15899 tried to fix the problem when columns are dropped as well as
> when columns are added. Unfortunately the fix introduced an issue and had to
> be reverted in CASSANDRA-16735.
> If the scenario for ADDED columns is tricky, the original scenario for
> DROPPED columns can be solved in a safe way at the {{ColumnFilter}} level.
> By consequence, I think that we should at least solve that scenario.
> [~bdeggleston], [~samt], [~ifesdjeen] does my proposal makes sense to you?
--
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-18566) Avoid unnecessary deserialization of terminal arguments when executing CQL functions
[
https://issues.apache.org/jira/browse/CASSANDRA-18566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18566:
---
Reviewers: Benjamin Lerer
> Avoid unnecessary deserialization of terminal arguments when executing CQL
> functions
>
>
> Key: CASSANDRA-18566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18566
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CQL functions unnecessarily deserialize their terminal arguments on every
> call.
> For example, the function call in {{SELECT mask_inner(column, 1, 0) FROM t}}
> deserializes {{1}} and {{2}} for each returned row. As another example, the
> selector in {{SELECT column * 2 FROM t}} also deserializes {{2}} for each
> returned row.
> The goal of this ticket is to improve the function execution code to avoid
> those deserializations.
--
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-18329) Upgrade jamm
[ https://issues.apache.org/jira/browse/CASSANDRA-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-18329: -- Assignee: Benjamin Lerer > Upgrade jamm > > > Key: CASSANDRA-18329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18329 > Project: Cassandra > Issue Type: Task > Components: Jamm >Reporter: Ekaterina Dimitrova >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Jamm is currently under maintenance that will solve JDK11 issues and enable > it to work with post JDK11+ versions up to JDK17. > This ticket will serve as a placeholder for upgrading Jamm in Cassandra when > the new Jamm release is out. -- 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
