[jira] [Assigned] (CASSANDRA-16664) Log JVM Arguments at in-JVM Test Class Initialization
[
https://issues.apache.org/jira/browse/CASSANDRA-16664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-16664:
---
Assignee: (was: Денис)
> Log JVM Arguments at in-JVM Test Class Initialization
> -
>
> Key: CASSANDRA-16664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16664
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Priority: Normal
> Labels: ghc-lhf, lhf
> Fix For: 4.0.x, 4.x
>
>
> Normal C* startup flows through {{CassandraDaemon.setup()}}, which calls
> {{logSystemInfo()}}, logging JVM arguments and a number of other useful bits
> of information. The in-JVM dtest startup does not flow through
> {{CassandraDaemon.setup()}}, and therefore does not. It would be useful for
> troubleshooting purposes if {{TestBaseImpl}} logged the JVM arguments before
> moving into executing tests.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17818:
Description:
Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
will suggest that information for ck2 is missing. But if you add it it will
still be wrong as "v" cannot be used. So the problem here is really about using
non-clustering column rather than about not providing information about some
clustering column.
The following is example from 3.11, but I think the code is the same in 4.0,
4.1, trunk:
{code:java}
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
CLUSTERING ORDER for column ck1"
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
CLUSTERING ORDER for column ck2"
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
clustering key columns can be defined in CLUSTERING ORDER directive"{code}
We need to be sure that we return to the user the same correct error message in
all three cases and it should be "Only clustering key columns can be defined in
CLUSTERING ORDER directive"
+Additional information for newcomers+
*
[This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
is where we handle the issue incorrectly as proved by the example. The easiest
way to handle this issue would be to check the key set content of
{_}clusteringOrder{_}.
* It would be good also to add more unit tests in
[CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
to cover different cases.
* I suggest we create patch first for 3.11 and then we can propagate it up to
the next versions.
was:
Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
will suggest that information for ck2 is missing. But if you add it it will
still be wrong as "v" cannot be used. So the problem here is really about using
non-clustering column rather than about not providing information about some
clustering column.
The following is example from 3.11, the code is the same in 4.0, 4.1, trunk:
{{}}
{code:java}
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
CLUSTERING ORDER for column ck1"
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
CLUSTERING ORDER for column ck2"
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
clustering key columns can be defined in CLUSTERING ORDER directive"{code}
{{**}}
We need to be sure that we return to the user the same correct error message in
all three cases and it should be "Only clustering key columns can be defined in
CLUSTERING ORDER directive"
+Additional information for newcomers+
*
[This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
is where we handle the issue incorrectly as proved by the example. The easiest
way to handle this issue would be to check the key set content of
{_}clusteringOrder{_}.
* It would be good also to add more unit tests in
[CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
to cover different cases.
* I suggest we create patch first for 3.11 and then we can propagate it up to
the next versions.
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Labels: ghc-lhf
> Fix For: 3.11.x
[jira] [Updated] (CASSANDRA-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17818:
Description:
Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
will suggest that information for ck2 is missing. But if you add it it will
still be wrong as "v" cannot be used. So the problem here is really about using
non-clustering column rather than about not providing information about some
clustering column.
The following is example from 3.11, but the code is the same in 4.0, 4.1, trunk:
{code:java}
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
CLUSTERING ORDER for column ck1"
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
CLUSTERING ORDER for column ck2"
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
clustering key columns can be defined in CLUSTERING ORDER directive"{code}
We need to be sure that we return to the user the same correct error message in
all three cases and it should be "Only clustering key columns can be defined in
CLUSTERING ORDER directive"
+Additional information for newcomers+
*
[This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
is where we handle the issue incorrectly as proved by the example. The easiest
way to handle this issue would be to check the key set content of
{_}clusteringOrder{_}.
* It would be good also to add more unit tests in
[CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
to cover different cases.
* I suggest we create patch first for 3.11 and then we can propagate it up to
the next versions.
was:
Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
will suggest that information for ck2 is missing. But if you add it it will
still be wrong as "v" cannot be used. So the problem here is really about using
non-clustering column rather than about not providing information about some
clustering column.
The following is example from 3.11, but I think the code is the same in 4.0,
4.1, trunk:
{code:java}
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
CLUSTERING ORDER for column ck1"
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
CLUSTERING ORDER for column ck2"
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
clustering key columns can be defined in CLUSTERING ORDER directive"{code}
We need to be sure that we return to the user the same correct error message in
all three cases and it should be "Only clustering key columns can be defined in
CLUSTERING ORDER directive"
+Additional information for newcomers+
*
[This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
is where we handle the issue incorrectly as proved by the example. The easiest
way to handle this issue would be to check the key set content of
{_}clusteringOrder{_}.
* It would be good also to add more unit tests in
[CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
to cover different cases.
* I suggest we create patch first for 3.11 and then we can propagate it up to
the next versions.
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Labels: ghc-lhf
> Fix For: 3.11.x, 4.0.x, 4
[jira] [Updated] (CASSANDRA-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17818:
Fix Version/s: 3.11.x
4.0.x
4.1.x
4.x
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Labels: ghc-lhf
> Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, the code is the same in 4.0, 4.1, trunk:
> {{}}
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> {{**}}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17818:
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Component/s: CQL/Syntax
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Labels: ghc-lhf
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, the code is the same in 4.0, 4.1, trunk:
> {{}}
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> {{**}}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17818:
Labels: ghc-lhf (was: ghc-lhf uhf)
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Labels: ghc-lhf
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, the code is the same in 4.0, 4.1, trunk:
> {{}}
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> {{**}}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
Ekaterina Dimitrova created CASSANDRA-17818:
---
Summary: Fix error message handling when trying to use CLUSTERING
ORDER with non-clustering column
Key: CASSANDRA-17818
URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
will suggest that information for ck2 is missing. But if you add it it will
still be wrong as "v" cannot be used. So the problem here is really about using
non-clustering column rather than about not providing information about some
clustering column.
The following is example from 3.11, the code is the same in 4.0, 4.1, trunk:
{{}}
{code:java}
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
CLUSTERING ORDER for column ck1"
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
CLUSTERING ORDER for column ck2"
cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY KEY
((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
clustering key columns can be defined in CLUSTERING ORDER directive"{code}
{{**}}
We need to be sure that we return to the user the same correct error message in
all three cases and it should be "Only clustering key columns can be defined in
CLUSTERING ORDER directive"
+Additional information for newcomers+
*
[This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
is where we handle the issue incorrectly as proved by the example. The easiest
way to handle this issue would be to check the key set content of
{_}clusteringOrder{_}.
* It would be good also to add more unit tests in
[CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
to cover different cases.
* I suggest we create patch first for 3.11 and then we can propagate it up to
the next versions.
--
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-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17818:
Labels: ghc-lhf uhf (was: )
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Labels: ghc-lhf, uhf
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, the code is the same in 4.0, 4.1, trunk:
> {{}}
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> {{**}}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
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-17817) Fix upgrade test test_collection_function on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17817: Description: The upgrade test test_collection_functio is failing on trunk post CASSANDRA-8877 For unknown to me reason Jenkins shows it started failing post CASSANDRA-17575 which does not make sense as that ticket improved documentation. Bisecting in Circle CI points to CASSANDRA-8877 The test run in a loop before CASSANDRA-8877 [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d] , it consistently fails with CASSANDRA-8877 [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. CC [~adelapena], [~ycai] and [~b.le...@gmail.com] was: The upgrade test test_collection_functio is failing on trunk post CASSANDRA-8877 For unknown to me reason Jenkins shows it started failing post CASSANDRA-17575 which does not make sense as that ticket improved documentation. Bisecting in Circle CI points to CASSANDRA-8877 The test run in a loop before CASSANDRA-8877 [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d , it consistently fails with CASSANDRA-8877 [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. CC [~adelapena], [~ycai] and [~b.le...@gmail.com] > Fix upgrade test test_collection_function on trunk > -- > > Key: CASSANDRA-17817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17817 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > The upgrade test test_collection_functio is failing on trunk post > CASSANDRA-8877 > For unknown to me reason Jenkins shows it started failing post > CASSANDRA-17575 which does not make sense as that ticket improved > documentation. > Bisecting in Circle CI points to CASSANDRA-8877 > The test run in a loop before CASSANDRA-8877 > [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d] > , it consistently fails with CASSANDRA-8877 > [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. > CC [~adelapena], [~ycai] and [~b.le...@gmail.com] -- 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-17817) Fix upgrade test test_collection_function on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579970#comment-17579970 ] Ekaterina Dimitrova commented on CASSANDRA-17817: - Cool, thanks for the quick "fix" :) > Fix upgrade test test_collection_function on trunk > -- > > Key: CASSANDRA-17817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17817 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > The upgrade test test_collection_functio is failing on trunk post > CASSANDRA-8877 > For unknown to me reason Jenkins shows it started failing post > CASSANDRA-17575 which does not make sense as that ticket improved > documentation. > Bisecting in Circle CI points to CASSANDRA-8877 > The test run in a loop before CASSANDRA-8877 > [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d > , it consistently fails with CASSANDRA-8877 > [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. > CC [~adelapena], [~ycai] and [~b.le...@gmail.com] -- 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-17817) Fix upgrade test test_collection_function on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17817: Reviewers: Andres de la Peña (was: Andres de la Peña, Ekaterina Dimitrova) > Fix upgrade test test_collection_function on trunk > -- > > Key: CASSANDRA-17817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17817 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > The upgrade test test_collection_functio is failing on trunk post > CASSANDRA-8877 > For unknown to me reason Jenkins shows it started failing post > CASSANDRA-17575 which does not make sense as that ticket improved > documentation. > Bisecting in Circle CI points to CASSANDRA-8877 > The test run in a loop before CASSANDRA-8877 > [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d > , it consistently fails with CASSANDRA-8877 > [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. > CC [~adelapena], [~ycai] and [~b.le...@gmail.com] -- 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-17817) Fix upgrade test test_collection_function on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17817: Reviewers: Andres de la Peña, Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > Fix upgrade test test_collection_function on trunk > -- > > Key: CASSANDRA-17817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17817 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > The upgrade test test_collection_functio is failing on trunk post > CASSANDRA-8877 > For unknown to me reason Jenkins shows it started failing post > CASSANDRA-17575 which does not make sense as that ticket improved > documentation. > Bisecting in Circle CI points to CASSANDRA-8877 > The test run in a loop before CASSANDRA-8877 > [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d > , it consistently fails with CASSANDRA-8877 > [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. > CC [~adelapena], [~ycai] and [~b.le...@gmail.com] -- 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-17817) Fix upgrade test test_collection_function on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17817: Test and Documentation Plan: Tests ignored, not valid anymore Status: Patch Available (was: In Progress) > Fix upgrade test test_collection_function on trunk > -- > > Key: CASSANDRA-17817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17817 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > The upgrade test test_collection_functio is failing on trunk post > CASSANDRA-8877 > For unknown to me reason Jenkins shows it started failing post > CASSANDRA-17575 which does not make sense as that ticket improved > documentation. > Bisecting in Circle CI points to CASSANDRA-8877 > The test run in a loop before CASSANDRA-8877 > [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d > , it consistently fails with CASSANDRA-8877 > [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. > CC [~adelapena], [~ycai] and [~b.le...@gmail.com] -- 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-17817) Fix upgrade test test_collection_function on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-17817: --- Assignee: Brandon Williams > Fix upgrade test test_collection_function on trunk > -- > > Key: CASSANDRA-17817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17817 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > The upgrade test test_collection_functio is failing on trunk post > CASSANDRA-8877 > For unknown to me reason Jenkins shows it started failing post > CASSANDRA-17575 which does not make sense as that ticket improved > documentation. > Bisecting in Circle CI points to CASSANDRA-8877 > The test run in a loop before CASSANDRA-8877 > [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d > , it consistently fails with CASSANDRA-8877 > [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. > CC [~adelapena], [~ycai] and [~b.le...@gmail.com] -- 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-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579893#comment-17579893
]
Ekaterina Dimitrova edited comment on CASSANDRA-17677 at 8/16/22 12:24 AM:
---
In my humble opinion this looks really good! Docs, tests, etc..
-I left only one comment about a description, otherwise- I am +1. We need only
CHANGES.txt and NEWS.txt (deprecation section and to explain we have changed
the new flags for entire-stable as this is not compatible with alpha1 version)
I think we are only looking for [~yifanc] final comment (I guess he wants to
make final check after the discussions and the latest changes?)
Last but not least, as far as I can tell the patch is the same for 4.1 and
trunk so I reviewed only the 4.1 PR. Please let me know if that was not the
case and there is something in addition I need to look at.
was (Author: e.dimitrova):
In my humble opinion this looks really good! Docs, tests, etc..
I left only one comment about a description, otherwise I am +1. We need only
CHANGES.txt and NEWS.txt (deprecation section and to explain we have changed
the new flags for entire-stable as this is not compatible with alpha1 version)
I think we are only looking for [~yifanc] final comment (I guess he wants to
make final check after the discussions and the latest changes?)
Last but not least, as far as I can tell the patch is the same for 4.1 and
trunk so I reviewed only the 4.1 PR. Please let me know if that was not the
case and there is something in addition I need to look at.
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoaderOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected from the Cassandra config parameters and
> unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{and add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579966#comment-17579966 ] Alex Lourie commented on CASSANDRA-13010: - [~smiklosovic] Yea, go ahead, I don't plan to work on it. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Normal > Labels: 4.0-feature-freeze-review-requested, lhf > Attachments: cleanup.png, multiple operations.png > > -- 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] (CASSANDRASC-41) Implement toString for Range in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579965#comment-17579965 ] Dinesh Joshi commented on CASSANDRASC-41: - +1 > Implement toString for Range in Sidecar > --- > > Key: CASSANDRASC-41 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-41 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > The toString method for Range is not implemented, leading to the ranges > objects being logged incorrectly. We should add the toString implementation. -- 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-17817) Fix upgrade test test_collection_function on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-17817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579963#comment-17579963
]
Andres de la Peña commented on CASSANDRA-17817:
---
Oh, I totally missed that upgrade test. Indeed the test is not valid after
CASSANDRA-8877, since it's exclusively verifying that we cannot use writetime
and ttl functions on collections. This is precisely what that ticket changed.
CASSANDRA-8877 includes [a new upgrade
test|https://github.com/apache/cassandra/blob/c8c8635a4c902ef051a46845919a5430f8d71e3f/test/distributed/org/apache/cassandra/distributed/upgrade/MixedModeWritetimeOrTTLTest.java]
covering that and a few additional cases, so I think we can safely ignore
{{test_collection_function}} after 4.1, as proposed.
> Fix upgrade test test_collection_function on trunk
> --
>
> Key: CASSANDRA-17817
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17817
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> The upgrade test test_collection_functio is failing on trunk post
> CASSANDRA-8877
> For unknown to me reason Jenkins shows it started failing post
> CASSANDRA-17575 which does not make sense as that ticket improved
> documentation.
> Bisecting in Circle CI points to CASSANDRA-8877
> The test run in a loop before CASSANDRA-8877
> [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d
> , it consistently fails with CASSANDRA-8877
> [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps].
> CC [~adelapena], [~ycai] and [~b.le...@gmail.com]
--
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-17817) Fix upgrade test test_collection_function on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579953#comment-17579953 ] Brandon Williams commented on CASSANDRA-17817: -- I'm pretty sure this test isn't valid after CASSANDRA-8877, so [here|https://github.com/driftx/cassandra-dtest/commit/376b79f169b532f5a52152a7701213b33af4be17] is a simple patch to ignore it after 4.1. [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1872/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1872/pipeline] > Fix upgrade test test_collection_function on trunk > -- > > Key: CASSANDRA-17817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17817 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > The upgrade test test_collection_functio is failing on trunk post > CASSANDRA-8877 > For unknown to me reason Jenkins shows it started failing post > CASSANDRA-17575 which does not make sense as that ticket improved > documentation. > Bisecting in Circle CI points to CASSANDRA-8877 > The test run in a loop before CASSANDRA-8877 > [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d > , it consistently fails with CASSANDRA-8877 > [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. > CC [~adelapena], [~ycai] and [~b.le...@gmail.com] -- 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-17719) CEP-15: (C*) Multi-partition transaction CQL support
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579952#comment-17579952
]
Caleb Rackliffe commented on CASSANDRA-17719:
-
Updated the main description to include recent evolution of the syntax from the
mailing list.
> CEP-15: (C*) Multi-partition transaction CQL support
>
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> I haven't seen an example of an unconditional update (ie: not contained in an
> if block), but I don't see any reason not to support them. Though they don't
> need to be delivered in v1.
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as a starting point, a source of ideas for approaches, or not
[jira] [Updated] (CASSANDRA-17719) CEP-15: (C*) Multi-partition transaction CQL support
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Description:
The dev list thread regarding CQL transaction support seems to have converged
on a syntax.
The thread is here:
[https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
The message proposing the syntax ultimately agreed on is here:
[https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
I'll describe my understanding of the agreed syntax here for, but I'd suggest
reading through the thread.
The example query is this:
{code:sql}
BEGIN TRANSACTION
LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
SELECT car.is_running, car.miles_driven;
IF car.is_running THEN
UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
END IF
COMMIT TRANSACTION
{code}
Sections are described below, and we want to require the statement enforces an
order on the different types of clauses. First, assignments, then select(s),
then conditional updates. This may be relaxed in the future, but is meant to
prevent users from interleaving updates and assignments and expecting read your
own write behavior that we don't want to support in v1.
h3. Reference assignments
{code:sql}
LET car = (SELECT miles_driven, is_running FROM cars WHERE
model=’pinto’){code}
The first part is basically assigning the result of a SELECT statement to a
named reference that can be used in updates/conditions and be returned to the
user. Tuple names belong to a global scope and must not clash with other LET
statements or update statements (more on that in the updates section). Also,
the select statement must either be a point read, with all primary key columns
defined, or explicitly set a limit of 1.
h3. Selection
Data to returned to client. Currently, we're only supporting a single select
statement. Either a normal select statement, or one returning values assigned
by LET statements as shown in the example. Ultimately we'll want to support
multiple select statements and returning the results to the client. Although
that will require a protocol change.
h3. Updates
Normal inserts/updates/deletes with the following extensions:
* Inserts and updates can reference values assigned earlier in the statement
* Updates can reference their own columns:
{code:java}
miles_driven = miles_driven + 30{code}
- or -
{code:java}
miles_driven += 30{code}
These will of course need to generate any required reads behind the scenes.
There's no precedence of table vs reference names, so if a relevant column name
and reference name conflict, the query needs to fail to parse.
h3. If blocks
{code:sql}
IF THEN
;
;
END IF
{code}
For v1, we only need to support a single condition in the format above. In the
future, we'd like to support multiple branches with multiple conditions like:
{code:sql}
IF THEN
;
;
ELSE IF THEN
;
ELSE
;
END IF
{code}
I haven't seen an example of an unconditional update (ie: not contained in an
if block), but I don't see any reason not to support them. Though they don't
need to be delivered in v1.
h3. Conditions
Comparisons of value references to literals or other references. IS NULL / IS
NOT NULL also needs to be supported. Multiple comparisons need to be supported,
but v1 only needs to support AND'ing them together
{code:java}
Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
= 5
IS NOT NULL
IF car IS NOT NULL AND car.miles_driven > 30
IF car.miles_driven = user.miles_driven{code}
(Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
individually dereferenced columns.)
h3. Implementation notes
I have a proof of concept I'd created to demo the initially proposed syntax
here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It could
be used as a starting point, a source of ideas for approaches, or not used at
all. The main thing to keep in mind is that value references prevent creating
read commands and mutations until later in the transaction process, and
potentially on another machine, which means we can't create accord transactions
with fully formed mutations and read commands. CQL statements and terms are
also not serializable, and would require a ton of work to properly serialize,
so there will need to be some intermediate stage that can be serialized.
was:
The dev list thread regarding CQL transaction support seems to have converged
on a syntax.
The thread is here:
[https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
The message proposing the syntax ultimately agreed on is here:
[https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
I'l
[jira] [Updated] (CASSANDRA-17719) CEP-15: (C*) Multi-partition transaction CQL support
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Description:
The dev list thread regarding CQL transaction support seems to have converged
on a syntax.
The thread is here:
[https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
The message proposing the syntax ultimately agreed on is here:
[https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
I'll describe my understanding of the agreed syntax here for, but I'd suggest
reading through the thread.
The example query is this:
{code:sql}
BEGIN TRANSACTION
LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
SELECT car.is_running, car.miles_driven
IF car.is_running THEN
UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
END IF
COMMIT TRANSACTION
{code}
Sections are described below, and we want to require the statement enforces an
order on the different types of clauses. First, assignments, then select(s),
then conditional updates. This may be relaxed in the future, but is meant to
prevent users from interleaving updates and assignments and expecting read your
own write behavior that we don't want to support in v1.
h3. Reference assignments
{code:sql}
LET car = (SELECT miles_driven, is_running FROM cars WHERE
model=’pinto’){code}
The first part is basically assigning the result of a SELECT statement to a
named reference that can be used in updates/conditions and be returned to the
user. Tuple names belong to a global scope and must not clash with other LET
statements or update statements (more on that in the updates section). Also,
the select statement must either be a point read, with all primary key columns
defined, or explicitly set a limit of 1.
h3. Selection
Data to returned to client. Currently, we're only supporting a single select
statement. Either a normal select statement, or one returning values assigned
by LET statements as shown in the example. Ultimately we'll want to support
multiple select statements and returning the results to the client. Although
that will require a protocol change.
h3. Updates
Normal inserts/updates/deletes with the following extensions:
* Inserts and updates can reference values assigned earlier in the statement
* Updates can reference their own columns:
{code:java}
miles_driven = miles_driven + 30{code}
- or -
{code:java}
miles_driven += 30{code}
These will of course need to generate any required reads behind the scenes.
There's no precedence of table vs reference names, so if a relevant column name
and reference name conflict, the query needs to fail to parse.
h3. If blocks
{code:sql}
IF THEN
;
;
END IF
{code}
For v1, we only need to support a single condition in the format above. In the
future, we'd like to support multiple branches with multiple conditions like:
{code:sql}
IF THEN
;
;
ELSE IF THEN
;
ELSE
;
END IF
{code}
I haven't seen an example of an unconditional update (ie: not contained in an
if block), but I don't see any reason not to support them. Though they don't
need to be delivered in v1.
h3. Conditions
Comparisons of value references to literals or other references. IS NULL / IS
NOT NULL also needs to be supported. Multiple comparisons need to be supported,
but v1 only needs to support AND'ing them together
{code:java}
Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
= 5
IS NOT NULL
IF car IS NOT NULL AND car.miles_driven > 30
IF car.miles_driven = user.miles_driven{code}
(Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
individually dereferenced columns.)
h3. Implementation notes
I have a proof of concept I'd created to demo the initially proposed syntax
here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It could
be used as a starting point, a source of ideas for approaches, or not used at
all. The main thing to keep in mind is that value references prevent creating
read commands and mutations until later in the transaction process, and
potentially on another machine, which means we can't create accord transactions
with fully formed mutations and read commands. CQL statements and terms are
also not serializable, and would require a ton of work to properly serialize,
so there will need to be some intermediate stage that can be serialized.
was:
The dev list thread regarding CQL transaction support seems to have converged
on a syntax.
The thread is here:
[https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
The message proposing the syntax ultimately agreed on is here:
[https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
I'
[jira] [Commented] (CASSANDRA-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579939#comment-17579939
]
Ekaterina Dimitrova commented on CASSANDRA-17677:
-
I figured out what happened with test_collection_function and opened a ticket
CASSANDRA-17817
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoaderOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected from the Cassandra config parameters and
> unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{and add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
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-17817) Fix upgrade test test_collection_function on trunk
Ekaterina Dimitrova created CASSANDRA-17817: --- Summary: Fix upgrade test test_collection_function on trunk Key: CASSANDRA-17817 URL: https://issues.apache.org/jira/browse/CASSANDRA-17817 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova The upgrade test test_collection_functio is failing on trunk post CASSANDRA-8877 For unknown to me reason Jenkins shows it started failing post CASSANDRA-17575 which does not make sense as that ticket improved documentation. Bisecting in Circle CI points to CASSANDRA-8877 The test run in a loop before CASSANDRA-8877 [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d , it consistently fails with CASSANDRA-8877 [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. CC [~adelapena], [~ycai] and [~b.le...@gmail.com] -- 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-17817) Fix upgrade test test_collection_function on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17817: Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: CI Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Fix upgrade test test_collection_function on trunk > -- > > Key: CASSANDRA-17817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17817 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > The upgrade test test_collection_functio is failing on trunk post > CASSANDRA-8877 > For unknown to me reason Jenkins shows it started failing post > CASSANDRA-17575 which does not make sense as that ticket improved > documentation. > Bisecting in Circle CI points to CASSANDRA-8877 > The test run in a loop before CASSANDRA-8877 > [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d > , it consistently fails with CASSANDRA-8877 > [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. > CC [~adelapena], [~ycai] and [~b.le...@gmail.com] -- 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-17817) Fix upgrade test test_collection_function on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17817: Fix Version/s: 4.x > Fix upgrade test test_collection_function on trunk > -- > > Key: CASSANDRA-17817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17817 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > The upgrade test test_collection_functio is failing on trunk post > CASSANDRA-8877 > For unknown to me reason Jenkins shows it started failing post > CASSANDRA-17575 which does not make sense as that ticket improved > documentation. > Bisecting in Circle CI points to CASSANDRA-8877 > The test run in a loop before CASSANDRA-8877 > [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d > , it consistently fails with CASSANDRA-8877 > [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps]. > CC [~adelapena], [~ycai] and [~b.le...@gmail.com] -- 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
[cassandra-website] branch asf-staging updated (626ff7b4 -> 7de8f7c6)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 626ff7b4 generate docs for 930e594a new 7de8f7c6 generate docs for 930e594a This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (626ff7b4) \ N -- N -- N refs/heads/asf-staging (7de8f7c6) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17805) When doing a host replacement, we need to check that the node is a live node before failing with "Cannot replace a live node..."
[
https://issues.apache.org/jira/browse/CASSANDRA-17805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17805:
--
Fix Version/s: 4.2
(was: 4.x)
Since Version: 2.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/05eb476c498d64dcfdb6542da64b789195c9a6d7
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> When doing a host replacement, we need to check that the node is a live node
> before failing with "Cannot replace a live node..."
>
>
> Key: CASSANDRA-17805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17805
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, during a node replacement, we check that the node has not updated
> gossip for a configured {{ring_delay}} amount of time (defaults to 30
> seconds). If we see an update from the node that we are replacing in less
> than the configured time, we throw a {{UnsupportedOperationException}} with
> message {{Cannot replace a live node...}}. However, we never check whether
> the node is reporting as alive or not alive.
> We need an additional check to ensure that the node being replaced is
> reported as live; and only then throw the {{UnsupportedOperationException}}
--
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
[cassandra] branch trunk updated: When doing a host replacement, we need to check that the node is a live node before failing with "Cannot replace a live node..."
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 9184dd5a99 When doing a host replacement, we need to check that the
node is a live node before failing with "Cannot replace a live node..."
9184dd5a99 is described below
commit 9184dd5a998366dc2b5c18d4954b13b033efcf80
Author: Francisco Guerrero
AuthorDate: Mon Aug 15 09:23:56 2022 -0700
When doing a host replacement, we need to check that the node is a live
node before failing with "Cannot replace a live node..."
patch by Francisco Guerrero; reviewed by Brandon Williams, David Capwell
for CASSANDRA-17805
---
CHANGES.txt | 1 +
src/java/org/apache/cassandra/service/StorageService.java | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index dd09b25c56..7dce2b90bd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * When doing a host replacement, we need to check that the node is a live
node before failing with "Cannot replace a live node..." (CASSANDRA-17805)
* Add support to generate a One-Shot heap dump on unhandled exceptions
(CASSANDRA-17795)
* Rate-limit new client connection auth setup to avoid overwhelming bcrypt
(CASSANDRA-17812)
* DataOutputBuffer#scratchBuffer can use off-heap or on-heap memory as a
means to control memory allocations (CASSANDRA-16471)
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index ba04ccec91..b7756c0c21 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -1855,14 +1855,23 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
}
// check for operator errors...
+long nanoDelay = MILLISECONDS.toNanos(ringTimeoutMillis);
for (Token token : bootstrapTokens)
{
InetAddressAndPort existing =
tokenMetadata.getEndpoint(token);
if (existing != null)
{
-long nanoDelay = ringTimeoutMillis * 100L;
-if
(Gossiper.instance.getEndpointStateForEndpoint(existing).getUpdateTimestamp() >
(nanoTime() - nanoDelay))
+EndpointState endpointStateForExisting =
Gossiper.instance.getEndpointStateForEndpoint(existing);
+long updateTimestamp =
endpointStateForExisting.getUpdateTimestamp();
+long allowedDelay = nanoTime() - nanoDelay;
+
+// if the node was updated within the ring delay or
the node is alive, we should fail
+if (updateTimestamp > allowedDelay ||
endpointStateForExisting.isAlive())
+{
+logger.error("Unable to replace node for token={}.
The node is reporting as {}alive with updateTimestamp={}, allowedDelay={}",
+ token,
endpointStateForExisting.isAlive() ? "" : "not ", updateTimestamp,
allowedDelay);
throw new UnsupportedOperationException("Cannot
replace a live node... ");
+}
collisions.add(existing);
}
else
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579893#comment-17579893
]
Ekaterina Dimitrova commented on CASSANDRA-17677:
-
In my humble opinion this looks really good! Docs, tests, etc..
I left only one comment about a description, otherwise I am +1. We need only
CHANGES.txt and NEWS.txt (deprecation section and to explain we have changed
the new flags for entire-stable as this is not compatible with alpha1 version)
I think we are only looking for [~yifanc] final comment (I guess he wants to
make final check after the discussions and the latest changes?)
Last but not least, as far as I can tell the patch is the same for 4.1 and
trunk so I reviewed only the 4.1 PR. Please let me know if that was not the
case and there is something in addition I need to look at.
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoaderOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected from the Cassandra config parameters and
> unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{and add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
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
[cassandra-website] branch asf-staging updated (f678d097 -> 626ff7b4)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard f678d097 generate docs for 930e594a new 626ff7b4 generate docs for 930e594a This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (f678d097) \ N -- N -- N refs/heads/asf-staging (626ff7b4) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents
[
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579888#comment-17579888
]
Caleb Rackliffe commented on CASSANDRA-17804:
-
I dropped a couple nits in the PR, but LGTM overall. I guess the difficulty
here is that you can't strictly guess how long the restart will take, and
therefore can't know when the first check on {{listsnapshots}} is irrelevant.
The only alternative I could see is inspecting the stdout, pulling a timestamp
of some kind from it, and ignoring the check on the drop prefix in the first
assert if too much time had passed.
> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>
> My guess is that in some resource constrained environment, even the first
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In
> other words, we skip to the state of the world the last assertion in the test
> is checking.
--
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-17816) WEBSITE - link fix for "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17816: - Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/159 > WEBSITE - link fix for "Apache Cassandra 4.1: Configuration Standardization" > > > Key: CASSANDRA-17816 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17816 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with fixing an broken link on > the blog "Apache Cassandra 4.1: Configuration Standardization" -- 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-17816) WEBSITE - link fix for "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17816: --- Labels: pull-request-available (was: ) > WEBSITE - link fix for "Apache Cassandra 4.1: Configuration Standardization" > > > Key: CASSANDRA-17816 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17816 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with fixing an broken link on > the blog "Apache Cassandra 4.1: Configuration Standardization" -- 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-17816) WEBSITE - link fix for "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17816: - Test and Documentation Plan: Fixing the "documentation" link > WEBSITE - link fix for "Apache Cassandra 4.1: Configuration Standardization" > > > Key: CASSANDRA-17816 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17816 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with fixing an broken link on > the blog "Apache Cassandra 4.1: Configuration Standardization" -- 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-17816) WEBSITE - link fix for "Apache Cassandra 4.1: Configuration Standardization"
[ https://issues.apache.org/jira/browse/CASSANDRA-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17816: - Change Category: Semantic Complexity: Normal Status: Open (was: Triage Needed) > WEBSITE - link fix for "Apache Cassandra 4.1: Configuration Standardization" > > > Key: CASSANDRA-17816 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17816 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with fixing an broken link on > the blog "Apache Cassandra 4.1: Configuration Standardization" -- 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-17816) WEBSITE - link fix for "Apache Cassandra 4.1: Configuration Standardization"
Diogenese Topper created CASSANDRA-17816: Summary: WEBSITE - link fix for "Apache Cassandra 4.1: Configuration Standardization" Key: CASSANDRA-17816 URL: https://issues.apache.org/jira/browse/CASSANDRA-17816 Project: Cassandra Issue Type: Task Components: Documentation/Blog Reporter: Diogenese Topper This ticket is to capture the work associated with fixing an broken link on the blog "Apache Cassandra 4.1: Configuration Standardization" -- 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-17599) Update how_to_commit documentation with lost updates from in-tree repo
[ https://issues.apache.org/jira/browse/CASSANDRA-17599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579857#comment-17579857 ] Michael Semb Wever commented on CASSANDRA-17599: Yes! Taking a quick look, if you wanted to, the style/format of the content could be improved as well. Things like * numbered steps, or more condensed code blocks, * bold "Tips", optionally with an "tip" icon, but generally just making things a bit more readable, e.g. see the [original github page|https://github.com/apache/cassandra/blob/1fce84f9833bd62227dbf8f5d063935457dbc18e/doc/source/development/how_to_commit.rst] which i think is a lot more digestable. But this is completely optional, the patch is +1 already from me. > Update how_to_commit documentation with lost updates from in-tree repo > -- > > Key: CASSANDRA-17599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17599 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Michael Semb Wever >Priority: Normal > Attachments: how_to_commit.patch > > > When the > [how_to_commit.rst|https://github.com/apache/cassandra/blob/1fce84f9833bd62227dbf8f5d063935457dbc18e/doc/source/development/how_to_commit.rst] > page got migrated and moved to the > [cassandra-website|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc] > repo, new edits were not carried over. > cassandra-website/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc > > needs to be updated so it reads like > https://github.com/apache/cassandra/blob/1fce84f9833bd62227dbf8f5d063935457dbc18e/doc/source/development/how_to_commit.rst > It should also be updated to include latest release branches (ref: > CASSANDRA-17589 ) -- 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
[cassandra-website] branch asf-staging updated (cd3a1100 -> f678d097)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard cd3a1100 generate docs for 930e594a new f678d097 generate docs for 930e594a This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (cd3a1100) \ N -- N -- N refs/heads/asf-staging (f678d097) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../cassandra/configuration/cass_yaml_file.html| 36 +++-- .../cassandra/configuration/cass_yaml_file.html| 36 +++-- .../cassandra/configuration/cass_yaml_file.html| 36 +++-- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078 bytes 5 files changed, 103 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents
[
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17804:
Reviewers: Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Status: Review In Progress (was: Patch Available)
> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> See
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>
> My guess is that in some resource constrained environment, even the first
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In
> other words, we skip to the state of the world the last assertion in the test
> is checking.
--
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-17778) WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu
[ https://issues.apache.org/jira/browse/CASSANDRA-17778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17778: Reviewers: Caleb Rackliffe, Ekaterina Dimitrova (was: Ekaterina Dimitrova) Status: Review In Progress (was: Patch Available) > WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu > -- > > Key: CASSANDRA-17778 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17778 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1.x, 4.x > > > There is no way to navigate to the new configuration page for CASSANDRA-15234 > ([Liberating cassandra.yaml Parameters' Names from Their > Units|https://cassandra.apache.org/doc/trunk/cassandra/new/configuration.html]) > because it is not referenced anywhere. > Unless someone has bookmarked the page, there is no way to find it on the > site. > Other doc changes expected: > * Add a small table with supported units per type as currently we list only > the duration's ones and min units for old parameters. We list the supported > units only in NEWS.txt. > * Add info about the RuntimeExceptions we introduced in CASSANDRA-17725 for > a few deprecated JMX getters. > * Add a note for Cassandra developers - "Please ensure that any JMX > setters/getters update the Config class properties and not some local copies. > Settings Virtual Table reports the configuration loaded at any time from the > Config class." -- 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-10789) Allow DBAs to kill individual client sessions from certain IP(s) and temporarily block subsequent connections without bouncing JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579800#comment-17579800 ] Stefan Miklosovic commented on CASSANDRA-10789: --- I would like to continue to work on this patch, I briefly went over it and it seems in quite a good shape. Has something changed in the meanwhile which would block this feature to be finished? [~aweisberg] [~jjirsa] > Allow DBAs to kill individual client sessions from certain IP(s) and > temporarily block subsequent connections without bouncing JVM > -- > > Key: CASSANDRA-10789 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10789 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination >Reporter: Wei Deng >Assignee: Damien Stevenson >Priority: Normal > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > Attachments: 10789-trunk-dtest.txt, 10789-trunk.txt > > > In production, there could be hundreds of clients connected to a Cassandra > cluster (maybe even from different applications), and if they use DataStax > Java Driver, each client will establish at least one TCP connection to a > Cassandra server (see > https://datastax.github.io/java-driver/2.1.9/features/pooling/). This is all > normal and at any given time, you can indeed see hundreds of ESTABLISHED > connections to port 9042 on a C* server (from netstat -na). The problem is > that sometimes when a C* cluster is under heavy load, when the DBA identifies > some client session that sends abusive amount of traffic to the C* server and > would like to stop it, they would like a lightweight approach rather than > shutting down the JVM or rolling restart the whole cluster to kill all > hundreds of connections in order to kill a single client session. If the DBA > had root privilege, they would have been able to do something at the OS > network level to achieve the same goal but oftentimes enterprise DBA role is > separate from OS sysadmin role, so the DBAs usually don't have that privilege. > This is especially helpful when you have a multi-tenant C* cluster and you > want to have the impact for handling such client to be minimal to the other > applications. This feature (killing individual session) seems to be a common > feature in other databases (regardless of whether the client has some > reconnect logic or not). It could be implemented as a JMX MBean method and > exposed through nodetool to the DBAs. > Note due to CQL driver's automated reconnection, simply killing the currently > connected client session will not work well, so the JMX parameter should be > an IP address or a list of IP addresses, so that the Cassandra server can > terminate existing connection with that IP, and block future connection > attempts from that IP for the remaining time until the JVM is restarted. -- 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-17151) Guardrail for column size
[
https://issues.apache.org/jira/browse/CASSANDRA-17151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17151:
Status: Ready to Commit (was: Review In Progress)
> Guardrail for column size
> -
>
> Key: CASSANDRA-17151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17151
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the max size of column values, for example:
> {code}
> # Failure threshold to prevent writing large column values.
> # Defaults to -1 to disable.
> column_value_size_failure_threshold_in_kb: -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-17805) When doing a host replacement, we need to check that the node is a live node before failing with "Cannot replace a live node..."
[
https://issues.apache.org/jira/browse/CASSANDRA-17805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17805:
--
Status: Ready to Commit (was: Review In Progress)
> When doing a host replacement, we need to check that the node is a live node
> before failing with "Cannot replace a live node..."
>
>
> Key: CASSANDRA-17805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17805
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, during a node replacement, we check that the node has not updated
> gossip for a configured {{ring_delay}} amount of time (defaults to 30
> seconds). If we see an update from the node that we are replacing in less
> than the configured time, we throw a {{UnsupportedOperationException}} with
> message {{Cannot replace a live node...}}. However, we never check whether
> the node is reporting as alive or not alive.
> We need an additional check to ensure that the node being replaced is
> reported as live; and only then throw the {{UnsupportedOperationException}}
--
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-17805) When doing a host replacement, we need to check that the node is a live node before failing with "Cannot replace a live node..."
[
https://issues.apache.org/jira/browse/CASSANDRA-17805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579798#comment-17579798
]
David Capwell commented on CASSANDRA-17805:
---
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17805-trunk-D8B2B58B-977F-4DDF-8BE1-31BE0B7356F0]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17805-trunk-D8B2B58B-977F-4DDF-8BE1-31BE0B7356F0]|[build|unknown]|
> When doing a host replacement, we need to check that the node is a live node
> before failing with "Cannot replace a live node..."
>
>
> Key: CASSANDRA-17805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17805
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, during a node replacement, we check that the node has not updated
> gossip for a configured {{ring_delay}} amount of time (defaults to 30
> seconds). If we see an update from the node that we are replacing in less
> than the configured time, we throw a {{UnsupportedOperationException}} with
> message {{Cannot replace a live node...}}. However, we never check whether
> the node is reporting as alive or not alive.
> We need an additional check to ensure that the node being replaced is
> reported as live; and only then throw the {{UnsupportedOperationException}}
--
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-17805) When doing a host replacement, we need to check that the node is a live node before failing with "Cannot replace a live node..."
[
https://issues.apache.org/jira/browse/CASSANDRA-17805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17805:
--
Reviewers: Brandon Williams, David Capwell (was: David Capwell)
> When doing a host replacement, we need to check that the node is a live node
> before failing with "Cannot replace a live node..."
>
>
> Key: CASSANDRA-17805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17805
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, during a node replacement, we check that the node has not updated
> gossip for a configured {{ring_delay}} amount of time (defaults to 30
> seconds). If we see an update from the node that we are replacing in less
> than the configured time, we throw a {{UnsupportedOperationException}} with
> message {{Cannot replace a live node...}}. However, we never check whether
> the node is reporting as alive or not alive.
> We need an additional check to ensure that the node being replaced is
> reported as live; and only then throw the {{UnsupportedOperationException}}
--
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-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579794#comment-17579794
]
Ekaterina Dimitrova commented on CASSANDRA-17677:
-
Thanks [~frankgh] , I just actually pulled your latest code and will be looking
into it today.
About CI - I can confirm the failure in 4.1 is already seen in butler and
unrelated, there is no ticket though -
[https://ci-cassandra.apache.org/job/Cassandra-4.1/131/testReport/dtest-offheap.hintedhandoff_test/TestHintedHandoff/test_hintedhandoff_window/]
We probably need to follow up on it where it came from as it seems new... But
it is out of scope here.
You are right about the test_collection_function tests, seems they just started
failing consistently last week. I will follow up on that as the patch after
which they started failing shouldn't have broken them in theory but who
knows...
I will post my review/approval later today.
https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoaderOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected from the Cassandra config parameters and
> unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{and add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
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-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579794#comment-17579794
]
Ekaterina Dimitrova edited comment on CASSANDRA-17677 at 8/15/22 4:21 PM:
--
Thanks [~frankgh] , I just actually pulled your latest code and will be looking
into it today.
About CI - I can confirm the failure in 4.1 is already seen in butler and
unrelated, there is no ticket though -
[https://ci-cassandra.apache.org/job/Cassandra-4.1/131/testReport/dtest-offheap.hintedhandoff_test/TestHintedHandoff/test_hintedhandoff_window/]
We probably need to follow up on it where it came from as it seems new... But
it is out of scope here.
You are right about the test_collection_function tests, seems they just started
failing consistently last week. I will follow up on that as the patch after
which they started failing shouldn't have broken them in theory but who
knows...
https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk
I will post my review/approval later today.
was (Author: e.dimitrova):
Thanks [~frankgh] , I just actually pulled your latest code and will be looking
into it today.
About CI - I can confirm the failure in 4.1 is already seen in butler and
unrelated, there is no ticket though -
[https://ci-cassandra.apache.org/job/Cassandra-4.1/131/testReport/dtest-offheap.hintedhandoff_test/TestHintedHandoff/test_hintedhandoff_window/]
We probably need to follow up on it where it came from as it seems new... But
it is out of scope here.
You are right about the test_collection_function tests, seems they just started
failing consistently last week. I will follow up on that as the patch after
which they started failing shouldn't have broken them in theory but who
knows...
I will post my review/approval later today.
https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoaderOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected from the Cassandra config parameters and
> unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{and add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
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-17151) Guardrail for column size
[
https://issues.apache.org/jira/browse/CASSANDRA-17151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579792#comment-17579792
]
David Capwell commented on CASSANDRA-17151:
---
+1
> Guardrail for column size
> -
>
> Key: CASSANDRA-17151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17151
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the max size of column values, for example:
> {code}
> # Failure threshold to prevent writing large column values.
> # Defaults to -1 to disable.
> column_value_size_failure_threshold_in_kb: -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-17151) Guardrail for column size
[
https://issues.apache.org/jira/browse/CASSANDRA-17151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17151:
--
Reviewers: David Capwell, Ekaterina Dimitrova (was: Ekaterina Dimitrova)
> Guardrail for column size
> -
>
> Key: CASSANDRA-17151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17151
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the max size of column values, for example:
> {code}
> # Failure threshold to prevent writing large column values.
> # Defaults to -1 to disable.
> column_value_size_failure_threshold_in_kb: -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] [Commented] (CASSANDRA-13089) Sidebar can't scroll when affix longer than window
[ https://issues.apache.org/jira/browse/CASSANDRA-13089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579790#comment-17579790 ] Stefan Miklosovic commented on CASSANDRA-13089: --- I do not think this is applicable anymore. > Sidebar can't scroll when affix longer than window > -- > > Key: CASSANDRA-13089 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13089 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Alwyn Davis >Priority: Low > Attachments: doc-navigation-fixer.js > > > On the Cassandra Configuration page > (http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html), > the side nav is very long (3853px for me), but can't be scrolled. > I'm not sure how the "fixed-navigation" javascript is being added but > changing it to add a max-height and allow scrollbars would fix this (please > see attached example). -- 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-13089) Sidebar can't scroll when affix longer than window
[ https://issues.apache.org/jira/browse/CASSANDRA-13089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-13089: -- Resolution: Abandoned Status: Resolved (was: Open) > Sidebar can't scroll when affix longer than window > -- > > Key: CASSANDRA-13089 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13089 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Alwyn Davis >Priority: Low > Attachments: doc-navigation-fixer.js > > > On the Cassandra Configuration page > (http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html), > the side nav is very long (3853px for me), but can't be scrolled. > I'm not sure how the "fixed-navigation" javascript is being added but > changing it to add a max-height and allow scrollbars would fix this (please > see attached example). -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579786#comment-17579786 ] Stefan Miklosovic commented on CASSANDRA-13010: --- hi [~alourie] , do you plan to work on this? Otherwise I would be interested in taking your work and make it happen. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Normal > Labels: 4.0-feature-freeze-review-requested, lhf > Attachments: cleanup.png, multiple operations.png > > -- 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-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579785#comment-17579785
]
Francisco Guerrero commented on CASSANDRA-17677:
I went ahead and implemented the suggestion of handling the parameters
internally in bytes. This approach allows us to have no conversion issues.
Pipelines look happy for {{4.1}} but there are 15 errors here
https://app.circleci.com/pipelines/github/frankgh/cassandra/110/workflows/07658b64-caea-41dc-93d2-214de0ff7f2b/jobs/2453.
They seem to be coming from the {{test_collection_function}} tests. These
failing tests look unrelated to this PR.
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoaderOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected from the Cassandra config parameters and
> unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{and add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
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-17599) Update how_to_commit documentation with lost updates from in-tree repo
[ https://issues.apache.org/jira/browse/CASSANDRA-17599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-17599: --- Assignee: (was: Ekaterina Dimitrova) > Update how_to_commit documentation with lost updates from in-tree repo > -- > > Key: CASSANDRA-17599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17599 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Michael Semb Wever >Priority: Normal > Attachments: how_to_commit.patch > > > When the > [how_to_commit.rst|https://github.com/apache/cassandra/blob/1fce84f9833bd62227dbf8f5d063935457dbc18e/doc/source/development/how_to_commit.rst] > page got migrated and moved to the > [cassandra-website|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc] > repo, new edits were not carried over. > cassandra-website/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc > > needs to be updated so it reads like > https://github.com/apache/cassandra/blob/1fce84f9833bd62227dbf8f5d063935457dbc18e/doc/source/development/how_to_commit.rst > It should also be updated to include latest release branches (ref: > CASSANDRA-17589 ) -- 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-17599) Update how_to_commit documentation with lost updates from in-tree repo
[ https://issues.apache.org/jira/browse/CASSANDRA-17599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-17599: --- Assignee: Ekaterina Dimitrova > Update how_to_commit documentation with lost updates from in-tree repo > -- > > Key: CASSANDRA-17599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17599 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Michael Semb Wever >Assignee: Ekaterina Dimitrova >Priority: Normal > Attachments: how_to_commit.patch > > > When the > [how_to_commit.rst|https://github.com/apache/cassandra/blob/1fce84f9833bd62227dbf8f5d063935457dbc18e/doc/source/development/how_to_commit.rst] > page got migrated and moved to the > [cassandra-website|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc] > repo, new edits were not carried over. > cassandra-website/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc > > needs to be updated so it reads like > https://github.com/apache/cassandra/blob/1fce84f9833bd62227dbf8f5d063935457dbc18e/doc/source/development/how_to_commit.rst > It should also be updated to include latest release branches (ref: > CASSANDRA-17589 ) -- 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] (CASSANDRASC-41) Implement toString for Range in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-41: - Reviewers: Francisco Guerrero, Yifan Cai Status: Review In Progress (was: Patch Available) > Implement toString for Range in Sidecar > --- > > Key: CASSANDRASC-41 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-41 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > The toString method for Range is not implemented, leading to the ranges > objects being logged incorrectly. We should add the toString implementation. -- 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] (CASSANDRASC-41) Implement toString for Range in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-41: - Reviewers: Francisco Guerrero (was: Francisco Guerrero, Yifan Cai) > Implement toString for Range in Sidecar > --- > > Key: CASSANDRASC-41 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-41 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > The toString method for Range is not implemented, leading to the ranges > objects being logged incorrectly. We should add the toString implementation. -- 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-17461) Test Failure: org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation
[
https://issues.apache.org/jira/browse/CASSANDRA-17461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579776#comment-17579776
]
Andres de la Peña commented on CASSANDRA-17461:
---
I have been able to reproduce the CAS timeout locally too, by just running the
test in a shell loop:
{code:java}
for i in {1..500}
do
ant test-jvm-dtest-some
-Dtest.name="org.apache.cassandra.distributed.test.CASTest"
-Dtest.methods="testConflictingWritesWithStaleRingInformation"
done
{code}
It can take a while to hit a failure, though. The CircleCI job does basically
the same but using multiple parallel runners.
> Test Failure:
> org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation
> -
>
> Key: CASSANDRA-17461
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17461
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> Intermittent failures on {{org.apache.cassandra.distributed.test.CASTest}}
> for trunk:
> *
> [testConflictingWritesWithStaleRingInformation|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.distributed.test/CASTest/testConflictingWritesWithStaleRingInformation_3/]
> *
> [testSuccessfulWriteBeforeRangeMovement|https://ci-cassandra.apache.org/job/Cassandra-trunk/1025/testReport/org.apache.cassandra.distributed.test/CASTest/testSuccessfulWriteBeforeRangeMovement/]
> *
> [testSuccessfulWriteDuringRangeMovementFollowedByConflicting|https://ci-cassandra.apache.org/job/Cassandra-trunk/1020/testReport/org.apache.cassandra.distributed.test/CASTest/testSuccessfulWriteDuringRangeMovementFollowedByConflicting/]
> *
> [testSucccessfulWriteDuringRangeMovementFollowedByRead|https://ci-cassandra.apache.org/job/Cassandra-trunk/1020/testReport/org.apache.cassandra.distributed.test/CASTest/testSucccessfulWriteDuringRangeMovementFollowedByRead/]
> All four seem to have the same aspect:
> {code}
> Failed 2 times in the last 5 runs. Flakiness: 50%, Stability: 60%
> Error Message
> CAS operation timed out: received 1 of 2 required responses after 0
> contention retries
> Stacktrace
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 1 of 2 required responses after 0 contention retries
> at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.begin(Paxos.java:1048)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:659)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618)
> at org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Standard Output
> DEBUG [main] 2022-03-19 16:20:42,868 Reflections.java:198 - going to scan
> these urls:
> [jar:file:/home/cassandra/cassandra/build/apache-cassandra-4.1-SNAPSHOT.jar!/,
>
> jar:file:/home/cassandra/cassandra/build/test/lib/jars/simulator-bootstrap.jar!/,
>
> jar:file:/home/cassandra/cassandra/build/test/lib/jars/dtest-api-0.0.12.jar!/,
> file:/home/cassandra/cassandra/build/classes/fqltool/,
> file:/home/cassandra/cassandra/build/test/classes/,
> file:/home/cassandra/cassandra/build/classes/main/, file:/home/cass
> ...[truncated 4929659 chars]...
> gService.java:519 - Waiting for messaging service to quiesce
> INFO [node1_isolatedExecutor:10] 2022-03-19 16:21:55,223
> SubstituteLogger.java:169 - INFO [node1_isolatedExecutor:10] node1
> 2022-03-19 16:21:55,221 MessagingService.java:519 - Waiting for messaging
> service t
[jira] [Commented] (CASSANDRA-17679) Make resumable bootstrap feature optional
[
https://issues.apache.org/jira/browse/CASSANDRA-17679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579774#comment-17579774
]
Jeremiah Jordan commented on CASSANDRA-17679:
-
{quote}That about cover it?
{quote}
Yes.
On the proposal by Paulo. I think we should not change anything for 4.0. But
for 4.1+ I think the proposed setup is a good way forward.
{quote}a) {{-Dcassandra.reset_bootstrap_progress=}} new default behavior
- fail bootstrap if a previous bootstrap attempt was detected (user needs to
manually cleanup bootstrap progress).
b) {{-Dcassandra.reset_bootstrap_progress=true}} clear streamed ranges from
system.available_ranges, and in the future also cleanup incomplete bootstrap
data on disk (perform this later action in a follow-up ticket)
c) {{-Dcassandra.reset_bootstrap_progress=false}} current default behavior of
skipping already available ranges during bootstrap streaming.
{quote}
If we detect a failed bootstrap then we make the user specify what they want to
do.
Something else to consider is what to do with "nodetool rebuild". It also uses
the data from the progress table. But that as well as trying to remove
existing data are probably worth a new ticket.
> Make resumable bootstrap feature optional
> -
>
> Key: CASSANDRA-17679
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17679
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Streaming
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> From the patch I'm working on:
> {code}
> # In certain environments, operators may want to disable resumable bootstrap
> in order to avoid potential correctness
> # violations or data loss scenarios. Largely this centers around nodes going
> down during bootstrap, tombstones being
> # written, and potential races with repair. By default we leave this on as
> it's been enabled for quite some time,
> # however the option to disable it is more palatable now that we have zero
> copy streaming as that greatly accelerates
> # bootstraps. This defaults to true.
> # resumable_bootstrap_enabled: true
> {code}
> Not really a great fit for guardrails as it's less a "feature to be toggled
> on and off" and more a subset of a specific feature that in certain
> circumstances can lead to issues.
--
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-17679) Make resumable bootstrap feature optional
[
https://issues.apache.org/jira/browse/CASSANDRA-17679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579765#comment-17579765
]
Paulo Motta edited comment on CASSANDRA-17679 at 8/15/22 3:27 PM:
--
After thinking about this again, how about this proposal:
a) {{-Dcassandra.reset_bootstrap_progress=}} new default behavior - fail
bootstrap if a previous bootstrap attempt was detected (user needs to manually
cleanup bootstrap progress).
b) {{-Dcassandra.reset_bootstrap_progress=true}} clear streamed ranges from
system.available_ranges, and in the future also cleanup incomplete bootstrap
data on disk (perform this later action in a follow-up ticket)
c) {{-Dcassandra.reset_bootstrap_progress=false}} current default behavior of
skipping already available ranges during bootstrap streaming.
was (Author: paulo):
After thinking about this again, how about this proposal:
a) {{-Dcassandra.reset_bootstrap_progress=}} new default behavior - fail
bootstrap if a previous bootstrap attempt was detected (user needs to manually
cleanup bootstrap progress).
b) {{-Dcassandra.reset_bootstrap_progress=true}} clear streamed ranges from
system.available_ranges, and in the future also cleanup incomplete bootstrap
data on disk (perform this later action in a follow-up ticket)
c) {{-Dcassandra.reset_bootstrap_progress=false}} current behavior of skipping
already available ranges during bootstrap streaming.
> Make resumable bootstrap feature optional
> -
>
> Key: CASSANDRA-17679
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17679
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Streaming
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> From the patch I'm working on:
> {code}
> # In certain environments, operators may want to disable resumable bootstrap
> in order to avoid potential correctness
> # violations or data loss scenarios. Largely this centers around nodes going
> down during bootstrap, tombstones being
> # written, and potential races with repair. By default we leave this on as
> it's been enabled for quite some time,
> # however the option to disable it is more palatable now that we have zero
> copy streaming as that greatly accelerates
> # bootstraps. This defaults to true.
> # resumable_bootstrap_enabled: true
> {code}
> Not really a great fit for guardrails as it's less a "feature to be toggled
> on and off" and more a subset of a specific feature that in certain
> circumstances can lead to issues.
--
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-17679) Make resumable bootstrap feature optional
[
https://issues.apache.org/jira/browse/CASSANDRA-17679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579765#comment-17579765
]
Paulo Motta commented on CASSANDRA-17679:
-
After thinking about this again, how about this proposal:
a) {{-Dcassandra.reset_bootstrap_progress=}} new default behavior - fail
bootstrap if a previous bootstrap attempt was detected (user needs to manually
cleanup bootstrap progress).
b) {{-Dcassandra.reset_bootstrap_progress=true}} clear streamed ranges from
system.available_ranges, and in the future also cleanup incomplete bootstrap
data on disk (perform this later action in a follow-up ticket)
c) {{-Dcassandra.reset_bootstrap_progress=false}} current behavior of skipping
already available ranges during bootstrap streaming.
> Make resumable bootstrap feature optional
> -
>
> Key: CASSANDRA-17679
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17679
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Streaming
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> From the patch I'm working on:
> {code}
> # In certain environments, operators may want to disable resumable bootstrap
> in order to avoid potential correctness
> # violations or data loss scenarios. Largely this centers around nodes going
> down during bootstrap, tombstones being
> # written, and potential races with repair. By default we leave this on as
> it's been enabled for quite some time,
> # however the option to disable it is more palatable now that we have zero
> copy streaming as that greatly accelerates
> # bootstraps. This defaults to true.
> # resumable_bootstrap_enabled: true
> {code}
> Not really a great fit for guardrails as it's less a "feature to be toggled
> on and off" and more a subset of a specific feature that in certain
> circumstances can lead to issues.
--
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-17679) Make resumable bootstrap feature optional
[
https://issues.apache.org/jira/browse/CASSANDRA-17679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579762#comment-17579762
]
Paulo Motta commented on CASSANDRA-17679:
-
I agree this feature is useful to some users and we should keep it.
Since there are known edge cases and limitations, my proposal is to disable
this feature by default on 4.0+ (with proper notice on NEWS.txt), by simply
setting "-Dcassandra.reset_bootstrap_progress=true" by default, until we work
on making the feature more reliable. I think now it's too late to change
default behavior on 3.x so we can keep it as it is.
It would be nice to make "-Dcassandra.reset_bootstrap_progress=true" clear
existing bootstrap data as it would make this feature more reliable. Not sure
if this should be done in this ticket together with disabling this feature by
default or as a separate effort.
> Make resumable bootstrap feature optional
> -
>
> Key: CASSANDRA-17679
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17679
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Streaming
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> From the patch I'm working on:
> {code}
> # In certain environments, operators may want to disable resumable bootstrap
> in order to avoid potential correctness
> # violations or data loss scenarios. Largely this centers around nodes going
> down during bootstrap, tombstones being
> # written, and potential races with repair. By default we leave this on as
> it's been enabled for quite some time,
> # however the option to disable it is more palatable now that we have zero
> copy streaming as that greatly accelerates
> # bootstraps. This defaults to true.
> # resumable_bootstrap_enabled: true
> {code}
> Not really a great fit for guardrails as it's less a "feature to be toggled
> on and off" and more a subset of a specific feature that in certain
> circumstances can lead to issues.
--
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-17679) Make resumable bootstrap feature optional
[
https://issues.apache.org/jira/browse/CASSANDRA-17679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579753#comment-17579753
]
Josh McKenzie commented on CASSANDRA-17679:
---
ping [~jjordan]
> Make resumable bootstrap feature optional
> -
>
> Key: CASSANDRA-17679
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17679
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Streaming
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> From the patch I'm working on:
> {code}
> # In certain environments, operators may want to disable resumable bootstrap
> in order to avoid potential correctness
> # violations or data loss scenarios. Largely this centers around nodes going
> down during bootstrap, tombstones being
> # written, and potential races with repair. By default we leave this on as
> it's been enabled for quite some time,
> # however the option to disable it is more palatable now that we have zero
> copy streaming as that greatly accelerates
> # bootstraps. This defaults to true.
> # resumable_bootstrap_enabled: true
> {code}
> Not really a great fit for guardrails as it's less a "feature to be toggled
> on and off" and more a subset of a specific feature that in certain
> circumstances can lead to issues.
--
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-17810) Revise timeout handling on queries triggering timeout introduced by CASSANDRA-7392
[
https://issues.apache.org/jira/browse/CASSANDRA-17810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579752#comment-17579752
]
Josh McKenzie commented on CASSANDRA-17810:
---
Hm. CI is pretty unhappy w/this one; first spot check repros locally so I'll
dig into that and resubmit when resolved.
> Revise timeout handling on queries triggering timeout introduced by
> CASSANDRA-7392
> --
>
> Key: CASSANDRA-17810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17810
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> In situations where a replica times out with the code introduced in
> CASSANDRA-7392, they drop the timed-out query on the floor without notifying
> the coordinator; this doesn't become apparent coordinator-side until we go to
> serialize the response. While the results of this (i.e. missed data) should
> mostly be fixed by short read protection on repeat requests, the coordinator
> can in some cases throw an exception like {{IllegalStateException:
> UnfilteredRowIterator for keyspace.table has an open RT bound as its last
> item}} which is decidedly unfriendly.
> We should introduce a specific exception to allow replicas to notify a
> coordinator something has timed out and been dropped on the floor so the
> coordinator can appropriately handle that scenario and abort the query at
> that time.
--
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-17810) Revise timeout handling on queries triggering timeout introduced by CASSANDRA-7392
[
https://issues.apache.org/jira/browse/CASSANDRA-17810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17810:
--
Status: Open (was: Patch Available)
> Revise timeout handling on queries triggering timeout introduced by
> CASSANDRA-7392
> --
>
> Key: CASSANDRA-17810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17810
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> In situations where a replica times out with the code introduced in
> CASSANDRA-7392, they drop the timed-out query on the floor without notifying
> the coordinator; this doesn't become apparent coordinator-side until we go to
> serialize the response. While the results of this (i.e. missed data) should
> mostly be fixed by short read protection on repeat requests, the coordinator
> can in some cases throw an exception like {{IllegalStateException:
> UnfilteredRowIterator for keyspace.table has an open RT bound as its last
> item}} which is decidedly unfriendly.
> We should introduce a specific exception to allow replicas to notify a
> coordinator something has timed out and been dropped on the floor so the
> coordinator can appropriately handle that scenario and abort the query at
> that time.
--
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
[cassandra-website] branch asf-staging updated (541ea3a8 -> cd3a1100)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 541ea3a8 generate docs for 930e594a new cd3a1100 generate docs for 930e594a This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (541ea3a8) \ N -- N -- N refs/heads/asf-staging (cd3a1100) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17810) Revise timeout handling on queries triggering timeout introduced by CASSANDRA-7392
[
https://issues.apache.org/jira/browse/CASSANDRA-17810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17810:
--
Reviewers: Aleksey Yeschenko
> Revise timeout handling on queries triggering timeout introduced by
> CASSANDRA-7392
> --
>
> Key: CASSANDRA-17810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17810
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> In situations where a replica times out with the code introduced in
> CASSANDRA-7392, they drop the timed-out query on the floor without notifying
> the coordinator; this doesn't become apparent coordinator-side until we go to
> serialize the response. While the results of this (i.e. missed data) should
> mostly be fixed by short read protection on repeat requests, the coordinator
> can in some cases throw an exception like {{IllegalStateException:
> UnfilteredRowIterator for keyspace.table has an open RT bound as its last
> item}} which is decidedly unfriendly.
> We should introduce a specific exception to allow replicas to notify a
> coordinator something has timed out and been dropped on the floor so the
> coordinator can appropriately handle that scenario and abort the query at
> that time.
--
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-17795) Add ability to generate a one-time heap dump output to a file on Unhandled Exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-17795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17795:
--
Fix Version/s: 4.2
Source Control Link:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=3e0b94565acc64e903d73af3a14b23c875abc5b3
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Add ability to generate a one-time heap dump output to a file on Unhandled
> Exceptions
> -
>
> Key: CASSANDRA-17795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17795
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.2
>
>
> We should add the optional hot-proppable / in .yaml ability to collect a heap
> dump when any uncaught exception is handled by the {{JVMStabilityInspector}},
> assuming it's not an OOM or something that marks the JVM unstable.
> This has come in handy in a variety of prod debugging scenarios and would be
> good to have baked into the DB proper for 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-17795) Add ability to generate a one-time heap dump output to a file on Unhandled Exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-17795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17795:
--
Status: Ready to Commit (was: Review In Progress)
> Add ability to generate a one-time heap dump output to a file on Unhandled
> Exceptions
> -
>
> Key: CASSANDRA-17795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17795
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> We should add the optional hot-proppable / in .yaml ability to collect a heap
> dump when any uncaught exception is handled by the {{JVMStabilityInspector}},
> assuming it's not an OOM or something that marks the JVM unstable.
> This has come in handy in a variety of prod debugging scenarios and would be
> good to have baked into the DB proper for 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
[cassandra] branch trunk updated: Add support to generate a One-Shot heap dump on unhandled exceptions
This is an automated email from the ASF dual-hosted git repository.
jmckenzie pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 3e0b94565a Add support to generate a One-Shot heap dump on unhandled
exceptions
3e0b94565a is described below
commit 3e0b94565acc64e903d73af3a14b23c875abc5b3
Author: Josh McKenzie
AuthorDate: Tue Aug 2 16:02:03 2022 -0400
Add support to generate a One-Shot heap dump on unhandled exceptions
Patch by Caleb Rackliffe; reviewed by Josh McKenzie, David Capwell, and Jon
Meredith for CASSANDRA-17795
Co-authored-by: Caleb Rackliffe
Co-authored-by: Josh McKenzie
---
CHANGES.txt| 1 +
build.xml | 1 +
conf/cassandra.yaml| 10 +++
ide/idea/workspace.xml | 6 +-
src/java/org/apache/cassandra/config/Config.java | 3 +
.../cassandra/config/DatabaseDescriptor.java | 79 +
.../org/apache/cassandra/service/StorageProxy.java | 12
.../cassandra/service/StorageProxyMBean.java | 3 +
src/java/org/apache/cassandra/utils/HeapUtils.java | 82 +-
.../cassandra/utils/JVMStabilityInspector.java | 3 +
test/conf/cassandra.yaml | 3 +
.../org/apache/cassandra/utils/HeapUtilsTest.java | 63 +
.../org/apache/cassandra/tools/BulkLoaderTest.java | 26 ---
13 files changed, 277 insertions(+), 15 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 3aaaf8b38e..dd09b25c56 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * Add support to generate a One-Shot heap dump on unhandled exceptions
(CASSANDRA-17795)
* Rate-limit new client connection auth setup to avoid overwhelming bcrypt
(CASSANDRA-17812)
* DataOutputBuffer#scratchBuffer can use off-heap or on-heap memory as a
means to control memory allocations (CASSANDRA-16471)
* Add ability to read the TTLs and write times of the elements of a
collection and/or UDT (CASSANDRA-8877)
diff --git a/build.xml b/build.xml
index ca346c9f28..82a805d5d8 100644
--- a/build.xml
+++ b/build.xml
@@ -1500,6 +1500,7 @@
more aggressively rather than waiting. See CASSANDRA-14922 for
more details.
-->
+
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 98d70a035f..21e3f78c10 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -107,6 +107,16 @@ auto_hints_cleanup_enabled: false
# parameters:
# -
+# Directory where Cassandra should store results of a One-Shot troubleshooting
heapdump for uncaught exceptions.
+# Note: this value can be overridden by the -XX:HeapDumpPath JVM env param
with a relative local path for testing if
+# so desired.
+# If not set, the default directory is $CASSANDRA_HOME/heapdump
+# heap_dump_path: /var/lib/cassandra/heapdump
+
+# Enable / disable automatic dump of heap on first uncaught exception
+# If not set, the default value is false
+# dump_heap_on_uncaught_exception: true
+
# Enable / disable persistent hint windows.
#
# If set to false, a hint will be stored only in case a respective node
diff --git a/ide/idea/workspace.xml b/ide/idea/workspace.xml
index e35ba90ac7..321edd8024 100644
--- a/ide/idea/workspace.xml
+++ b/ide/idea/workspace.xml
@@ -143,7 +143,7 @@
-
+
@@ -167,7 +167,7 @@
-
@@ -187,7 +187,7 @@
-
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index bdca0a7df1..f14bb3544a 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -1179,4 +1179,7 @@ public class Config
logger.info("Node configuration:[{}]", Joiner.on(";
").join(configMap.entrySet()));
}
+
+public volatile boolean dump_heap_on_uncaught_exception = false;
+public String heap_dump_path = "heapdump";
}
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 0a9036f632..e000eeea26 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -18,6 +18,8 @@
package org.apache.cassandra.config;
import java.io.IOException;
+import java.lang.management.ManagementFactory;
+import java.lang.management.RuntimeMXBean;
import java.net.Inet4Address;
import java.net.Inet6Address;
import java.net.InetAddress;
@@ -25,6 +27,8 @@ import java.net.NetworkInterface;
import java.net.SocketException;
import java.net.UnknownHostException;
import java.nio.file.FileStore;
+import ja
[jira] [Commented] (CASSANDRA-17599) Update how_to_commit documentation with lost updates from in-tree repo
[ https://issues.apache.org/jira/browse/CASSANDRA-17599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579744#comment-17579744 ] Claude Warren commented on CASSANDRA-17599: --- [~mck] here is an attempt at a patch. Please let me know if this is what you were thinking of. I'll open a pull request if so. > Update how_to_commit documentation with lost updates from in-tree repo > -- > > Key: CASSANDRA-17599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17599 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Michael Semb Wever >Priority: Normal > Attachments: how_to_commit.patch > > > When the > [how_to_commit.rst|https://github.com/apache/cassandra/blob/1fce84f9833bd62227dbf8f5d063935457dbc18e/doc/source/development/how_to_commit.rst] > page got migrated and moved to the > [cassandra-website|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc] > repo, new edits were not carried over. > cassandra-website/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc > > needs to be updated so it reads like > https://github.com/apache/cassandra/blob/1fce84f9833bd62227dbf8f5d063935457dbc18e/doc/source/development/how_to_commit.rst > It should also be updated to include latest release branches (ref: > CASSANDRA-17589 ) -- 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-17599) Update how_to_commit documentation with lost updates from in-tree repo
[ https://issues.apache.org/jira/browse/CASSANDRA-17599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CASSANDRA-17599: -- Attachment: how_to_commit.patch > Update how_to_commit documentation with lost updates from in-tree repo > -- > > Key: CASSANDRA-17599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17599 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Michael Semb Wever >Priority: Normal > Attachments: how_to_commit.patch > > > When the > [how_to_commit.rst|https://github.com/apache/cassandra/blob/1fce84f9833bd62227dbf8f5d063935457dbc18e/doc/source/development/how_to_commit.rst] > page got migrated and moved to the > [cassandra-website|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc] > repo, new edits were not carried over. > cassandra-website/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc > > needs to be updated so it reads like > https://github.com/apache/cassandra/blob/1fce84f9833bd62227dbf8f5d063935457dbc18e/doc/source/development/how_to_commit.rst > It should also be updated to include latest release branches (ref: > CASSANDRA-17589 ) -- 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-17812) Rate-limit new client connection setup to avoid overwhelming bcrypt
[ https://issues.apache.org/jira/browse/CASSANDRA-17812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17812: -- Fix Version/s: 4.2 Source Control Link: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=09b282d1fdd7d6d62542137003011d144c0227be Resolution: Fixed Status: Resolved (was: Ready to Commit) > Rate-limit new client connection setup to avoid overwhelming bcrypt > --- > > Key: CASSANDRA-17812 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17812 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Encryption >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.2 > > > A flood of reconnects can cause a ton of pain at the bcrypt phase of > validating incoming connections. While this shouldn't happen during normal > operations, we need a rate limit server side - if there's a bad client out > there (version and/or configuration) that misbehaves, a way to cap the pain > on a server is quite useful. Right now the only option is to cap the total > connections which has other issues that aren't an ideal tradeoff (inability > to connect, etc). > Moving authentication requests to a small, separate pool will prevent > starvation handling all other requests. If the authExecutor pool backs up it > may cause authentication timeouts, but the clients should back off and retry > while the rest of the system continues to make progress. -- 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-17812) Rate-limit new client connection setup to avoid overwhelming bcrypt
[ https://issues.apache.org/jira/browse/CASSANDRA-17812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17812: -- Status: Ready to Commit (was: Review In Progress) > Rate-limit new client connection setup to avoid overwhelming bcrypt > --- > > Key: CASSANDRA-17812 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17812 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Encryption >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > A flood of reconnects can cause a ton of pain at the bcrypt phase of > validating incoming connections. While this shouldn't happen during normal > operations, we need a rate limit server side - if there's a bad client out > there (version and/or configuration) that misbehaves, a way to cap the pain > on a server is quite useful. Right now the only option is to cap the total > connections which has other issues that aren't an ideal tradeoff (inability > to connect, etc). > Moving authentication requests to a small, separate pool will prevent > starvation handling all other requests. If the authExecutor pool backs up it > may cause authentication timeouts, but the clients should back off and retry > while the rest of the system continues to make progress. -- 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
[cassandra] branch trunk updated: Rate-limit new client connection auth setup to avoid overwhelming bcrypt
This is an automated email from the ASF dual-hosted git repository.
jmckenzie pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 09b282d1fd Rate-limit new client connection auth setup to avoid
overwhelming bcrypt
09b282d1fd is described below
commit 09b282d1fdd7d6d62542137003011d144c0227be
Author: Josh McKenzie
AuthorDate: Thu Aug 11 14:02:27 2022 -0400
Rate-limit new client connection auth setup to avoid overwhelming bcrypt
Patch by Chris Lohfink; reviewed by Caleb Rackliffe, Yifan Cai, and Josh
McKenzie for CASSANDRA-17812
Co-authored-by: Chris Lohfink
Co-authored-by: Josh McKenzie
---
CHANGES.txt| 1 +
src/java/org/apache/cassandra/config/Config.java | 2 +
.../cassandra/config/DatabaseDescriptor.java | 16 ++
.../org/apache/cassandra/transport/Dispatcher.java | 47 --
src/java/org/apache/cassandra/utils/Shared.java| 2 +-
.../cassandra/transport/MessageDispatcherTest.java | 172 +
6 files changed, 228 insertions(+), 12 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 489d2d8845..3aaaf8b38e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * Rate-limit new client connection auth setup to avoid overwhelming bcrypt
(CASSANDRA-17812)
* DataOutputBuffer#scratchBuffer can use off-heap or on-heap memory as a
means to control memory allocations (CASSANDRA-16471)
* Add ability to read the TTLs and write times of the elements of a
collection and/or UDT (CASSANDRA-8877)
* Removed Python < 2.7 support from formatting.py (CASSANDRA-17694)
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index 68091ac90f..bdca0a7df1 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -266,6 +266,8 @@ public class Config
public int native_transport_max_threads = 128;
@Replaces(oldName = "native_transport_max_frame_size_in_mb", converter =
Converters.MEBIBYTES_DATA_STORAGE_INT, deprecated = true)
public DataStorageSpec.IntMebibytesBound native_transport_max_frame_size =
new DataStorageSpec.IntMebibytesBound("16MiB");
+/** do bcrypt hashing in a limited pool to prevent cpu load spikes; note:
any value < 1 will be set to 1 on init **/
+public int native_transport_max_auth_threads = 4;
public volatile long native_transport_max_concurrent_connections = -1L;
public volatile long native_transport_max_concurrent_connections_per_ip =
-1L;
public boolean native_transport_flush_in_batches_legacy = false;
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 1ce16052fe..0a9036f632 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -2573,6 +2573,22 @@ public class DatabaseDescriptor
conf.native_transport_max_threads = max_threads;
}
+public static Integer getNativeTransportMaxAuthThreads()
+{
+return conf.native_transport_max_auth_threads;
+}
+
+/**
+ * If this value is set to <= 0 it will move auth requests to the standard
request pool regardless of the current
+ * size of the {@link
org.apache.cassandra.transport.Dispatcher#authExecutor}'s active size.
+ *
+ * see {@link org.apache.cassandra.transport.Dispatcher#dispatch} for
executor selection
+ */
+public static void setNativeTransportMaxAuthThreads(int threads)
+{
+conf.native_transport_max_auth_threads = threads;
+}
+
public static int getNativeTransportMaxFrameSize()
{
return conf.native_transport_max_frame_size.toBytes();
diff --git a/src/java/org/apache/cassandra/transport/Dispatcher.java
b/src/java/org/apache/cassandra/transport/Dispatcher.java
index 8f8a607c77..f21acc2c6d 100644
--- a/src/java/org/apache/cassandra/transport/Dispatcher.java
+++ b/src/java/org/apache/cassandra/transport/Dispatcher.java
@@ -23,6 +23,7 @@ import java.util.concurrent.ConcurrentMap;
import java.util.concurrent.TimeUnit;
import java.util.function.Consumer;
+import com.google.common.annotations.VisibleForTesting;
import com.google.common.base.Predicate;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -51,11 +52,31 @@ import static
org.apache.cassandra.concurrent.SharedExecutorPool.SHARED;
public class Dispatcher
{
private static final Logger logger =
LoggerFactory.getLogger(Dispatcher.class);
-
-private static final LocalAwareExecutorPlus requestExecutor =
SHARED.newExecutor(DatabaseDescriptor.getNativeTransportMaxThreads(),
-
DatabaseDescriptor::setNativeTransport
[cassandra-website] branch asf-staging updated (eb87efdc -> 541ea3a8)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard eb87efdc generate docs for 930e594a new 541ea3a8 generate docs for 930e594a This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (eb87efdc) \ N -- N -- N refs/heads/asf-staging (541ea3a8) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch trunk updated: ninja-fix cassandra-rpm-packaging.sh `s/{$rpm_dist}/${rpm_dist}/`
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/trunk by this push:
new 1af3812 ninja-fix cassandra-rpm-packaging.sh
`s/{$rpm_dist}/${rpm_dist}/`
1af3812 is described below
commit 1af3812c0fddeaf22260d8164d5d87a377e2116b
Author: Mick Semb Wever
AuthorDate: Mon Aug 15 11:24:35 2022 +0200
ninja-fix cassandra-rpm-packaging.sh `s/{$rpm_dist}/${rpm_dist}/`
---
build-scripts/cassandra-rpm-packaging.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/build-scripts/cassandra-rpm-packaging.sh
b/build-scripts/cassandra-rpm-packaging.sh
index 8c955c5..8fdb2ef 100755
--- a/build-scripts/cassandra-rpm-packaging.sh
+++ b/build-scripts/cassandra-rpm-packaging.sh
@@ -49,6 +49,6 @@ pushd $cassandra_builds_dir
docker build --build-arg CASSANDRA_GIT_URL=$CASSANDRA_GIT_URL --build-arg
UID_ARG=`id -u` --build-arg GID_ARG=`id -g` -t
cassandra-artifacts-${dist_name}:${sha} -f docker/${dist_name}-image.docker
docker/
# Run build script through docker (specify branch, tag, or sha)
-docker run --rm -v "${rpm_dir}":/dist -v
~/.m2/repository/:/home/build/.m2/repository/
cassandra-artifacts-${dist_name}:${sha} /home/build/build-rpms.sh ${sha}
${java_version} {$rpm_dist}
+docker run --rm -v "${rpm_dir}":/dist -v
~/.m2/repository/:/home/build/.m2/repository/
cassandra-artifacts-${dist_name}:${sha} /home/build/build-rpms.sh ${sha}
${java_version} ${rpm_dist}
popd
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15767) /usr/bin/cassandra looking for wrong libjemalloc.so file
[ https://issues.apache.org/jira/browse/CASSANDRA-15767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15767: -- Reviewers: Brandon Williams, Stefan Miklosovic Status: Review In Progress (was: Patch Available) > /usr/bin/cassandra looking for wrong libjemalloc.so file > > > Key: CASSANDRA-15767 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15767 > Project: Cassandra > Issue Type: Bug > Components: Local/Scripts >Reporter: Brian Bellrose >Assignee: Stefan Miklosovic >Priority: Normal > Labels: centos8, debian, jemalloc > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1-beta, 4.2 > > > In /usr/sbin/cassandra > Linux) > if [ -z $CASSANDRA_LIBJEMALLOC ] ; then > which ldconfig > /dev/null 2>&1 > if [ $? = 0 ] ; then > # e.g. for CentOS > dirs="/lib64 /lib /usr/lib64 /usr/lib `ldconfig -v 2>/dev/null | grep -v > '^\s' | sed 's/^\([^:]*\):.*$/\1/'`" > else > # e.g. for Debian, OpenSUSE > dirs="/lib64 /lib /usr/lib64 /usr/lib `cat /etc/ld.so.conf > /etc/ld.so.conf.d/*.conf | grep '^/'`" > fi > dirs=`echo $dirs | tr " " ":"` > CASSANDRA_LIBJEMALLOC=$(find_library '.*/libjemalloc\.so\(\.1\)*' $dirs) > > However... > # find /usr/lib64 -name "*jemalloc*" > /usr/lib64/libjemalloc.so.2 > > -- 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
[cassandra] branch cassandra-4.0 updated (6483386caa -> 5023a816e3)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 6483386caa Fix changes add ebddf77924 Improve libjemalloc resolution in bin/cassandra add f821691239 Merge branch 'cassandra-3.0' into cassandra-3.11 add 5023a816e3 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + bin/cassandra | 20 +--- 2 files changed, 14 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 77e4eb4770ee1013e711e7f76f0c510b025b4629 Merge: 60db95cba1 71cef76faa Author: Stefan Miklosovic AuthorDate: Mon Aug 15 10:13:12 2022 +0200 Merge branch 'cassandra-4.1' into trunk CHANGES.txt | 1 + bin/cassandra | 20 +--- 2 files changed, 14 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (60db95cba1 -> 77e4eb4770)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 60db95cba1 DataOutputBuffer#scratchBuffer can use off-heap or on-heap memory as a means to control memory allocations add ebddf77924 Improve libjemalloc resolution in bin/cassandra add f821691239 Merge branch 'cassandra-3.0' into cassandra-3.11 add 5023a816e3 Merge branch 'cassandra-3.11' into cassandra-4.0 add 71cef76faa Merge branch 'cassandra-4.0' into cassandra-4.1 new 77e4eb4770 Merge branch 'cassandra-4.1' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 1 + bin/cassandra | 20 +--- 2 files changed, 14 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15767) /usr/bin/cassandra looking for wrong libjemalloc.so file
[ https://issues.apache.org/jira/browse/CASSANDRA-15767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15767: -- Status: Ready to Commit (was: Review In Progress) > /usr/bin/cassandra looking for wrong libjemalloc.so file > > > Key: CASSANDRA-15767 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15767 > Project: Cassandra > Issue Type: Bug > Components: Local/Scripts >Reporter: Brian Bellrose >Assignee: Stefan Miklosovic >Priority: Normal > Labels: centos8, debian, jemalloc > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1-beta, 4.2 > > > In /usr/sbin/cassandra > Linux) > if [ -z $CASSANDRA_LIBJEMALLOC ] ; then > which ldconfig > /dev/null 2>&1 > if [ $? = 0 ] ; then > # e.g. for CentOS > dirs="/lib64 /lib /usr/lib64 /usr/lib `ldconfig -v 2>/dev/null | grep -v > '^\s' | sed 's/^\([^:]*\):.*$/\1/'`" > else > # e.g. for Debian, OpenSUSE > dirs="/lib64 /lib /usr/lib64 /usr/lib `cat /etc/ld.so.conf > /etc/ld.so.conf.d/*.conf | grep '^/'`" > fi > dirs=`echo $dirs | tr " " ":"` > CASSANDRA_LIBJEMALLOC=$(find_library '.*/libjemalloc\.so\(\.1\)*' $dirs) > > However... > # find /usr/lib64 -name "*jemalloc*" > /usr/lib64/libjemalloc.so.2 > > -- 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-15767) /usr/bin/cassandra looking for wrong libjemalloc.so file
[ https://issues.apache.org/jira/browse/CASSANDRA-15767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15767: -- Fix Version/s: 3.0.28 3.11.14 4.0.6 (was: 3.0.x) (was: 3.11.x) (was: 4.0.x) Since Version: 3.0.27 Source Control Link: https://github.com/apache/cassandra/commit/ebddf7792411d1fdd62666e99cb89174ccaf630c Resolution: Fixed Status: Resolved (was: Ready to Commit) > /usr/bin/cassandra looking for wrong libjemalloc.so file > > > Key: CASSANDRA-15767 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15767 > Project: Cassandra > Issue Type: Bug > Components: Local/Scripts >Reporter: Brian Bellrose >Assignee: Stefan Miklosovic >Priority: Normal > Labels: centos8, debian, jemalloc > Fix For: 3.0.28, 3.11.14, 4.0.6, 4.1-beta, 4.2 > > > In /usr/sbin/cassandra > Linux) > if [ -z $CASSANDRA_LIBJEMALLOC ] ; then > which ldconfig > /dev/null 2>&1 > if [ $? = 0 ] ; then > # e.g. for CentOS > dirs="/lib64 /lib /usr/lib64 /usr/lib `ldconfig -v 2>/dev/null | grep -v > '^\s' | sed 's/^\([^:]*\):.*$/\1/'`" > else > # e.g. for Debian, OpenSUSE > dirs="/lib64 /lib /usr/lib64 /usr/lib `cat /etc/ld.so.conf > /etc/ld.so.conf.d/*.conf | grep '^/'`" > fi > dirs=`echo $dirs | tr " " ":"` > CASSANDRA_LIBJEMALLOC=$(find_library '.*/libjemalloc\.so\(\.1\)*' $dirs) > > However... > # find /usr/lib64 -name "*jemalloc*" > /usr/lib64/libjemalloc.so.2 > > -- 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
[cassandra] branch cassandra-3.0 updated (299bfaed35 -> ebddf77924)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 299bfaed35 Fix missing state resetting on CompressedRandomAccessReader read errors add ebddf77924 Improve libjemalloc resolution in bin/cassandra No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + bin/cassandra | 20 +--- 2 files changed, 14 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (e7bdee507f -> 71cef76faa)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from e7bdee507f Merge branch 'cassandra-4.0' into cassandra-4.1 add ebddf77924 Improve libjemalloc resolution in bin/cassandra add f821691239 Merge branch 'cassandra-3.0' into cassandra-3.11 add 5023a816e3 Merge branch 'cassandra-3.11' into cassandra-4.0 add 71cef76faa Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + bin/cassandra | 20 +--- 2 files changed, 14 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (4e410fc46d -> f821691239)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 4e410fc46d Document usage of closed token intervals in manual compaction add ebddf77924 Improve libjemalloc resolution in bin/cassandra add f821691239 Merge branch 'cassandra-3.0' into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + bin/cassandra | 20 +--- 2 files changed, 14 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
