[jira] [Updated] (CASSJAVA-12) DefaultSslEngineFactory missing null check on close
[
https://issues.apache.org/jira/browse/CASSJAVA-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSJAVA-12:
--
Fix Version/s: 4.19.0
Source Control Link:
https://github.com/apache/cassandra-java-driver/commit/8ebcd9f85afb548f38e953fb1190d9ff04d8df5a
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> DefaultSslEngineFactory missing null check on close
> ---
>
> Key: CASSJAVA-12
> URL: https://issues.apache.org/jira/browse/CASSJAVA-12
> Project: Apache Cassandra Java driver
> Issue Type: Bug
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 4.19.0
>
>
> https://github.com/apache/cassandra-java-driver/blob/72c729b1ba95695fed467ca3734de7a39a2b3201/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L167
> Change is very simple:
> {code:java}
> @Override
> public void close() throws Exception {
> if (kmf != null)
> kmf.close();
> }
> {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] (CASSJAVA-12) DefaultSslEngineFactory missing null check on close
[
https://issues.apache.org/jira/browse/CASSJAVA-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSJAVA-12:
--
Status: Ready to Commit (was: Review In Progress)
> DefaultSslEngineFactory missing null check on close
> ---
>
> Key: CASSJAVA-12
> URL: https://issues.apache.org/jira/browse/CASSJAVA-12
> Project: Apache Cassandra Java driver
> Issue Type: Bug
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> https://github.com/apache/cassandra-java-driver/blob/72c729b1ba95695fed467ca3734de7a39a2b3201/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L167
> Change is very simple:
> {code:java}
> @Override
> public void close() throws Exception {
> if (kmf != null)
> kmf.close();
> }
> {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] (CASSJAVA-12) DefaultSslEngineFactory missing null check on close
[
https://issues.apache.org/jira/browse/CASSJAVA-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSJAVA-12:
--
Reviewers: Andy Tolbert, Chris Lohfink, Abe Ratnofsky
Andy Tolbert, Chris Lohfink, Abe Ratnofsky (was: Abe Ratnofsky,
Andy Tolbert, Chris Lohfink)
Status: Review In Progress (was: Patch Available)
> DefaultSslEngineFactory missing null check on close
> ---
>
> Key: CASSJAVA-12
> URL: https://issues.apache.org/jira/browse/CASSJAVA-12
> Project: Apache Cassandra Java driver
> Issue Type: Bug
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> https://github.com/apache/cassandra-java-driver/blob/72c729b1ba95695fed467ca3734de7a39a2b3201/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L167
> Change is very simple:
> {code:java}
> @Override
> public void close() throws Exception {
> if (kmf != null)
> kmf.close();
> }
> {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-20041) Update Jacoco dependency for JDK21 support
[ https://issues.apache.org/jira/browse/CASSANDRA-20041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-20041: -- Change Category: Quality Assurance Complexity: Low Hanging Fruit Assignee: Abe Ratnofsky Status: Open (was: Triage Needed) > Update Jacoco dependency for JDK21 support > -- > > Key: CASSANDRA-20041 > URL: https://issues.apache.org/jira/browse/CASSANDRA-20041 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python, Test/fuzz, Test/unit >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, 5.0 and trunk use JDK21 but Jacoco 0.8.8. > > Jacoco 0.8.8 does not support JDK21: > [https://github.com/apache/cassandra/blob/15ed18e9d49f48e88f40b90c156248b8b697c7e2/build.xml#L146] > > Need to update to Jacoco 0.8.11+: > [https://github.com/jacoco/jacoco/releases/tag/v0.8.11] > > Might as well go to 0.8.12 (latest as of writing). -- 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-20041) Update Jacoco dependency for JDK21 support
[ https://issues.apache.org/jira/browse/CASSANDRA-20041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894682#comment-17894682 ] Abe Ratnofsky commented on CASSANDRA-20041: --- I was too early with this - [~jmckenzie] could you roll this into the JDK21 support you're working on? Closing this one out. > Update Jacoco dependency for JDK21 support > -- > > Key: CASSANDRA-20041 > URL: https://issues.apache.org/jira/browse/CASSANDRA-20041 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python, Test/fuzz, Test/unit >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, 5.0 and trunk use JDK21 but Jacoco 0.8.8. > > Jacoco 0.8.8 does not support JDK21: > [https://github.com/apache/cassandra/blob/15ed18e9d49f48e88f40b90c156248b8b697c7e2/build.xml#L146] > > Need to update to Jacoco 0.8.11+: > [https://github.com/jacoco/jacoco/releases/tag/v0.8.11] > > Might as well go to 0.8.12 (latest as of writing). -- 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-20041) Update Jacoco dependency for JDK21 support
[ https://issues.apache.org/jira/browse/CASSANDRA-20041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-20041: -- Resolution: Later Status: Resolved (was: Open) > Update Jacoco dependency for JDK21 support > -- > > Key: CASSANDRA-20041 > URL: https://issues.apache.org/jira/browse/CASSANDRA-20041 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python, Test/fuzz, Test/unit >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, 5.0 and trunk use JDK21 but Jacoco 0.8.8. > > Jacoco 0.8.8 does not support JDK21: > [https://github.com/apache/cassandra/blob/15ed18e9d49f48e88f40b90c156248b8b697c7e2/build.xml#L146] > > Need to update to Jacoco 0.8.11+: > [https://github.com/jacoco/jacoco/releases/tag/v0.8.11] > > Might as well go to 0.8.12 (latest as of writing). -- 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-20041) Update Jacoco dependency for JDK21 support
Abe Ratnofsky created CASSANDRA-20041: - Summary: Update Jacoco dependency for JDK21 support Key: CASSANDRA-20041 URL: https://issues.apache.org/jira/browse/CASSANDRA-20041 Project: Cassandra Issue Type: Task Components: Test/dtest/java, Test/dtest/python, Test/fuzz, Test/unit Reporter: Abe Ratnofsky Currently, trunk uses JDK21 but Jacoco 0.8.8. Jacoco 0.8.8 does not support JDK21: [https://github.com/apache/cassandra/blob/15ed18e9d49f48e88f40b90c156248b8b697c7e2/build.xml#L146] Need to update to Jacoco 0.8.11+: [https://github.com/jacoco/jacoco/releases/tag/v0.8.11] Might as well go to 0.8.12 (latest as of writing). -- 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-20041) Update Jacoco dependency for JDK21 support
[ https://issues.apache.org/jira/browse/CASSANDRA-20041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-20041: -- Description: Currently, 5.0 and trunk use JDK21 but Jacoco 0.8.8. Jacoco 0.8.8 does not support JDK21: [https://github.com/apache/cassandra/blob/15ed18e9d49f48e88f40b90c156248b8b697c7e2/build.xml#L146] Need to update to Jacoco 0.8.11+: [https://github.com/jacoco/jacoco/releases/tag/v0.8.11] Might as well go to 0.8.12 (latest as of writing). was: Currently, trunk uses JDK21 but Jacoco 0.8.8. Jacoco 0.8.8 does not support JDK21: [https://github.com/apache/cassandra/blob/15ed18e9d49f48e88f40b90c156248b8b697c7e2/build.xml#L146] Need to update to Jacoco 0.8.11+: [https://github.com/jacoco/jacoco/releases/tag/v0.8.11] Might as well go to 0.8.12 (latest as of writing). > Update Jacoco dependency for JDK21 support > -- > > Key: CASSANDRA-20041 > URL: https://issues.apache.org/jira/browse/CASSANDRA-20041 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python, Test/fuzz, Test/unit >Reporter: Abe Ratnofsky >Priority: Normal > > Currently, 5.0 and trunk use JDK21 but Jacoco 0.8.8. > > Jacoco 0.8.8 does not support JDK21: > [https://github.com/apache/cassandra/blob/15ed18e9d49f48e88f40b90c156248b8b697c7e2/build.xml#L146] > > Need to update to Jacoco 0.8.11+: > [https://github.com/jacoco/jacoco/releases/tag/v0.8.11] > > Might as well go to 0.8.12 (latest as of writing). -- 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] (CASSANDRA-20001) DefaultSslEngineFactory missing null check on close
[ https://issues.apache.org/jira/browse/CASSANDRA-20001 ]
Abe Ratnofsky deleted comment on CASSANDRA-20001:
---
was (Author: aratnofsky):
https://github.com/apache/cassandra-java-driver/pull/1966
> DefaultSslEngineFactory missing null check on close
> ---
>
> Key: CASSANDRA-20001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20001
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> https://github.com/apache/cassandra-java-driver/blob/72c729b1ba95695fed467ca3734de7a39a2b3201/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L167
> Change is very simple:
> {code:java}
> @Override
> public void close() throws Exception {
> if (kmf != null)
> kmf.close();
> }
> {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-20001) DefaultSslEngineFactory missing null check on close
[
https://issues.apache.org/jira/browse/CASSANDRA-20001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-20001:
--
Test and Documentation Plan: None
Status: Patch Available (was: Open)
https://github.com/apache/cassandra-java-driver/pull/1966
> DefaultSslEngineFactory missing null check on close
> ---
>
> Key: CASSANDRA-20001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20001
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> https://github.com/apache/cassandra-java-driver/blob/72c729b1ba95695fed467ca3734de7a39a2b3201/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L167
> Change is very simple:
> {code:java}
> @Override
> public void close() throws Exception {
> if (kmf != null)
> kmf.close();
> }
> {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-20001) DefaultSslEngineFactory missing null check on close
[
https://issues.apache.org/jira/browse/CASSANDRA-20001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-20001:
--
Bug Category: Parent values: Code(13163)
Complexity: Low Hanging Fruit
Discovered By: Adhoc Test
Severity: Low
Status: Open (was: Triage Needed)
https://github.com/apache/cassandra-java-driver/pull/1966
> DefaultSslEngineFactory missing null check on close
> ---
>
> Key: CASSANDRA-20001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20001
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> https://github.com/apache/cassandra-java-driver/blob/72c729b1ba95695fed467ca3734de7a39a2b3201/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L167
> Change is very simple:
> {code:java}
> @Override
> public void close() throws Exception {
> if (kmf != null)
> kmf.close();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-20001) DefaultSslEngineFactory missing null check on close
Abe Ratnofsky created CASSANDRA-20001:
-
Summary: DefaultSslEngineFactory missing null check on close
Key: CASSANDRA-20001
URL: https://issues.apache.org/jira/browse/CASSANDRA-20001
Project: Cassandra
Issue Type: Bug
Components: Client/java-driver
Reporter: Abe Ratnofsky
Assignee: Abe Ratnofsky
https://github.com/apache/cassandra-java-driver/blob/72c729b1ba95695fed467ca3734de7a39a2b3201/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L167
Change is very simple:
{code:java}
@Override
public void close() throws Exception {
if (kmf != null)
kmf.close();
}
{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-19130) Implement transactional table truncation
[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886402#comment-17886402
]
Abe Ratnofsky commented on CASSANDRA-19130:
---
Yep, that's how dropped columns work. Any objection to making TRUNCATE work the
same way, using mutation timestamps and support USING TIMESTAMP, then we can
get truncate timestamps propagated via TCM? That seems like the best path to
getting good semantics here.
> Implement transactional table truncation
>
>
> Key: CASSANDRA-19130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19130
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
>Reporter: Marcus Eriksson
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TRUNCATE table should leverage cluster metadata to ensure consistent
> truncation timestamps across all replicas. The current implementation depends
> on all nodes being available, but this could be reimplemented as a
> {{Transformation}}.
--
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-19130) Implement transactional table truncation
[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885454#comment-17885454
]
Abe Ratnofsky edited comment on CASSANDRA-19130 at 9/27/24 6:57 PM:
I think we should allow "legacy" truncations coordinated by non-TCM instances
to work as they do now, but reject truncations coordinated by TCM instances
when the cluster contains non-TCM instances. In order to reject truncations
coordinated by non-TCM instances we'd have to roll out a flag to let pre-TCM
instances reject truncation, and users don't always upgrade to the latest minor
before upgrading. So maintaining the legacy behavior when the coordinator is
pre-TCM feels appropriate to me.
TCM coordinators rejecting truncate during mixed-version mode should be fine
too, since currently truncate does not work if any nodes are down, and
mixed-version mode happens during an upgrade when nodes are restarting for
bounces anyway.
That leaves the path when all instances are running TCM.
Firstly - we'll be able to set the truncation timestamp in the coordinator and
propagate it with TCM, so all replicas store the same truncation timestamp in
SystemKeyspace and skip the same mutations during commit log replay. If users
are running concurrent mutations and truncations, then we have undefined
behavior, because replicas that receive a mutation before truncation will drop
the mutation, and replicas that receive a mutation after truncation will keep
that mutation, then drop it when next recovering from the commitlog. We don't
have a means to have an agreed order of the mutation timestamps and truncation
timestamp, since mutation timestamps can be custom but truncation timestamps
are always wall-clock on the coordinator.
If we really want transactional TRUNCATE support, we should have TRUNCATE work
via mutation timestamps (rather than wall-clock timestamps), and support
TRUNCATE USING TIMESTAMP. Users could then expect that after any TRUNCATE no
future reads return data including any mutation timestamp earlier than
truncated_at. Using mutation timestamps would also permit easier integration
with Accord's transactional_mode=full.
>From [~samt]'s earlier comment:
> The way truncation works is that it writes a timestamp into a system table on
> each node, associated with the table being truncated (and a commitlog
> position). Then, when local reads and writes are done against that table, any
> cells with a timestamp earlier than the truncation is essentially discarded.
I'm not seeing this, at least on trunk. SystemKeyspace.getTruncatedAt isn't
called on the read path. This test fails because a single row is returned:
{code:java}
@Test
public void testTruncate()
{
createTable("CREATE TABLE %s (k int PRIMARY KEY, v int)");
SystemKeyspace.saveTruncationRecord(getCurrentColumnFamilyStore(), 101,
CommitLogPosition.NONE);
execute("INSERT INTO %s (k, v) VALUES (1, 1) USING TIMESTAMP ?", 100L);
// Should be empty since truncated after write
assertRowCount(execute("SELECT * FROM %s"), 0);
}
{code}
was (Author: aratnofsky):
I think we should allow "legacy" truncations coordinated by non-TCM instances
to work as they do now, but reject truncations coordinated by TCM instances
when the cluster contains non-TCM instances. In order to reject truncations
coordinated by non-TCM instances we'd have to roll out a flag to let pre-TCM
instances reject truncation, and users don't always upgrade to the latest minor
before upgrading. So maintaining the legacy behavior when the coordinator is
pre-TCM feels appropriate to me.
TCM coordinators rejecting truncate during mixed-version mode should be fine
too, since currently truncate does not work if any nodes are down, and
mixed-version mode happens during an upgrade when nodes are restarting for
bounces anyway.
That leaves the path when all instances are running TCM.
Firstly - we'll be able to set the truncation timestamp in the coordinator and
propagate it with TCM, so all replicas store the same truncation timestamp in
SystemKeyspace and skip the same mutations during commit log replay. If users
are running concurrent mutations and truncations, then we have undefined
behavior, because replicas that receive a mutation before truncation will drop
the mutation, and replicas that receive a mutation after truncation will keep
that mutation, then drop it when next recovering from the commitlog. We don't
have a means to have an agreed order of the mutation timestamps and truncation
timestamp, since mutation timestamps can be custom but truncation timestamps
are always wall-clock on the coordinator.
If we really want transactional TRUNCATE support, we should have TRUNCATE work
via mutation timestamps (rather than wall-clock timestamps), and support
TRUNCATE USING TIMESTA
[jira] [Comment Edited] (CASSANDRA-19130) Implement transactional table truncation
[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885454#comment-17885454
]
Abe Ratnofsky edited comment on CASSANDRA-19130 at 9/27/24 6:56 PM:
I think we should allow "legacy" truncations coordinated by non-TCM instances
to work as they do now, but reject truncations coordinated by TCM instances
when the cluster contains non-TCM instances. In order to reject truncations
coordinated by non-TCM instances we'd have to roll out a flag to let pre-TCM
instances reject truncation, and users don't always upgrade to the latest minor
before upgrading. So maintaining the legacy behavior when the coordinator is
pre-TCM feels appropriate to me.
TCM coordinators rejecting truncate during mixed-version mode should be fine
too, since currently truncate does not work if any nodes are down, and
mixed-version mode happens during an upgrade when nodes are restarting for
bounces anyway.
That leaves the path when all instances are running TCM.
Firstly - we'll be able to set the truncation timestamp in the coordinator and
propagate it with TCM, so all replicas store the same truncation timestamp in
SystemKeyspace and skip the same mutations during commit log replay. If users
are running concurrent mutations and truncations, then we have undefined
behavior, because replicas that receive a mutation before truncation will drop
the mutation, and replicas that receive a mutation after truncation will keep
that mutation, then drop it when next recovering from the commitlog. We don't
have a means to have an agreed order of the mutation timestamps and truncation
timestamp, since mutation timestamps can be custom but truncation timestamps
are always wall-clock on the coordinator.
If we really want transactional TRUNCATE support, we should have TRUNCATE work
via mutation timestamps (rather than wall-clock timestamps), and support
TRUNCATE USING TIMESTAMP. Users could then expect that after any TRUNCATE no
future reads return data including any mutation timestamp earlier than
truncated_at. Using mutation timestamps would also permit easier integration
with Accord's transactional_mode=full.
>From [~samt]'s earlier comment:
> The way truncation works is that it writes a timestamp into a system table on
> each node, associated with the table being truncated (and a commitlog
> position). Then, when local reads and writes are done against that table, any
> cells with a timestamp earlier than the truncation is essentially discarded.
I'm not seeing this, at least on trunk. SystemKeyspace.getTruncatedAt isn't
called on the read path. This test fails because a single row is returned:
{code:java}
@Test
public void testTruncate()
{
createTable("CREATE TABLE %s (k int PRIMARY KEY, v int)");
SystemKeyspace.saveTruncationRecord(getCurrentColumnFamilyStore(), 101,
CommitLogPosition.NONE);
execute("INSERT INTO %s (k, v) VALUES (1, 1) USING TIMESTAMP ?", 100L);
// Should be empty since truncated after write
assertRowCount(execute("SELECT * FROM %s"), 0);
}
{code}
was (Author: aratnofsky):
I think we should allow "legacy" truncations coordinated by non-TCM instances
to work as they do now, but reject truncations coordinated by TCM instances
when the cluster contains non-TCM instances. In order to reject truncations
coordinated by non-TCM instances we'd have to roll out a flag to let pre-TCM
instances reject truncation, and users don't always upgrade to the latest minor
before upgrading. So maintaining the legacy behavior when the coordinator is
pre-TCM feels appropriate to me.
TCM coordinators rejecting truncate during mixed-version mode should be fine
too, since currently truncate does not work if any nodes are down, and
mixed-version mode happens during an upgrade when nodes are restarting for
bounces anyway.
That leaves the path when all instances are running TCM.
Firstly - we'll be able to set the truncation timestamp in the coordinator and
propagate it with TCM, so all replicas store the same truncation timestamp in
SystemKeyspace and skip the same mutations during commit log replay. If users
are running concurrent mutations and truncations, then we have undefined
behavior, because replicas that receive a mutation before truncation will drop
the mutation, and replicas that receive a mutation after truncation will keep
that mutation, then drop it when next recovering from the commitlog. We don't
have a means to have an agreed order of the mutation timestamps and truncation
timestamp, since mutation timestamps can be custom but truncation timestamps
are always wall-clock on the coordinator.
If we really want transactional TRUNCATE support, we should have TRUNCATE work
via mutation timestamps (rather than wall-clock timestamps), and support
TRUNCATE USING TIMESTAMP. Users
[jira] [Comment Edited] (CASSANDRA-19130) Implement transactional table truncation
[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885454#comment-17885454
]
Abe Ratnofsky edited comment on CASSANDRA-19130 at 9/27/24 6:57 PM:
I think we should allow "legacy" truncations coordinated by non-TCM instances
to work as they do now, but reject truncations coordinated by TCM instances
when the cluster contains non-TCM instances. In order to reject truncations
coordinated by non-TCM instances we'd have to roll out a flag to let pre-TCM
instances reject truncation, and users don't always upgrade to the latest minor
before upgrading. So maintaining the legacy behavior when the coordinator is
pre-TCM feels appropriate to me.
TCM coordinators rejecting truncate during mixed-version mode should be fine
too, since currently truncate does not work if any nodes are down, and
mixed-version mode happens during an upgrade when nodes are restarting for
bounces anyway.
That leaves the path when all instances are running TCM.
Firstly - we'll be able to set the truncation timestamp in the coordinator and
propagate it with TCM, so all replicas store the same truncation timestamp in
SystemKeyspace and skip the same mutations during commit log replay. If users
are running concurrent mutations and truncations, then we have undefined
behavior, because replicas that receive a mutation before truncation will drop
the mutation, and replicas that receive a mutation after truncation will keep
that mutation, then drop it when next recovering from the commitlog. We don't
have a means to have an agreed order of the mutation timestamps and truncation
timestamp, since mutation timestamps can be custom but truncation timestamps
are always wall-clock on the coordinator.
If we really want transactional TRUNCATE support, we should have TRUNCATE work
via mutation timestamps (rather than wall-clock timestamps), and support
TRUNCATE USING TIMESTAMP. Users could then expect that after any TRUNCATE no
future reads return data including any mutation timestamp earlier than
truncated_at. Using mutation timestamps would also permit easier integration
with Accord's transactional_mode=full.
>From [~samt]'s earlier comment:
> The way truncation works is that it writes a timestamp into a system table on
> each node, associated with the table being truncated (and a commitlog
> position). Then, when local reads and writes are done against that table, any
> cells with a timestamp earlier than the truncation is essentially discarded.
I'm not seeing this, at least on trunk. SystemKeyspace.getTruncatedAt isn't
called on the read path. This test fails because a single row is returned:
{code:java}
@Test
public void testTruncate()
{
createTable("CREATE TABLE %s (k int PRIMARY KEY, v int)");
SystemKeyspace.saveTruncationRecord(getCurrentColumnFamilyStore(),
101, CommitLogPosition.NONE);
execute("INSERT INTO %s (k, v) VALUES (1, 1) USING TIMESTAMP ?", 100L);
// Should be empty since truncated after write
assertRowCount(execute("SELECT * FROM %s"), 0);
}
{code}
was (Author: aratnofsky):
I think we should allow "legacy" truncations coordinated by non-TCM instances
to work as they do now, but reject truncations coordinated by TCM instances
when the cluster contains non-TCM instances. In order to reject truncations
coordinated by non-TCM instances we'd have to roll out a flag to let pre-TCM
instances reject truncation, and users don't always upgrade to the latest minor
before upgrading. So maintaining the legacy behavior when the coordinator is
pre-TCM feels appropriate to me.
TCM coordinators rejecting truncate during mixed-version mode should be fine
too, since currently truncate does not work if any nodes are down, and
mixed-version mode happens during an upgrade when nodes are restarting for
bounces anyway.
That leaves the path when all instances are running TCM.
Firstly - we'll be able to set the truncation timestamp in the coordinator and
propagate it with TCM, so all replicas store the same truncation timestamp in
SystemKeyspace and skip the same mutations during commit log replay. If users
are running concurrent mutations and truncations, then we have undefined
behavior, because replicas that receive a mutation before truncation will drop
the mutation, and replicas that receive a mutation after truncation will keep
that mutation, then drop it when next recovering from the commitlog. We don't
have a means to have an agreed order of the mutation timestamps and truncation
timestamp, since mutation timestamps can be custom but truncation timestamps
are always wall-clock on the coordinator.
If we really want transactional TRUNCATE support, we should have TRUNCATE work
via mutation timestamps (rather than wall-clock timestamps), and support
TRUNCATE
[jira] [Commented] (CASSANDRA-19130) Implement transactional table truncation
[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885454#comment-17885454
]
Abe Ratnofsky commented on CASSANDRA-19130:
---
I think we should allow "legacy" truncations coordinated by non-TCM instances
to work as they do now, but reject truncations coordinated by TCM instances
when the cluster contains non-TCM instances. In order to reject truncations
coordinated by non-TCM instances we'd have to roll out a flag to let pre-TCM
instances reject truncation, and users don't always upgrade to the latest minor
before upgrading. So maintaining the legacy behavior when the coordinator is
pre-TCM feels appropriate to me.
TCM coordinators rejecting truncate during mixed-version mode should be fine
too, since currently truncate does not work if any nodes are down, and
mixed-version mode happens during an upgrade when nodes are restarting for
bounces anyway.
That leaves the path when all instances are running TCM.
Firstly - we'll be able to set the truncation timestamp in the coordinator and
propagate it with TCM, so all replicas store the same truncation timestamp in
SystemKeyspace and skip the same mutations during commit log replay. If users
are running concurrent mutations and truncations, then we have undefined
behavior, because replicas that receive a mutation before truncation will drop
the mutation, and replicas that receive a mutation after truncation will keep
that mutation, then drop it when next recovering from the commitlog. We don't
have a means to have an agreed order of the mutation timestamps and truncation
timestamp, since mutation timestamps can be custom but truncation timestamps
are always wall-clock on the coordinator.
If we really want transactional TRUNCATE support, we should have TRUNCATE work
via mutation timestamps (rather than wall-clock timestamps), and support
TRUNCATE USING TIMESTAMP. Users could then expect that after any TRUNCATE no
future reads return data including any mutation timestamp earlier than
truncated_at. Using mutation timestamps would also permit easier integration
with Accord's transactional_mode=full.
>From [~samt]'s earlier comment:
> The way truncation works is that it writes a timestamp into a system table on
> each node, associated with the table being truncated (and a commitlog
> position). Then, when local reads and writes are done against that table, any
> cells with a timestamp earlier than the truncation is essentially discarded.
I'm not seeing this, at least on trunk. SystemKeyspace.getTruncatedAt isn't
called on the read path. This test fails because a single row is returned:
{code:java}
@Test
public void testTruncate()
{
createTable("CREATE TABLE %s (k int PRIMARY KEY, v int)");
SystemKeyspace.saveTruncationRecord(getCurrentColumnFamilyStore(), 101,
CommitLogPosition.NONE);
execute("INSERT INTO %s (k, v) VALUES (1, 1) USING TIMESTAMP ?", 100L);
// Should be empty since truncated after write
assertRowCount(execute("SELECT * FROM %s"), 0);
}
{code}
> Implement transactional table truncation
>
>
> Key: CASSANDRA-19130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19130
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
>Reporter: Marcus Eriksson
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TRUNCATE table should leverage cluster metadata to ensure consistent
> truncation timestamps across all replicas. The current implementation depends
> on all nodes being available, but this could be reimplemented as a
> {{Transformation}}.
--
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-19903) Add guardrail for enabling usage of VectorType
[
https://issues.apache.org/jira/browse/CASSANDRA-19903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879957#comment-17879957
]
Abe Ratnofsky commented on CASSANDRA-19903:
---
Here's the 5.0 PR as well: https://github.com/apache/cassandra/pull/3525
> Add guardrail for enabling usage of VectorType
> --
>
> Key: CASSANDRA-19903
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19903
> Project: Cassandra
> Issue Type: New Feature
> Components: Cluster/Schema
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Add a guardrail to allow operators to toggle support for the new Vector type.
> This is a precaution that operators may desire when working with clusters
> than have a diverse set of clients, and some clients may not yet support the
> new vector type. Those clients may fail when fetching metadata ("unexpected
> column type") and prevent session establishment, or fail to query vector
> columns, or otherwise behave strangely.
>
> Patch is ready here:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-X-guardrail-vector-enable
--
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-19903) Add guardrail for enabling usage of VectorType
[
https://issues.apache.org/jira/browse/CASSANDRA-19903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19903:
--
Test and Documentation Plan: Unit tests
Status: Patch Available (was: In Progress)
PR: https://github.com/apache/cassandra/pull/3524
> Add guardrail for enabling usage of VectorType
> --
>
> Key: CASSANDRA-19903
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19903
> Project: Cassandra
> Issue Type: New Feature
> Components: Cluster/Schema
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add a guardrail to allow operators to toggle support for the new Vector type.
> This is a precaution that operators may desire when working with clusters
> than have a diverse set of clients, and some clients may not yet support the
> new vector type. Those clients may fail when fetching metadata ("unexpected
> column type") and prevent session establishment, or fail to query vector
> columns, or otherwise behave strangely.
>
> Patch is ready here:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-X-guardrail-vector-enable
--
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-19903) Add guardrail for enabling usage of VectorType
[
https://issues.apache.org/jira/browse/CASSANDRA-19903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19903:
--
Change Category: Operability
Complexity: Normal
Component/s: Cluster/Schema
Reviewers: Caleb Rackliffe
Status: Open (was: Triage Needed)
> Add guardrail for enabling usage of VectorType
> --
>
> Key: CASSANDRA-19903
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19903
> Project: Cassandra
> Issue Type: New Feature
> Components: Cluster/Schema
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> Add a guardrail to allow operators to toggle support for the new Vector type.
> This is a precaution that operators may desire when working with clusters
> than have a diverse set of clients, and some clients may not yet support the
> new vector type. Those clients may fail when fetching metadata ("unexpected
> column type") and prevent session establishment, or fail to query vector
> columns, or otherwise behave strangely.
>
> Patch is ready here:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-X-guardrail-vector-enable
--
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-19903) Add guardrail for enabling usage of VectorType
Abe Ratnofsky created CASSANDRA-19903:
-
Summary: Add guardrail for enabling usage of VectorType
Key: CASSANDRA-19903
URL: https://issues.apache.org/jira/browse/CASSANDRA-19903
Project: Cassandra
Issue Type: New Feature
Reporter: Abe Ratnofsky
Assignee: Abe Ratnofsky
Add a guardrail to allow operators to toggle support for the new Vector type.
This is a precaution that operators may desire when working with clusters than
have a diverse set of clients, and some clients may not yet support the new
vector type. Those clients may fail when fetching metadata ("unexpected column
type") and prevent session establishment, or fail to query vector columns, or
otherwise behave strangely.
Patch is ready here:
https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-X-guardrail-vector-enable
--
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-19817) PasswordAuthenticator accepts passwords with matching prefixes exceeding bcrypt length limit
[
https://issues.apache.org/jira/browse/CASSANDRA-19817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871784#comment-17871784
]
Abe Ratnofsky commented on CASSANDRA-19817:
---
Minor correction on above - server would response with the ClientWarn on an
AuthSuccess message, not AuthResponse, which is the response from the client
that contains the password.
> PasswordAuthenticator accepts passwords with matching prefixes exceeding
> bcrypt length limit
>
>
> Key: CASSANDRA-19817
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19817
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Abe Ratnofsky
>Priority: Normal
>
> Cassandra allows roles to be created with passwords longer than the bcrypt
> length limit of 72 bytes[1]. All passwords sharing a 72-byte prefix have the
> same bcrypt hash, so users can authenticate with passwords that do not
> exactly match a role's configured password.
>
> Users expect authentication to only happen when there is an exact match
> between a role's configured password and the password provided by an agent
> authenticating against that role.
> I have a few elements to propose:
> 1. Cassandra rejects creation of passwords (via CREATE ROLE or ALTER ROLE)
> that exceed the 72-byte limit
> 2. Cassandra logs a server-side warning (not ClientWarn) when a role's
> password exceeds the length limit, recommending a password change, with
> NoSpamLogger
> Thanks to Stefan Miklosovic for investigating this with me.
> As for proof, here's a failing test:
> {code:java}
> import org.mindrot.jbcrypt.BCrypt;
> public class PasswordCollisionTest
> {
> @Test
> public void testLongPassword() throws Exception
>
> { String longpassword =
> "";
> String salt = BCrypt.gensalt(); String longhashed =
> BCrypt.hashpw(longpassword, salt);
> Assert.assertTrue(BCrypt.checkpw(longpassword, longhashed)); String
> longerpassword = longpassword + "bbb"; String longerhashed =
> BCrypt.hashpw(longerpassword, salt);
> Assert.assertNotEquals(longerhashed, longhashed); }
> }
> {code}
>
> Here's a similar test as an end-user would experience it, against recent
> trunk (fe30e227bdedf13f890e242d2646598398ba8bed):
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> cassandra@cqlsh> CREATE ROLE longpassword WITH PASSWORD =
> ''
> AND LOGIN = true;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
>
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
> bbb
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> {code}
>
> [1]: [https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length]
--
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-19817) PasswordAuthenticator accepts passwords with matching prefixes exceeding bcrypt length limit
[
https://issues.apache.org/jira/browse/CASSANDRA-19817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871784#comment-17871784
]
Abe Ratnofsky edited comment on CASSANDRA-19817 at 8/7/24 8:14 PM:
---
Minor correction on above - server would respond with the ClientWarn on an
AuthSuccess message, not AuthResponse, which is the response from the client
that contains the password.
was (Author: aratnofsky):
Minor correction on above - server would response with the ClientWarn on an
AuthSuccess message, not AuthResponse, which is the response from the client
that contains the password.
> PasswordAuthenticator accepts passwords with matching prefixes exceeding
> bcrypt length limit
>
>
> Key: CASSANDRA-19817
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19817
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Abe Ratnofsky
>Priority: Normal
>
> Cassandra allows roles to be created with passwords longer than the bcrypt
> length limit of 72 bytes[1]. All passwords sharing a 72-byte prefix have the
> same bcrypt hash, so users can authenticate with passwords that do not
> exactly match a role's configured password.
>
> Users expect authentication to only happen when there is an exact match
> between a role's configured password and the password provided by an agent
> authenticating against that role.
> I have a few elements to propose:
> 1. Cassandra rejects creation of passwords (via CREATE ROLE or ALTER ROLE)
> that exceed the 72-byte limit
> 2. Cassandra logs a server-side warning (not ClientWarn) when a role's
> password exceeds the length limit, recommending a password change, with
> NoSpamLogger
> Thanks to Stefan Miklosovic for investigating this with me.
> As for proof, here's a failing test:
> {code:java}
> import org.mindrot.jbcrypt.BCrypt;
> public class PasswordCollisionTest
> {
> @Test
> public void testLongPassword() throws Exception
>
> { String longpassword =
> "";
> String salt = BCrypt.gensalt(); String longhashed =
> BCrypt.hashpw(longpassword, salt);
> Assert.assertTrue(BCrypt.checkpw(longpassword, longhashed)); String
> longerpassword = longpassword + "bbb"; String longerhashed =
> BCrypt.hashpw(longerpassword, salt);
> Assert.assertNotEquals(longerhashed, longhashed); }
> }
> {code}
>
> Here's a similar test as an end-user would experience it, against recent
> trunk (fe30e227bdedf13f890e242d2646598398ba8bed):
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> cassandra@cqlsh> CREATE ROLE longpassword WITH PASSWORD =
> ''
> AND LOGIN = true;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
>
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
> bbb
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> {code}
>
> [1]: [https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length]
--
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-19817) PasswordAuthenticator accepts passwords with matching prefixes exceeding bcrypt length limit
[
https://issues.apache.org/jira/browse/CASSANDRA-19817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871783#comment-17871783
]
Abe Ratnofsky commented on CASSANDRA-19817:
---
I'm not strongly against a ClientWarn, but I didn't propose that for two
reasons:
# Last time I checked, most clients don't correctly log ClientWarnings
included in non-RESULTS messages on the native protocol, but we should fix that
in the drivers we can control. IIRC, there are no non-RESULTS ClientWarn yet,
but I haven't checked back in a little while. If we do include a ClientWarn on
an AUTH_RESPONSE and the client's driver doesn't log it, the user won't see it.
# Client authentication can happen frequently, and we don't want to sent a
ClientWarn on every authentication attempt. We could keep an expiring map of
last time we ClientWarn'd a particular role, and skip the warning again if the
last one was too recent.
Both of the above can be addressed - I'd support a patch that logs a warning to
both clients and operators.
> PasswordAuthenticator accepts passwords with matching prefixes exceeding
> bcrypt length limit
>
>
> Key: CASSANDRA-19817
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19817
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Abe Ratnofsky
>Priority: Normal
>
> Cassandra allows roles to be created with passwords longer than the bcrypt
> length limit of 72 bytes[1]. All passwords sharing a 72-byte prefix have the
> same bcrypt hash, so users can authenticate with passwords that do not
> exactly match a role's configured password.
>
> Users expect authentication to only happen when there is an exact match
> between a role's configured password and the password provided by an agent
> authenticating against that role.
> I have a few elements to propose:
> 1. Cassandra rejects creation of passwords (via CREATE ROLE or ALTER ROLE)
> that exceed the 72-byte limit
> 2. Cassandra logs a server-side warning (not ClientWarn) when a role's
> password exceeds the length limit, recommending a password change, with
> NoSpamLogger
> Thanks to Stefan Miklosovic for investigating this with me.
> As for proof, here's a failing test:
> {code:java}
> import org.mindrot.jbcrypt.BCrypt;
> public class PasswordCollisionTest
> {
> @Test
> public void testLongPassword() throws Exception
>
> { String longpassword =
> "";
> String salt = BCrypt.gensalt(); String longhashed =
> BCrypt.hashpw(longpassword, salt);
> Assert.assertTrue(BCrypt.checkpw(longpassword, longhashed)); String
> longerpassword = longpassword + "bbb"; String longerhashed =
> BCrypt.hashpw(longerpassword, salt);
> Assert.assertNotEquals(longerhashed, longhashed); }
> }
> {code}
>
> Here's a similar test as an end-user would experience it, against recent
> trunk (fe30e227bdedf13f890e242d2646598398ba8bed):
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> cassandra@cqlsh> CREATE ROLE longpassword WITH PASSWORD =
> ''
> AND LOGIN = true;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
>
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
> bbb
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> {code}
>
> [1]: [https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length]
--
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-19817) PasswordAuthenticator accepts passwords with matching prefixes exceeding bcrypt length limit
[
https://issues.apache.org/jira/browse/CASSANDRA-19817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871776#comment-17871776
]
Abe Ratnofsky commented on CASSANDRA-19817:
---
I'm suggesting rejecting new passwords over the length limit, and
server-warning when users authenticate with passwords over the length limit but
still letting those users log in as-usual. The server-warning would just let
operators know that their users are running in less-than-secure configurations,
so the operator could contact those users to change their passwords.
> PasswordAuthenticator accepts passwords with matching prefixes exceeding
> bcrypt length limit
>
>
> Key: CASSANDRA-19817
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19817
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Abe Ratnofsky
>Priority: Normal
>
> Cassandra allows roles to be created with passwords longer than the bcrypt
> length limit of 72 bytes[1]. All passwords sharing a 72-byte prefix have the
> same bcrypt hash, so users can authenticate with passwords that do not
> exactly match a role's configured password.
>
> Users expect authentication to only happen when there is an exact match
> between a role's configured password and the password provided by an agent
> authenticating against that role.
> I have a few elements to propose:
> 1. Cassandra rejects creation of passwords (via CREATE ROLE or ALTER ROLE)
> that exceed the 72-byte limit
> 2. Cassandra logs a server-side warning (not ClientWarn) when a role's
> password exceeds the length limit, recommending a password change, with
> NoSpamLogger
> Thanks to Stefan Miklosovic for investigating this with me.
> As for proof, here's a failing test:
> {code:java}
> import org.mindrot.jbcrypt.BCrypt;
> public class PasswordCollisionTest
> {
> @Test
> public void testLongPassword() throws Exception
>
> { String longpassword =
> "";
> String salt = BCrypt.gensalt(); String longhashed =
> BCrypt.hashpw(longpassword, salt);
> Assert.assertTrue(BCrypt.checkpw(longpassword, longhashed)); String
> longerpassword = longpassword + "bbb"; String longerhashed =
> BCrypt.hashpw(longerpassword, salt);
> Assert.assertNotEquals(longerhashed, longhashed); }
> }
> {code}
>
> Here's a similar test as an end-user would experience it, against recent
> trunk (fe30e227bdedf13f890e242d2646598398ba8bed):
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> cassandra@cqlsh> CREATE ROLE longpassword WITH PASSWORD =
> ''
> AND LOGIN = true;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
>
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
> bbb
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> {code}
>
> [1]: [https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length]
--
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-19817) PasswordAuthenticator accepts passwords with matching prefixes exceeding bcrypt length limit
[
https://issues.apache.org/jira/browse/CASSANDRA-19817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19817:
--
Description:
Cassandra allows roles to be created with passwords longer than the bcrypt
length limit of 72 bytes[1]. All passwords sharing a 72-byte prefix have the
same bcrypt hash, so users can authenticate with passwords that do not exactly
match a role's configured password.
Users expect authentication to only happen when there is an exact match between
a role's configured password and the password provided by an agent
authenticating against that role.
I have a few elements to propose:
1. Cassandra rejects creation of passwords (via CREATE ROLE or ALTER ROLE) that
exceed the 72-byte limit
2. Cassandra logs a server-side warning (not ClientWarn) when a role's password
exceeds the length limit, recommending a password change, with NoSpamLogger
Thanks to Stefan Miklosovic for investigating this with me.
As for proof, here's a failing test:
{code:java}
import org.mindrot.jbcrypt.BCrypt;
public class PasswordCollisionTest
{
@Test
public void testLongPassword() throws Exception
{ String longpassword =
"";
String salt = BCrypt.gensalt(); String longhashed =
BCrypt.hashpw(longpassword, salt);
Assert.assertTrue(BCrypt.checkpw(longpassword, longhashed)); String
longerpassword = longpassword + "bbb"; String longerhashed =
BCrypt.hashpw(longerpassword, salt);
Assert.assertNotEquals(longerhashed, longhashed); }
}
{code}
Here's a similar test as an end-user would experience it, against recent trunk
(fe30e227bdedf13f890e242d2646598398ba8bed):
{code:java}
$ ./bin/cqlsh -u cassandra -p cassandra
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
Use HELP for help.
cassandra@cqlsh> CREATE ROLE longpassword WITH PASSWORD =
''
AND LOGIN = true;
cassandra@cqlsh> exit;
$ ./bin/cqlsh -u longpassword -p
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
Use HELP for help.
longpassword@cqlsh> exit;
$ ./bin/cqlsh -u longpassword -p
bbb
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
Use HELP for help.
longpassword@cqlsh> exit;
{code}
[1]: [https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length]
was:
Cassandra allows roles to be created with passwords longer than the bcrypt
length limit of 72 bytes[1]. All passwords sharing a 72-byte prefix have the
same bcrypt hash, so users can authenticate with passwords that do not exactly
match a role's configured password.
Users expect authentication to only happen when there is an exact match between
a role's configured password and the password provided by an agent
authenticating against that role.
I have a few elements to propose:
1. Cassandra rejects creation of passwords (via CREATE ROLE or ALTER ROLE) that
exceed the 72-byte limit
2. Cassandra logs a server-side warning (not ClientWarn) when a role's password
exceeds the length limit, recommending a password change, with NoSpamLogger
Thanks to Stefan Miklosovic for investigating this with me.
As for proof, here's a failing test:
```
import org.mindrot.jbcrypt.BCrypt;
public class PasswordCollisionTest
{
@Test
public void testLongPassword() throws Exception
{
String longpassword =
"";
String salt = BCrypt.gensalt();
String longhashed = BCrypt.hashpw(longpassword, salt);
Assert.assertTrue(BCrypt.checkpw(longpassword, longhashed));
String longerpassword = longpassword + "bbb";
String longerhashed = BCrypt.hashpw(longerpassword, salt);
Assert.assertNotEquals(longerhashed, longhashed);
}
}
```
Here's a similar test as an end-user would experience it, against recent trunk
(fe30e227bdedf13f890e242d2646598398ba8bed):
```
$ ./bin/cqlsh -u cassandra -p cassandra
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
Use HELP for help.
cassandra@cqlsh> CREATE ROLE longpassword WITH PASSWORD =
''
AND LOGIN = true;
cassandra@cqlsh> exit;
$ ./bin/cqlsh -u longpassword -p
aaa
[jira] [Updated] (CASSANDRA-19817) PasswordAuthenticator accepts passwords with matching prefixes exceeding bcrypt length limit
[
https://issues.apache.org/jira/browse/CASSANDRA-19817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19817:
--
Impacts: (was: None)
> PasswordAuthenticator accepts passwords with matching prefixes exceeding
> bcrypt length limit
>
>
> Key: CASSANDRA-19817
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19817
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Abe Ratnofsky
>Priority: Normal
>
> Cassandra allows roles to be created with passwords longer than the bcrypt
> length limit of 72 bytes[1]. All passwords sharing a 72-byte prefix have the
> same bcrypt hash, so users can authenticate with passwords that do not
> exactly match a role's configured password.
>
> Users expect authentication to only happen when there is an exact match
> between a role's configured password and the password provided by an agent
> authenticating against that role.
> I have a few elements to propose:
> 1. Cassandra rejects creation of passwords (via CREATE ROLE or ALTER ROLE)
> that exceed the 72-byte limit
> 2. Cassandra logs a server-side warning (not ClientWarn) when a role's
> password exceeds the length limit, recommending a password change, with
> NoSpamLogger
> Thanks to Stefan Miklosovic for investigating this with me.
> As for proof, here's a failing test:
> ```
> import org.mindrot.jbcrypt.BCrypt;
> public class PasswordCollisionTest
> {
> @Test
> public void testLongPassword() throws Exception
> {
> String longpassword =
> "";
> String salt = BCrypt.gensalt();
> String longhashed = BCrypt.hashpw(longpassword, salt);
> Assert.assertTrue(BCrypt.checkpw(longpassword, longhashed));
> String longerpassword = longpassword + "bbb";
> String longerhashed = BCrypt.hashpw(longerpassword, salt);
> Assert.assertNotEquals(longerhashed, longhashed);
> }
> }
> ```
> Here's a similar test as an end-user would experience it, against recent
> trunk (fe30e227bdedf13f890e242d2646598398ba8bed):
> ```
> $ ./bin/cqlsh -u cassandra -p cassandra
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> cassandra@cqlsh> CREATE ROLE longpassword WITH PASSWORD =
> ''
> AND LOGIN = true;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
>
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> $ ./bin/cqlsh -u longpassword -p
> bbb
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> Use HELP for help.
> longpassword@cqlsh> exit;
> ```
> [1]: [https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length]
--
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-19817) PasswordAuthenticator accepts passwords with matching prefixes exceeding bcrypt length limit
Abe Ratnofsky created CASSANDRA-19817:
-
Summary: PasswordAuthenticator accepts passwords with matching
prefixes exceeding bcrypt length limit
Key: CASSANDRA-19817
URL: https://issues.apache.org/jira/browse/CASSANDRA-19817
Project: Cassandra
Issue Type: Bug
Components: Messaging/Client
Reporter: Abe Ratnofsky
Cassandra allows roles to be created with passwords longer than the bcrypt
length limit of 72 bytes[1]. All passwords sharing a 72-byte prefix have the
same bcrypt hash, so users can authenticate with passwords that do not exactly
match a role's configured password.
Users expect authentication to only happen when there is an exact match between
a role's configured password and the password provided by an agent
authenticating against that role.
I have a few elements to propose:
1. Cassandra rejects creation of passwords (via CREATE ROLE or ALTER ROLE) that
exceed the 72-byte limit
2. Cassandra logs a server-side warning (not ClientWarn) when a role's password
exceeds the length limit, recommending a password change, with NoSpamLogger
Thanks to Stefan Miklosovic for investigating this with me.
As for proof, here's a failing test:
```
import org.mindrot.jbcrypt.BCrypt;
public class PasswordCollisionTest
{
@Test
public void testLongPassword() throws Exception
{
String longpassword =
"";
String salt = BCrypt.gensalt();
String longhashed = BCrypt.hashpw(longpassword, salt);
Assert.assertTrue(BCrypt.checkpw(longpassword, longhashed));
String longerpassword = longpassword + "bbb";
String longerhashed = BCrypt.hashpw(longerpassword, salt);
Assert.assertNotEquals(longerhashed, longhashed);
}
}
```
Here's a similar test as an end-user would experience it, against recent trunk
(fe30e227bdedf13f890e242d2646598398ba8bed):
```
$ ./bin/cqlsh -u cassandra -p cassandra
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
Use HELP for help.
cassandra@cqlsh> CREATE ROLE longpassword WITH PASSWORD =
''
AND LOGIN = true;
cassandra@cqlsh> exit;
$ ./bin/cqlsh -u longpassword -p
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
Use HELP for help.
longpassword@cqlsh> exit;
$ ./bin/cqlsh -u longpassword -p
bbb
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
Use HELP for help.
longpassword@cqlsh> exit;
```
[1]: [https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length]
--
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-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers
[
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866781#comment-17866781
]
Abe Ratnofsky commented on CASSANDRA-19765:
---
> but on the other hand you want to be nice enough to warn them that the access
> to that is going to be stopped and you do not want to do that abruptly
It's not our decision as authors whether to break workloads abruptly, it's the
operator's decision. The flag exists so an upgrade to a new version of
Cassandra does not break workloads by default; an operator can decide to start
up in an incompatible mode if they prefer.
I understand that this doesn't feel idiomatic to you; I would have also
preferred to implement behavior like this with per-column permissions, but that
doesn't currently exist, and extending the permissions hierarchy would be a
consequential change. I'm open to discussing other approaches. Changing the set
of permissions inferred by GRANT SELECT ON ALL KEYSPACES would also break user
workloads. We could just have a NEWS.txt entry stating our recommendation to
REVOKE SELECT on system_auth.roles for non-superusers, but a reasonable
operator could ask how to know usage of that table. Maybe the answer for them
is to use FQL?
> Remove accessibility to system_auth.roles salted_hash for non-superusers
>
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access
> contents of the salted_hash column. This column contains a bcrypt hash, which
> shouldn't be visible. This isn't a significant security risk at the current
> time, but is prone to [retrospective
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We
> should protect this column so passwords cannot be cracked in the future.
>
>
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
> cassandra | True | True | null |
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
> nonsuperuser | True | False | null |
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>
> Patches available:
> 3.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk
--
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-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers
[
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865492#comment-17865492
]
Abe Ratnofsky commented on CASSANDRA-19765:
---
It's common for tools or environments to GRANT SELECT ON ALL KEYSPACES for all
user roles, so it's fair to assume that lots of roles in the wild currently
have SELECT on system_auth.roles. I agree that handling on the GRANT is
preferred for new roles, but even still we don't have a good way to restrict
access to a single column. Another alternative would be to move salted_hash out
of system_auth.roles into a separate table, much like the new IDENTITY_TO_ROLES
table, so that table gets its own GRANT access.
The current design of this patch is meant to limit leakage for roles that
already exist, and minimize breakage that would happen if we changed the
definition of "GRANT SELECT ON ALL KEYSPACES".
> Remove accessibility to system_auth.roles salted_hash for non-superusers
>
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access
> contents of the salted_hash column. This column contains a bcrypt hash, which
> shouldn't be visible. This isn't a significant security risk at the current
> time, but is prone to [retrospective
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We
> should protect this column so passwords cannot be cracked in the future.
>
>
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
> cassandra | True | True | null |
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
> nonsuperuser | True | False | null |
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>
> Patches available:
> 3.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk
--
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-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers
[
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865396#comment-17865396
]
Abe Ratnofsky commented on CASSANDRA-19765:
---
[~smiklosovic] I don't think most users expect GRANT SELECT ON ALL KEYSPACES on
a blank cluster to include any sensitive information, and often that approach
is used since tools depend on system keyspaces (specifically: drivers depend on
local, peers, peers_v2, Spark Cassandra Connector depends on size_estimates,
table_estimates, etc.)
There is a separate discussion to be had around how to give the right tools the
right permissions, but permission-tightening across the entire resource
hierarchy is complicated and blocking access to just this column is fairly
simple.
> Remove accessibility to system_auth.roles salted_hash for non-superusers
>
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access
> contents of the salted_hash column. This column contains a bcrypt hash, which
> shouldn't be visible. This isn't a significant security risk at the current
> time, but is prone to [retrospective
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We
> should protect this column so passwords cannot be cracked in the future.
>
>
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
> cassandra | True | True | null |
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
> nonsuperuser | True | False | null |
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>
> Patches available:
> 3.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk
--
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-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers
[
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19765:
--
Test and Documentation Plan: Unit tests, default behavior is
backwards-compatible
Status: Patch Available (was: Open)
> Remove accessibility to system_auth.roles salted_hash for non-superusers
>
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access
> contents of the salted_hash column. This column contains a bcrypt hash, which
> shouldn't be visible. This isn't a significant security risk at the current
> time, but is prone to [retrospective
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We
> should protect this column so passwords cannot be cracked in the future.
>
>
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
> cassandra | True | True | null |
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
> nonsuperuser | True | False | null |
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>
> Patches available:
> 3.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk
--
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-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers
[
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19765:
--
Change Category: Operability
Complexity: Low Hanging Fruit
Component/s: Legacy/Core
Fix Version/s: 3.0.x
3.11.x
4.0.x
4.1.x
5.0.x
Status: Open (was: Triage Needed)
> Remove accessibility to system_auth.roles salted_hash for non-superusers
>
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access
> contents of the salted_hash column. This column contains a bcrypt hash, which
> shouldn't be visible. This isn't a significant security risk at the current
> time, but is prone to [retrospective
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We
> should protect this column so passwords cannot be cracked in the future.
>
>
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
> cassandra | True | True | null |
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
> nonsuperuser | True | False | null |
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>
> Patches available:
> 3.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk
--
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-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers
[
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19765:
--
Description:
Cassandra permits all users with SELECT on system_auth.roles to access contents
of the salted_hash column. This column contains a bcrypt hash, which shouldn't
be visible. This isn't a significant security risk at the current time, but is
prone to [retrospective
decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We should
protect this column so passwords cannot be cracked in the future.
{code:java}
$ ./bin/cqlsh -u cassandra -p cassandra
[cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND
PASSWORD='nonsuperuser';
cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
cassandra@cqlsh> exit;
$ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
[cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
role | can_login | is_superuser | member_of | salted_hash
--+---+--+---+--
cassandra | True | True | null |
$2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
nonsuperuser | True | False | null |
$2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
(2 rows)
{code}
Patches available:
3.0:
https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
3.11:
https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
4.0:
https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
4.1:
https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
5.0:
https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
trunk:
https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk
> Remove accessibility to system_auth.roles salted_hash for non-superusers
>
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> Cassandra permits all users with SELECT on system_auth.roles to access
> contents of the salted_hash column. This column contains a bcrypt hash, which
> shouldn't be visible. This isn't a significant security risk at the current
> time, but is prone to [retrospective
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We
> should protect this column so passwords cannot be cracked in the future.
>
>
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
> role | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
> cassandra | True | True | null |
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
> nonsuperuser | True | False | null |
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>
> Patches available:
> 3.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk:
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
--
[jira] [Updated] (CASSANDRA-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers
[ https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19765: -- Impacts: Security (was: None) > Remove accessibility to system_auth.roles salted_hash for non-superusers > > > Key: CASSANDRA-19765 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19765 > Project: Cassandra > Issue Type: Improvement >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers
[ https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19765: -- Summary: Remove accessibility to system_auth.roles salted_hash for non-superusers (was: TBD) > Remove accessibility to system_auth.roles salted_hash for non-superusers > > > Key: CASSANDRA-19765 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19765 > Project: Cassandra > Issue Type: Improvement >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19765) TBD
Abe Ratnofsky created CASSANDRA-19765: - Summary: TBD Key: CASSANDRA-19765 URL: https://issues.apache.org/jira/browse/CASSANDRA-19765 Project: Cassandra Issue Type: Improvement Reporter: Abe Ratnofsky Assignee: Abe Ratnofsky -- 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-19130) Implement transactional table truncation
[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837866#comment-17837866
]
Abe Ratnofsky commented on CASSANDRA-19130:
---
I actually wonder if we should make truncation "lazier": rather than removing
SSTables within TruncateVerbHandler (and keeping SSTables with maxDataAge >
truncatedAt), just record the agreed-upon truncation timestamp in TCM, then in
compaction remove entire SSTables with maxDataAge <= truncatedAt, and remove
all cells with earlier mutation timestamps. When we're handling a Truncation
transformation in TCM (via TableTruncationListener), kick off a local
truncation compaction. Once the compaction completes, we can purged the
truncatedAt marker in the system table.
On the read path, we'd also filter returned cells by mutation timestamps, and
exclude SSTables with maxDataAge <= truncatedAt.
The benefits of this are: clearer semantics (don't need to depend on flush /
snapshot timing), friendlier to the key and row cache (could purge only as
necessary). The main downside would be that truncate couldn't be used for
emergency disk reclaim, but I think that use-case belongs in nodetool not CQL
anyway.
> Implement transactional table truncation
>
>
> Key: CASSANDRA-19130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19130
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
>Reporter: Marcus Eriksson
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TRUNCATE table should leverage cluster metadata to ensure consistent
> truncation timestamps across all replicas. The current implementation depends
> on all nodes being available, but this could be reimplemented as a
> {{Transformation}}.
--
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-19130) Implement transactional table truncation
[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837854#comment-17837854
]
Abe Ratnofsky commented on CASSANDRA-19130:
---
> What happens with the truncation when there is a mixed cluster in place?
I would think that we should continue handle TruncateStatement in the pre-TCM
way, even when coordinated by an instance running with TCM, until the entire
cluster is known to be on TCM. Specifically, that would mean checking that all
instances are available, sending TRUNCATE_REQ to all peers and waiting for
responses, etc. Once the entire cluster is on TCM, we stop sending TRUNCATE_REQ
and ignore received TRUNCATE_REQ[1], and from then onwards all execution of
truncate happens via the TCM log listener.
[1]: We should warn if we receive a TRUNCATE_REQ after the entire cluster is on
TCM, since it should only be possible to receive one if a strange message
delivery happens from a pre-upgraded instance
> Implement transactional table truncation
>
>
> Key: CASSANDRA-19130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19130
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
>Reporter: Marcus Eriksson
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TRUNCATE table should leverage cluster metadata to ensure consistent
> truncation timestamps across all replicas. The current implementation depends
> on all nodes being available, but this could be reimplemented as a
> {{Transformation}}.
--
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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837468#comment-17837468 ] Abe Ratnofsky commented on CASSANDRA-19532: --- I forgot to update conf/cassandra.yaml and conf/cassandra_latest.yaml, thanks Stefan for catching that. Just fixed those and uploaded new test results, no failures related to my changes. > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary-1.html > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Attachment: ci_summary-1.html > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary-1.html > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Attachment: (was: ci_summary.html) > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary-1.html > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Attachment: (was: result_details.tar.gz) > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary-1.html > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836331#comment-17836331 ] Abe Ratnofsky commented on CASSANDRA-19532: --- Attached test results > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Attachment: ci_summary.html result_details.tar.gz > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Description: Currently, triggers are discouraged but there's no explicit way to disable them. Similar configuration already exists to disable other features, such as "conf.materialized_views_enabled". There should be a means for operators to gracefully disable the creation and execution of triggers. (was: Currently, triggers are discouraged but there's no explicit way to disable them. Similar configuration already exists to disable other features, such as "conf.materialized_views_enabled". There should be a means for operators to gracefully disable the creation and execution of triggers. I have a patch ready for this, getting a first review now and will push it shortly.) > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17835536#comment-17835536 ] Abe Ratnofsky commented on CASSANDRA-19532: --- One of the goals here is to add another layer of defense for users that don't use triggers but want to block their execution in case someone gets write access to conf/triggers. I initially had support for a JMX endpoint to change TriggersPolicy but felt (along with [~samt]) that it added another attack vector rather than strengthening the security of the system. As far as Guardrails - I see what you mean. I could convert TriggersPolicy.disabled to warn and TriggersPolicy.forbidden to fail, and guard in TriggerExecutor#loadTriggerInstance where I throw TriggersDisabledException. I do want to execute the query but not the triggers on "warn", I'm not sure if that's an intuitive use of Guardrails or stretching the definition too far though. Is there anything I'm missing that Guardrails gets us? > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. > > I have a patch ready for this, getting a first review now and will push it > shortly. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Impacts: Security (was: None) Test and Documentation Plan: Unit tests and inline documentation Status: Patch Available (was: Open) Trunk PR: https://github.com/apache/cassandra/pull/3240 > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. > > I have a patch ready for this, getting a first review now and will push it > shortly. -- 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-19532) Allow operators to disable the execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Summary: Allow operators to disable the execution of triggers (was: Allow operators to disable the creation and execution of triggers) > Allow operators to disable the execution of triggers > > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. > > I have a patch ready for this, getting a first review now and will push it > shortly. -- 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-19532) Allow operators to disable the creation and execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Reviewers: Sam Tunnicliffe, Stefan Miklosovic (was: Stefan Miklosovic) > Allow operators to disable the creation and execution of triggers > - > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. > > I have a patch ready for this, getting a first review now and will push it > shortly. -- 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-19532) Allow operators to disable the creation and execution of triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19532: -- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Allow operators to disable the creation and execution of triggers > - > > Key: CASSANDRA-19532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, triggers are discouraged but there's no explicit way to disable > them. Similar configuration already exists to disable other features, such as > "conf.materialized_views_enabled". There should be a means for operators to > gracefully disable the creation and execution of triggers. > > I have a patch ready for this, getting a first review now and will push it > shortly. -- 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-19532) Allow operators to disable the creation and execution of triggers
Abe Ratnofsky created CASSANDRA-19532: - Summary: Allow operators to disable the creation and execution of triggers Key: CASSANDRA-19532 URL: https://issues.apache.org/jira/browse/CASSANDRA-19532 Project: Cassandra Issue Type: Improvement Components: Local/Other Reporter: Abe Ratnofsky Assignee: Abe Ratnofsky Currently, triggers are discouraged but there's no explicit way to disable them. Similar configuration already exists to disable other features, such as "conf.materialized_views_enabled". There should be a means for operators to gracefully disable the creation and execution of triggers. I have a patch ready for this, getting a first review now and will push it shortly. -- 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-18951) Add option for MutualTlsAuthenticator to restrict the certificate age
[
https://issues.apache.org/jira/browse/CASSANDRA-18951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-18951:
--
Reviewers: Abe Ratnofsky, Andy Tolbert
Status: Review In Progress (was: Patch Available)
> Add option for MutualTlsAuthenticator to restrict the certificate age
> -
>
> Key: CASSANDRA-18951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18951
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Authorization
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> In {{org.apache.cassandra.auth.MutualTlsAuthenticator}}, we validate that a
> certificate is valid by looking at the identities inside the
> certificate and making sure the identity exists in the identity to role table.
> In some situations we may want to restrict the certificates
> we accept by rejecting certificates older than x amount of days. Some
> certificates can be generated with long expiration dates,
> and this might be undesired when you want to protect against potential
> certificates being compromised. For that reason, it is
> important to add an option, that when configured, we can limit the age of the
> certificate we accept for mTLS authentication.
> When enabled, this will force clients to have to renew certificates more
> frequently, reducing the exposure of a Cassandra cluster
> to leaked certificates.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19427) Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries with multiple coordinator-local partitions
[
https://issues.apache.org/jira/browse/CASSANDRA-19427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19427:
--
Reviewers: Caleb Rackliffe, Stefan Miklosovic (was: Stefan Miklosovic)
> Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries
> with multiple coordinator-local partitions
>
>
> Key: CASSANDRA-19427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19427
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Legacy/Local Write-Read Paths
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On one of our clusters, we noticed rare but periodic
> ArrayIndexOutOfBoundsExceptions:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-3,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException"{code}
>
>
> The error was in a Runnable, so the stacktrace didn't directly indicate where
> the error was coming from. We enabled JFR to log the underlying exception
> that was thrown:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-2,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds
> for length 0
> at java.base/java.util.ArrayList.add(ArrayList.java:487)
> at java.base/java.util.ArrayList.add(ArrayList.java:499)
> at org.apache.cassandra.service.ClientWarn$State.add(ClientWarn.java:84)
> at
> org.apache.cassandra.service.ClientWarn$State.access$000(ClientWarn.java:77)
> at org.apache.cassandra.service.ClientWarn.warn(ClientWarn.java:51)
> at
> org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:596)
> at
> org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
> at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:95)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2260)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2575)
> ... 6 more"{code}
>
>
> An AIOBE on ArrayList.add(E) should only be possible when multiple threads
> attempt to call the method at the same time.
>
> This was seen while executing a SELECT WHERE IN query with multiple partition
> keys. This exception could happen when multiple local reads are dispatched by
> the coordinator in
> org.apache.cassandra.service.reads.AbstractReadExecutor#makeRequests. In this
> case, multiple local reads exceed the tombstone warning threshold, so
> multiple tombstone warnings are added to the same ClientWarn.State reference.
> Currently, org.apache.cassandra.service.ClientWarn.State#warnings is an
> ArrayList, which isn't safe for concurrent modification, causing the AIOBE to
> be thrown.
>
> I have a patch available for this, and I'm preparing it now. The patch is
> simple - it just changes
> org.apache.cassandra.service.ClientWarn.State#warnings to a thread-safe
> CopyOnWriteArrayList. I also have a jvm-dtest that demonstrates the iss
[jira] [Commented] (CASSANDRA-19427) Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries with multiple coordinator-local partitions
[
https://issues.apache.org/jira/browse/CASSANDRA-19427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17821428#comment-17821428
]
Abe Ratnofsky commented on CASSANDRA-19427:
---
Had some discussion with [~maedhroz] about CopyOnWriteArrayList vs.
Collections.synchronizedList. There's a reasonable argument that lock
acquisition from synchronizedList is better than copying the entire list on
mutation in CopyOnWriteArrayList, especially since CopyOnWriteArrayList is also
synchronized when mutating the list. But the list should stay small in number
of elements (there aren't many client warnings that exist in the first place,
and unlikely that many will be returned on a single response) and each element
is small (truncated to a fixed maximum length when added).
The main reason I chose CopyOnWriteArrayList is because of synchronizedList's
semantics for iteration:
[https://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#synchronizedList-java.util.List-]
> It is imperative that the user manually synchronize on the returned list when
>iterating over it
I just don't love these semantics - even though we don't iterate over the list
until we serialize the warnings into the response, it just feels too easy to
miss that requirement to synchronize on iteration.
> Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries
> with multiple coordinator-local partitions
>
>
> Key: CASSANDRA-19427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19427
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Legacy/Local Write-Read Paths
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On one of our clusters, we noticed rare but periodic
> ArrayIndexOutOfBoundsExceptions:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-3,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException"{code}
>
>
> The error was in a Runnable, so the stacktrace didn't directly indicate where
> the error was coming from. We enabled JFR to log the underlying exception
> that was thrown:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-2,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds
> for length 0
> at java.base/java.util.ArrayList.add(ArrayList.java:487)
> at java.base/java.util.ArrayList.add(ArrayList.java:499)
> at org.apache.cassandra.service.ClientWarn$State.add(ClientWarn.java:84)
> at
> org.apache.cassandra.service.ClientWarn$State.access$000(ClientWarn.java:77)
> at org.apache.cassandra.service.ClientWarn.warn(ClientWarn.java:51)
> at
> org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:596)
> at
> org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
> at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:95)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2260)
>
[jira] [Commented] (CASSANDRA-19427) Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries with multiple coordinator-local partitions
[
https://issues.apache.org/jira/browse/CASSANDRA-19427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17821316#comment-17821316
]
Abe Ratnofsky commented on CASSANDRA-19427:
---
Added comment, updated patch on all branches:
3.11: [https://github.com/apache/cassandra/pull/3142]
4.0: [https://github.com/apache/cassandra/pull/3143]
4.1: [https://github.com/apache/cassandra/pull/3144]
5.0: [https://github.com/apache/cassandra/pull/3145]
trunk: [https://github.com/apache/cassandra/pull/3129]
All the 3.11-5.0 patches are the same, then trunk is different since the
introduction of CASSANDRA-18330 / TCM.
> Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries
> with multiple coordinator-local partitions
>
>
> Key: CASSANDRA-19427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19427
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Legacy/Local Write-Read Paths
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> On one of our clusters, we noticed rare but periodic
> ArrayIndexOutOfBoundsExceptions:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-3,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException"{code}
>
>
> The error was in a Runnable, so the stacktrace didn't directly indicate where
> the error was coming from. We enabled JFR to log the underlying exception
> that was thrown:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-2,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds
> for length 0
> at java.base/java.util.ArrayList.add(ArrayList.java:487)
> at java.base/java.util.ArrayList.add(ArrayList.java:499)
> at org.apache.cassandra.service.ClientWarn$State.add(ClientWarn.java:84)
> at
> org.apache.cassandra.service.ClientWarn$State.access$000(ClientWarn.java:77)
> at org.apache.cassandra.service.ClientWarn.warn(ClientWarn.java:51)
> at
> org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:596)
> at
> org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
> at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:95)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2260)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2575)
> ... 6 more"{code}
>
>
> An AIOBE on ArrayList.add(E) should only be possible when multiple threads
> attempt to call the method at the same time.
>
> This was seen while executing a SELECT WHERE IN query with multiple partition
> keys. This exception could happen when multiple local reads are dispatched by
> the coordinator in
> org.apache.cassandra.service.reads.AbstractReadExecutor#makeRequests. In this
> case, multiple local reads exceed the tombstone warning threshold, so
> multiple tombstone warnings are added to the same ClientWarn.State reference.
> Curren
[jira] [Commented] (CASSANDRA-19427) Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries with multiple coordinator-local partitions
[
https://issues.apache.org/jira/browse/CASSANDRA-19427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820128#comment-17820128
]
Abe Ratnofsky commented on CASSANDRA-19427:
---
Agree - the fix patch is extremely simple so should be straightforward to
apply. I just pushed the demonstration branch that includes a jvm-dtest showing
the concurrent access as well.
> Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries
> with multiple coordinator-local partitions
>
>
> Key: CASSANDRA-19427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19427
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Legacy/Local Write-Read Paths
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> On one of our clusters, we noticed rare but periodic
> ArrayIndexOutOfBoundsExceptions:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-3,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException"{code}
>
>
> The error was in a Runnable, so the stacktrace didn't directly indicate where
> the error was coming from. We enabled JFR to log the underlying exception
> that was thrown:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-2,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds
> for length 0
> at java.base/java.util.ArrayList.add(ArrayList.java:487)
> at java.base/java.util.ArrayList.add(ArrayList.java:499)
> at org.apache.cassandra.service.ClientWarn$State.add(ClientWarn.java:84)
> at
> org.apache.cassandra.service.ClientWarn$State.access$000(ClientWarn.java:77)
> at org.apache.cassandra.service.ClientWarn.warn(ClientWarn.java:51)
> at
> org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:596)
> at
> org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
> at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:95)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2260)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2575)
> ... 6 more"{code}
>
>
> An AIOBE on ArrayList.add(E) should only be possible when multiple threads
> attempt to call the method at the same time.
>
> This was seen while executing a SELECT WHERE IN query with multiple partition
> keys. This exception could happen when multiple local reads are dispatched by
> the coordinator in
> org.apache.cassandra.service.reads.AbstractReadExecutor#makeRequests. In this
> case, multiple local reads exceed the tombstone warning threshold, so
> multiple tombstone warnings are added to the same ClientWarn.State reference.
> Currently, org.apache.cassandra.service.ClientWarn.State#warnings is an
> ArrayList, which isn't safe for concurrent modification, causing the AIOBE to
> be thrown.
>
> I have a patch available for this, and I'm preparing it now. The patch is
> simpl
[jira] [Updated] (CASSANDRA-19427) Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries with multiple coordinator-local partitions
[
https://issues.apache.org/jira/browse/CASSANDRA-19427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19427:
--
Test and Documentation Plan: Demonstration branch included but no new unit
tests, this fixes a transient issue that is dependent on thread scheduling
Status: Patch Available (was: Open)
> Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries
> with multiple coordinator-local partitions
>
>
> Key: CASSANDRA-19427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19427
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Legacy/Local Write-Read Paths
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> On one of our clusters, we noticed rare but periodic
> ArrayIndexOutOfBoundsExceptions:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-3,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException"{code}
>
>
> The error was in a Runnable, so the stacktrace didn't directly indicate where
> the error was coming from. We enabled JFR to log the underlying exception
> that was thrown:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-2,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds
> for length 0
> at java.base/java.util.ArrayList.add(ArrayList.java:487)
> at java.base/java.util.ArrayList.add(ArrayList.java:499)
> at org.apache.cassandra.service.ClientWarn$State.add(ClientWarn.java:84)
> at
> org.apache.cassandra.service.ClientWarn$State.access$000(ClientWarn.java:77)
> at org.apache.cassandra.service.ClientWarn.warn(ClientWarn.java:51)
> at
> org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:596)
> at
> org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
> at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:95)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2260)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2575)
> ... 6 more"{code}
>
>
> An AIOBE on ArrayList.add(E) should only be possible when multiple threads
> attempt to call the method at the same time.
>
> This was seen while executing a SELECT WHERE IN query with multiple partition
> keys. This exception could happen when multiple local reads are dispatched by
> the coordinator in
> org.apache.cassandra.service.reads.AbstractReadExecutor#makeRequests. In this
> case, multiple local reads exceed the tombstone warning threshold, so
> multiple tombstone warnings are added to the same ClientWarn.State reference.
> Currently, org.apache.cassandra.service.ClientWarn.State#warnings is an
> ArrayList, which isn't safe for concurrent modification, causing the AIOBE to
> be thrown.
>
> I have a patch available for this, and I'm preparing it now. The patch is
> simple - it just changes
> org.a
[jira] [Updated] (CASSANDRA-19427) Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries with multiple coordinator-local partitions
[
https://issues.apache.org/jira/browse/CASSANDRA-19427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19427:
--
Description:
On one of our clusters, we noticed rare but periodic
ArrayIndexOutOfBoundsExceptions:
{code:java}
message="Uncaught exception on thread Thread[ReadStage-3,5,main]"
exception="java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.ArrayIndexOutOfBoundsException"{code}
The error was in a Runnable, so the stacktrace didn't directly indicate where
the error was coming from. We enabled JFR to log the underlying exception that
was thrown:
{code:java}
message="Uncaught exception on thread Thread[ReadStage-2,5,main]"
exception="java.lang.RuntimeException:
java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for
length 0
at java.base/java.util.ArrayList.add(ArrayList.java:487)
at java.base/java.util.ArrayList.add(ArrayList.java:499)
at org.apache.cassandra.service.ClientWarn$State.add(ClientWarn.java:84)
at org.apache.cassandra.service.ClientWarn$State.access$000(ClientWarn.java:77)
at org.apache.cassandra.service.ClientWarn.warn(ClientWarn.java:51)
at
org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:596)
at
org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:95)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2260)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2575)
... 6 more"{code}
An AIOBE on ArrayList.add(E) should only be possible when multiple threads
attempt to call the method at the same time.
This was seen while executing a SELECT WHERE IN query with multiple partition
keys. This exception could happen when multiple local reads are dispatched by
the coordinator in
org.apache.cassandra.service.reads.AbstractReadExecutor#makeRequests. In this
case, multiple local reads exceed the tombstone warning threshold, so multiple
tombstone warnings are added to the same ClientWarn.State reference.
Currently, org.apache.cassandra.service.ClientWarn.State#warnings is an
ArrayList, which isn't safe for concurrent modification, causing the AIOBE to
be thrown.
I have a patch available for this, and I'm preparing it now. The patch is
simple - it just changes org.apache.cassandra.service.ClientWarn.State#warnings
to a thread-safe CopyOnWriteArrayList. I also have a jvm-dtest that
demonstrates the issue but doesn't need to be merged - it shows how a SELECT
WHERE IN query with local reads that add client warnings can add to the same
ClientWarn.State from different threads. I'll push that in a separate branch
just for demonstration purposes.
Demonstration branch:
[https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19427-aiobe-clientwarn-demo]
Fix branch:
[https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19427-aiobe-clientwarn-fix]
(PR linked below)
This appears to have been an issue since at least 3.11, that was the earliest
release I checked.
was:
On one of our clusters, we noticed rare but periodic
ArrayIndexOutOfBoundsExceptions:
{code:java}
message="Uncaught exception on thread Thread[ReadStage-3,5,main]"
exception="java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException
at
org.apache.cassandra.service.StorageProxy$Droppa
[jira] [Updated] (CASSANDRA-19427) Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries with multiple coordinator-local partitions
[
https://issues.apache.org/jira/browse/CASSANDRA-19427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19427:
--
Impacts: (was: None)
> Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries
> with multiple coordinator-local partitions
>
>
> Key: CASSANDRA-19427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19427
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Legacy/Local Write-Read Paths
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> On one of our clusters, we noticed rare but periodic
> ArrayIndexOutOfBoundsExceptions:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-3,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException"{code}
>
>
> The error was in a Runnable, so the stacktrace didn't directly indicate where
> the error was coming from. We enabled JFR to log the underlying exception
> that was thrown:
>
> {code:java}
> message="Uncaught exception on thread Thread[ReadStage-2,5,main]"
> exception="java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds
> for length 0
> at java.base/java.util.ArrayList.add(ArrayList.java:487)
> at java.base/java.util.ArrayList.add(ArrayList.java:499)
> at org.apache.cassandra.service.ClientWarn$State.add(ClientWarn.java:84)
> at
> org.apache.cassandra.service.ClientWarn$State.access$000(ClientWarn.java:77)
> at org.apache.cassandra.service.ClientWarn.warn(ClientWarn.java:51)
> at
> org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:596)
> at
> org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
> at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:95)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2260)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2575)
> ... 6 more"{code}
>
>
> An AIOBE on ArrayList.add(E) should only be possible when multiple threads
> attempt to call the method at the same time.
>
> This was seen while executing a SELECT WHERE IN query with multiple partition
> keys. This exception could happen when multiple local reads are dispatched by
> the coordinator in
> org.apache.cassandra.service.reads.AbstractReadExecutor#makeRequests. In this
> case, multiple local reads exceed the tombstone warning threshold, so
> multiple tombstone warnings are added to the same ClientWarn.State reference.
> Currently, org.apache.cassandra.service.ClientWarn.State#warnings is an
> ArrayList, which isn't safe for concurrent modification, causing the AIOBE to
> be thrown.
>
> I have a patch available for this, and I'm preparing it now. The patch is
> simple - it just changes
> org.apache.cassandra.service.ClientWarn.State#warnings to a thread-safe
> CopyOnWriteArrayList. I also have a jvm-dtest that demonstrates the issue but
> doesn't need to be merged - it shows how a SELECT WHERE IN query with local
> reads that add client warnings can add to the same ClientWarn.State fro
[jira] [Created] (CASSANDRA-19427) Fix concurrent access of ClientWarn causing AIOBE for SELECT WHERE IN queries with multiple coordinator-local partitions
Abe Ratnofsky created CASSANDRA-19427:
-
Summary: Fix concurrent access of ClientWarn causing AIOBE for
SELECT WHERE IN queries with multiple coordinator-local partitions
Key: CASSANDRA-19427
URL: https://issues.apache.org/jira/browse/CASSANDRA-19427
Project: Cassandra
Issue Type: Bug
Components: Consistency/Coordination, Legacy/Local Write-Read Paths
Reporter: Abe Ratnofsky
Assignee: Abe Ratnofsky
On one of our clusters, we noticed rare but periodic
ArrayIndexOutOfBoundsExceptions:
{code:java}
message="Uncaught exception on thread Thread[ReadStage-3,5,main]"
exception="java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.ArrayIndexOutOfBoundsException"{code}
The error was in a Runnable, so the stacktrace didn't directly indicate where
the error was coming from. We enabled JFR to log the underlying exception that
was thrown:
{code:java}
message="Uncaught exception on thread Thread[ReadStage-2,5,main]"
exception="java.lang.RuntimeException:
java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2579)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for
length 0
at java.base/java.util.ArrayList.add(ArrayList.java:487)
at java.base/java.util.ArrayList.add(ArrayList.java:499)
at org.apache.cassandra.service.ClientWarn$State.add(ClientWarn.java:84)
at org.apache.cassandra.service.ClientWarn$State.access$000(ClientWarn.java:77)
at org.apache.cassandra.service.ClientWarn.warn(ClientWarn.java:51)
at
org.apache.cassandra.db.ReadCommand$1MetricRecording.onClose(ReadCommand.java:596)
at
org.apache.cassandra.db.transform.BasePartitions.runOnClose(BasePartitions.java:70)
at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:95)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2260)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2575)
... 6 more"{code}
An AIOBE on ArrayList.add(E) should only be possible when multiple threads
attempt to call the method at the same time.
This was seen while executing a SELECT WHERE IN query with multiple partition
keys. This exception could happen when multiple local reads are dispatched by
the coordinator in
org.apache.cassandra.service.reads.AbstractReadExecutor#makeRequests. In this
case, multiple local reads exceed the tombstone warning threshold, so multiple
tombstone warnings are added to the same ClientWarn.State reference.
Currently, org.apache.cassandra.service.ClientWarn.State#warnings is an
ArrayList, which isn't safe for concurrent modification, causing the AIOBE to
be thrown.
I have a patch available for this, and I'm preparing it now. The patch is
simple - it just changes org.apache.cassandra.service.ClientWarn.State#warnings
to a thread-safe CopyOnWriteArrayList. I also have a jvm-dtest that
demonstrates the issue but doesn't need to be merged - it shows how a SELECT
WHERE IN query with local reads that add client warnings can add to the same
ClientWarn.State from different threads. I'll push that in a separate branch
just for demonstration purposes.
This appears to have been an issue since at least 3.11, that was the earliest
release I checked.
--
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.or
[jira] [Commented] (CASSANDRA-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817158#comment-17817158 ] Abe Ratnofsky commented on CASSANDRA-19392: --- +1, just left some feedback on wording > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19392) deprecate dual ports support (native_transport_port_ssl)
[ https://issues.apache.org/jira/browse/CASSANDRA-19392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19392: -- Reviewers: Abe Ratnofsky Status: Review In Progress (was: Needs Committer) > deprecate dual ports support (native_transport_port_ssl) > - > > Key: CASSANDRA-19392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19392 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > We decided (1) to deprecate dual ports support in 5.0 (and eventually remove > it in trunk). This ticket will track the work towards the deprecation for 5.0. > (1) https://lists.apache.org/thread/dow196gspwgp2og576zh3lotvt6mc3lv -- 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-19385) ALTER ROLE WITH LOGIN=FALSE and REVOKE ROLE do not disconnect existing users
Abe Ratnofsky created CASSANDRA-19385: - Summary: ALTER ROLE WITH LOGIN=FALSE and REVOKE ROLE do not disconnect existing users Key: CASSANDRA-19385 URL: https://issues.apache.org/jira/browse/CASSANDRA-19385 Project: Cassandra Issue Type: Bug Components: Messaging/Client Reporter: Abe Ratnofsky Currently, if users want to block a role from connecting to Cassandra, ALTER ROLE WITH LOGIN=FALSE and REVOKE ROLE seem like the sensible options. But these commands do not disconnect existing connections authenticated with the given role, and these connections will stay alive until they're disconnected for another reason. Subsequent attempts to connect with that role will fail. There is currently no way to disconnect all connections for a given user either. nodetool disablebinary will disconnect all client connections for a given node, and client sessions can be shut down. But in the case of a credential leak or a misconfigured user, it can be desirable to prevent login for a given role and disconnect all existing connections for that role. -- 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-19380) Enhance CqlSession to refresh the auth credentials dynamically
[
https://issues.apache.org/jira/browse/CASSANDRA-19380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815856#comment-17815856
]
Abe Ratnofsky commented on CASSANDRA-19380:
---
"ALTER ROLE WITH LOGIN=FALSE" also will not disconnect existing clients;
they'll continue to work but fail on the next authentication attempt.
> Enhance CqlSession to refresh the auth credentials dynamically
> --
>
> Key: CASSANDRA-19380
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19380
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/java-driver
>Reporter: Ranjith Gampa
>Priority: Normal
>
> Our team is working on a feature to automatically deliver the credentials to
> application when the credentials are rotated without application teams
> restarting the application. Is this currently supported with
> "com.datastax.oss.driver.api.core.CqlSession"? If yes, please provide a
> sample code for the same.
>
> If this feature isn't supported, is it feasible to enhance? Below is our
> request,
> # To dynamically refresh the credentials at runtime within existing
> CqlSession instance.
> # Internally drain the old connections gracefully in resilient manner and
> establish the new connections with new credentials without doubling the
> overall number of connections.
>
> This is how we currently set the auth credentials at application startup.
>
> {code:java}
> cqlSessionBuilder.withConfigLoader(driverConfigLoader)
> .withAuthCredentials(userName, password); {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-19380) Enhance CqlSession to refresh the auth credentials dynamically
[
https://issues.apache.org/jira/browse/CASSANDRA-19380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815844#comment-17815844
]
Abe Ratnofsky commented on CASSANDRA-19380:
---
> In this case will the already-authenticated connections with old active user
> (now passive locked) continue to work?
Depends what you mean by "passive locked" - how are you switching the active
and passive user roles? Are you changing their permissions in Cassandra with
ALTER / GRANT / REVOKE CQL?
> Enhance CqlSession to refresh the auth credentials dynamically
> --
>
> Key: CASSANDRA-19380
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19380
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/java-driver
>Reporter: Ranjith Gampa
>Priority: Normal
>
> Our team is working on a feature to automatically deliver the credentials to
> application when the credentials are rotated without application teams
> restarting the application. Is this currently supported with
> "com.datastax.oss.driver.api.core.CqlSession"? If yes, please provide a
> sample code for the same.
>
> If this feature isn't supported, is it feasible to enhance? Below is our
> request,
> # To dynamically refresh the credentials at runtime within existing
> CqlSession instance.
> # Internally drain the old connections gracefully in resilient manner and
> establish the new connections with new credentials without doubling the
> overall number of connections.
>
> This is how we currently set the auth credentials at application startup.
>
> {code:java}
> cqlSessionBuilder.withConfigLoader(driverConfigLoader)
> .withAuthCredentials(userName, password); {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-19380) Enhance CqlSession to refresh the auth credentials dynamically
[
https://issues.apache.org/jira/browse/CASSANDRA-19380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815840#comment-17815840
]
Abe Ratnofsky commented on CASSANDRA-19380:
---
Can you share more about why you need to interrupt existing connections?
Typically it's sufficient to wait until the next natural reconnection attempt,
since already-authenticated connections are not impacted by credential
rotations where the password for a given user changes.
> Enhance CqlSession to refresh the auth credentials dynamically
> --
>
> Key: CASSANDRA-19380
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19380
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/java-driver
>Reporter: Ranjith Gampa
>Priority: Normal
>
> Our team is working on a feature to automatically deliver the credentials to
> application when the credentials are rotated without application teams
> restarting the application. Is this currently supported with
> "com.datastax.oss.driver.api.core.CqlSession"? If yes, please provide a
> sample code for the same.
>
> If this feature isn't supported, is it feasible to enhance? Below is our
> request,
> # To dynamically refresh the credentials at runtime within existing
> CqlSession instance.
> # Internally drain the old connections gracefully in resilient manner and
> establish the new connections with new credentials without doubling the
> overall number of connections.
>
> This is how we currently set the auth credentials at application startup.
>
> {code:java}
> cqlSessionBuilder.withConfigLoader(driverConfigLoader)
> .withAuthCredentials(userName, password); {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] [Comment Edited] (CASSANDRA-19380) Enhance CqlSession to refresh the auth credentials dynamically
[
https://issues.apache.org/jira/browse/CASSANDRA-19380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815824#comment-17815824
]
Abe Ratnofsky edited comment on CASSANDRA-19380 at 2/8/24 8:25 PM:
---
Hey Ranjith, credentials can already be rotated at runtime:
https://github.com/apache/cassandra-java-driver/blob/4.x/manual/core/authentication/README.md#plain-text
More docs on configuration reloading here:
https://github.com/apache/cassandra-java-driver/blob/4.x/manual/core/configuration/README.md
was (Author: aratnofsky):
Hey Ranjith, credentials can already be rotated at runtime:
https://github.com/apache/cassandra-java-driver/blob/4.x/manual/core/authentication/README.md#plain-text
> Enhance CqlSession to refresh the auth credentials dynamically
> --
>
> Key: CASSANDRA-19380
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19380
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/java-driver
>Reporter: Ranjith Gampa
>Priority: Normal
>
> Our team is working on a feature to automatically deliver the credentials to
> application when the credentials are rotated without application teams
> restarting the application. Is this currently supported with
> "com.datastax.oss.driver.api.core.CqlSession"? If yes, please provide a
> sample code for the same.
>
> If this feature isn't supported, is it feasible to enhance? Below is our
> request,
> # To dynamically refresh the credentials at runtime within existing
> CqlSession instance.
> # Internally drain the old connections gracefully in resilient manner and
> establish the new connections with new credentials without doubling the
> overall number of connections.
>
> This is how we currently set the auth credentials at application startup.
>
> {code:java}
> cqlSessionBuilder.withConfigLoader(driverConfigLoader)
> .withAuthCredentials(userName, password); {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-19380) Enhance CqlSession to refresh the auth credentials dynamically
[
https://issues.apache.org/jira/browse/CASSANDRA-19380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815824#comment-17815824
]
Abe Ratnofsky commented on CASSANDRA-19380:
---
Hey Ranjith, credentials can already be rotated at runtime:
https://github.com/apache/cassandra-java-driver/blob/4.x/manual/core/authentication/README.md#plain-text
> Enhance CqlSession to refresh the auth credentials dynamically
> --
>
> Key: CASSANDRA-19380
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19380
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/java-driver
>Reporter: Ranjith Gampa
>Priority: Normal
>
> Our team is working on a feature to automatically deliver the credentials to
> application when the credentials are rotated without application teams
> restarting the application. Is this currently supported with
> "com.datastax.oss.driver.api.core.CqlSession"? If yes, please provide a
> sample code for the same.
>
> If this feature isn't supported, is it feasible to enhance? Below is our
> request,
> # To dynamically refresh the credentials at runtime within existing
> CqlSession instance.
> # Internally drain the old connections gracefully in resilient manner and
> establish the new connections with new credentials without doubling the
> overall number of connections.
>
> This is how we currently set the auth credentials at application startup.
>
> {code:java}
> cqlSessionBuilder.withConfigLoader(driverConfigLoader)
> .withAuthCredentials(userName, password); {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-19290) Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in cassandra-java-driver
[
https://issues.apache.org/jira/browse/CASSANDRA-19290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19290:
--
Reviewers: Abe Ratnofsky, Bret McGuire, Abe Ratnofsky
Abe Ratnofsky, Bret McGuire, Abe Ratnofsky (was: Abe Ratnofsky,
Bret McGuire)
Status: Review In Progress (was: Patch Available)
> Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in
> cassandra-java-driver
> ---
>
> Key: CASSANDRA-19290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19290
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The java driver uses netty channel attributes to decorate a connection's
> channel with the cluster name (returned from the system.local table) and the
> map from the {{OPTIONS}} response, both of which are obtained on connection
> initialization.
> There's an issue here that I wouldn't expect to see in practice in that the
> {{AttributeKey}}'s used are created using {{AttributeKey.newInstance}}, which
> throws an exception if an {{AttributeKey}} of that name is defined anywhere
> else in evaluated code.
> https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/channel/DriverChannel.java#L52-L54
> {code:java}
> static final AttributeKey CLUSTER_NAME_KEY =
> AttributeKey.newInstance("cluster_name");
> static final AttributeKey>> OPTIONS_KEY =
> AttributeKey.newInstance("options");
> {code}
> This was encountered by a user that was creating driver connections within a
> trigger: https://the-asf.slack.com/archives/CJZLTM05A/p1705537114305579
> {noformat}
> Caused by: java.lang.IllegalArgumentException: 'cluster_name' is
> already in use
> at
> io.netty.util.ConstantPool.createOrThrow(ConstantPool.java:109)
> at io.netty.util.ConstantPool.newInstance(ConstantPool.java:91)
> at io.netty.util.AttributeKey.newInstance(AttributeKey.java:55)
> at
> com.datastax.oss.driver.internal.core.channel.DriverChannel.(DriverChannel.java:50)
> ... 30 common frames omitted
> {noformat}
> There is likely some class loading oddness in the Trigger implementation that
> exacerbates the problem. But at the least, if the driver were to use
> AttributeKey.valueOf instead (like Cassandra does where it uses them:
> https://github.com/search?q=repo%3Aapache%2Fcassandra+AttributeKey.valueOf&type=code),
> this particular issue could be avoided.
> Debatably we could use {{valueOf(firstNameComponent,secondNameComponent)}} as
> a way of namespacing the attribute (e.g.
> {{AttributeKey.newInstance("com.datastax.oss.driver.internal.core.channel",
> "cluster_name");}}, this does not seem necessary though.
--
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-19290) Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in cassandra-java-driver
[
https://issues.apache.org/jira/browse/CASSANDRA-19290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-19290:
--
Status: Needs Committer (was: Review In Progress)
> Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in
> cassandra-java-driver
> ---
>
> Key: CASSANDRA-19290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19290
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The java driver uses netty channel attributes to decorate a connection's
> channel with the cluster name (returned from the system.local table) and the
> map from the {{OPTIONS}} response, both of which are obtained on connection
> initialization.
> There's an issue here that I wouldn't expect to see in practice in that the
> {{AttributeKey}}'s used are created using {{AttributeKey.newInstance}}, which
> throws an exception if an {{AttributeKey}} of that name is defined anywhere
> else in evaluated code.
> https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/channel/DriverChannel.java#L52-L54
> {code:java}
> static final AttributeKey CLUSTER_NAME_KEY =
> AttributeKey.newInstance("cluster_name");
> static final AttributeKey>> OPTIONS_KEY =
> AttributeKey.newInstance("options");
> {code}
> This was encountered by a user that was creating driver connections within a
> trigger: https://the-asf.slack.com/archives/CJZLTM05A/p1705537114305579
> {noformat}
> Caused by: java.lang.IllegalArgumentException: 'cluster_name' is
> already in use
> at
> io.netty.util.ConstantPool.createOrThrow(ConstantPool.java:109)
> at io.netty.util.ConstantPool.newInstance(ConstantPool.java:91)
> at io.netty.util.AttributeKey.newInstance(AttributeKey.java:55)
> at
> com.datastax.oss.driver.internal.core.channel.DriverChannel.(DriverChannel.java:50)
> ... 30 common frames omitted
> {noformat}
> There is likely some class loading oddness in the Trigger implementation that
> exacerbates the problem. But at the least, if the driver were to use
> AttributeKey.valueOf instead (like Cassandra does where it uses them:
> https://github.com/search?q=repo%3Aapache%2Fcassandra+AttributeKey.valueOf&type=code),
> this particular issue could be avoided.
> Debatably we could use {{valueOf(firstNameComponent,secondNameComponent)}} as
> a way of namespacing the attribute (e.g.
> {{AttributeKey.newInstance("com.datastax.oss.driver.internal.core.channel",
> "cluster_name");}}, this does not seem necessary though.
--
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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19180: -- Test and Documentation Plan: Unit tests are included, documentation is updated Status: Patch Available (was: Open) PR: https://github.com/apache/cassandra-java-driver/pull/1743 2 +1s already provided (by [~absurdfarce] and [~andrew.tolbert]) > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 2h 20m > Remaining Estimate: 0h > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19180: -- Status: Needs Committer (was: Review In Progress) > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 2h 20m > Remaining Estimate: 0h > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19180: -- Reviewers: Andy Tolbert, Bret McGuire Status: Review In Progress (was: Patch Available) > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 2h 20m > Remaining Estimate: 0h > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-19292) Update target Cassandra versions for integration tests, support new 4.0.x and 4.1.x
[ https://issues.apache.org/jira/browse/CASSANDRA-19292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19292: -- Change Category: Quality Assurance Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Update target Cassandra versions for integration tests, support new 4.0.x and > 4.1.x > --- > > Key: CASSANDRA-19292 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19292 > Project: Cassandra > Issue Type: Task > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, apache/cassandra-java-driver runs against 4.0.0 but not newer > 4.0.x or 4.1.x releases: > https://github.com/apache/cassandra-java-driver/blob/4.x/core/src/main/java/com/datastax/oss/driver/api/core/Version.java#L54C1-L55C1 > 4.1 introduces changes to config as well, so there are failures to start CCM > clusters if we do a naive version bump, like: > "org.apache.cassandra.exceptions.ConfigurationException: Config contains both > old and new keys for the same configuration parameters, migrate old -> new: > [enable_user_defined_functions -> user_defined_functions_enabled]" > I have a patch ready for this, working on preparing it. -- 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-19292) Update target Cassandra versions for integration tests, support new 4.0.x and 4.1.x
Abe Ratnofsky created CASSANDRA-19292: - Summary: Update target Cassandra versions for integration tests, support new 4.0.x and 4.1.x Key: CASSANDRA-19292 URL: https://issues.apache.org/jira/browse/CASSANDRA-19292 Project: Cassandra Issue Type: Task Components: Client/java-driver Reporter: Abe Ratnofsky Assignee: Abe Ratnofsky Currently, apache/cassandra-java-driver runs against 4.0.0 but not newer 4.0.x or 4.1.x releases: https://github.com/apache/cassandra-java-driver/blob/4.x/core/src/main/java/com/datastax/oss/driver/api/core/Version.java#L54C1-L55C1 4.1 introduces changes to config as well, so there are failures to start CCM clusters if we do a naive version bump, like: "org.apache.cassandra.exceptions.ConfigurationException: Config contains both old and new keys for the same configuration parameters, migrate old -> new: [enable_user_defined_functions -> user_defined_functions_enabled]" I have a patch ready for this, working on preparing it. -- 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-19290) Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in cassandra-java-driver
[
https://issues.apache.org/jira/browse/CASSANDRA-19290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810052#comment-17810052
]
Abe Ratnofsky commented on CASSANDRA-19290:
---
+1
> Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in
> cassandra-java-driver
> ---
>
> Key: CASSANDRA-19290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19290
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The java driver uses netty channel attributes to decorate a connection's
> channel with the cluster name (returned from the system.local table) and the
> map from the {{OPTIONS}} response, both of which are obtained on connection
> initialization.
> There's an issue here that I wouldn't expect to see in practice in that the
> {{AttributeKey}}'s used are created using {{AttributeKey.newInstance}}, which
> throws an exception if an {{AttributeKey}} of that name is defined anywhere
> else in evaluated code.
> https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/channel/DriverChannel.java#L52-L54
> {code:java}
> static final AttributeKey CLUSTER_NAME_KEY =
> AttributeKey.newInstance("cluster_name");
> static final AttributeKey>> OPTIONS_KEY =
> AttributeKey.newInstance("options");
> {code}
> This was encountered by a user that was creating driver connections within a
> trigger: https://the-asf.slack.com/archives/CJZLTM05A/p1705537114305579
> {noformat}
> Caused by: java.lang.IllegalArgumentException: 'cluster_name' is
> already in use
> at
> io.netty.util.ConstantPool.createOrThrow(ConstantPool.java:109)
> at io.netty.util.ConstantPool.newInstance(ConstantPool.java:91)
> at io.netty.util.AttributeKey.newInstance(AttributeKey.java:55)
> at
> com.datastax.oss.driver.internal.core.channel.DriverChannel.(DriverChannel.java:50)
> ... 30 common frames omitted
> {noformat}
> There is likely some class loading oddness in the Trigger implementation that
> exacerbates the problem. But at the least, if the driver were to use
> AttributeKey.valueOf instead (like Cassandra does where it uses them:
> https://github.com/search?q=repo%3Aapache%2Fcassandra+AttributeKey.valueOf&type=code),
> this particular issue could be avoided.
> Debatably we could use {{valueOf(firstNameComponent,secondNameComponent)}} as
> a way of namespacing the attribute (e.g.
> {{AttributeKey.newInstance("com.datastax.oss.driver.internal.core.channel",
> "cluster_name");}}, this does not seem necessary though.
--
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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808360#comment-17808360 ] Abe Ratnofsky edited comment on CASSANDRA-19180 at 1/18/24 8:19 PM: Branch available: https://github.com/aratno/cassandra-java-driver/tree/CASSANDRA-19180-reload-client-keystore cc: [~absurdfarce] was (Author: aratnofsky): PR available: https://github.com/aratno/cassandra-java-driver/tree/CASSANDRA-19180-reload-client-keystore cc: [~absurdfarce] > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808360#comment-17808360 ] Abe Ratnofsky commented on CASSANDRA-19180: --- PR available: https://github.com/aratno/cassandra-java-driver/tree/CASSANDRA-19180-reload-client-keystore cc: [~absurdfarce] > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804372#comment-17804372
]
Abe Ratnofsky commented on CASSANDRA-18857:
---
+1
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19180: -- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19180: -- Impacts: Clients (was: None) > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-19180) Support reloading certificate stores in cassandra-java-driver
Abe Ratnofsky created CASSANDRA-19180: - Summary: Support reloading certificate stores in cassandra-java-driver Key: CASSANDRA-19180 URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 Project: Cassandra Issue Type: New Feature Components: Client/java-driver Reporter: Abe Ratnofsky Assignee: Abe Ratnofsky Currently, apache/cassandra-java-driver does not reload SSLContext when the underlying certificate store files change. When the DefaultSslEngineFactory (and the other factories) are set up, they build a fixed instance of javax.net.ssl.SSLContext that doesn't change: https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 This fixed SSLContext is used to negotiate SSL with the cluster, and if a keystore is reloaded on disk it isn't picked up by the driver, and future reconnections will fail if the keystore certificates have expired by the time they're used to handshake a new connection. We should reload client certificates so that applications that provide them can use short-lived certificates and not require a bounce to pick up new certificates. This is especially relevant in a world with CASSANDRA-18554 and broad use of mTLS. I have a patch for this that is nearly ready. Now that the project has moved under apache/ - who can I work with to understand how CI works now? -- 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-19166) StackOverflowError on ALTER after many previous schema changes
[ https://issues.apache.org/jira/browse/CASSANDRA-19166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17793852#comment-17793852 ] Abe Ratnofsky commented on CASSANDRA-19166: --- Thank you [~jlewandowski]! > StackOverflowError on ALTER after many previous schema changes > -- > > Key: CASSANDRA-19166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19166 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.1.4, 5.0-rc > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Since 4.1, TableMetadataRefCache re-wraps its fields in > Collections.unmodifiableMap on every local schema update. This causes > TableMetadataRefCache's Map fields to reference chains of nested > UnmodifiableMaps. Eventually, this leads to a StackOverflowError on get(), > which has to traverse lots of these maps to fetch the actual value. > https://github.com/apache/cassandra/blob/4059faf5b948c5a285c25fb0f2e4c4288ee7c305/src/java/org/apache/cassandra/schema/TableMetadataRefCache.java#L53 > The issue goes away on restart, since TableMetadataRefCache is reloaded from > disk. > See CASSANDRA-17044, when TableMetadataRefCache was introduced. This issue > was discovered on a real test cluster where schema changes were failing, via > a heap dump. -- 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-19166) StackOverflowError on ALTER after many previous schema changes
[ https://issues.apache.org/jira/browse/CASSANDRA-19166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19166: -- Test and Documentation Plan: Existing tests should pass, no additional tests Status: Patch Available (was: Open) PR up against 4.1: https://github.com/apache/cassandra/pull/2962 > StackOverflowError on ALTER after many previous schema changes > -- > > Key: CASSANDRA-19166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19166 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.1.x, 5.0.x > > Time Spent: 10m > Remaining Estimate: 0h > > Since 4.1, TableMetadataRefCache re-wraps its fields in > Collections.unmodifiableMap on every local schema update. This causes > TableMetadataRefCache's Map fields to reference chains of nested > UnmodifiableMaps. Eventually, this leads to a StackOverflowError on get(), > which has to traverse lots of these maps to fetch the actual value. > https://github.com/apache/cassandra/blob/4059faf5b948c5a285c25fb0f2e4c4288ee7c305/src/java/org/apache/cassandra/schema/TableMetadataRefCache.java#L53 > The issue goes away on restart, since TableMetadataRefCache is reloaded from > disk. > See CASSANDRA-17044, when TableMetadataRefCache was introduced. This issue > was discovered on a real test cluster where schema changes were failing, via > a heap dump. -- 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-19166) StackOverflowError on ALTER after many previous schema changes
[ https://issues.apache.org/jira/browse/CASSANDRA-19166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17793110#comment-17793110 ] Abe Ratnofsky commented on CASSANDRA-19166: --- I have a patch ready - preparing it on a branch now. > StackOverflowError on ALTER after many previous schema changes > -- > > Key: CASSANDRA-19166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19166 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.1.x, 5.0.x > > > Since 4.1, TableMetadataRefCache re-wraps its fields in > Collections.unmodifiableMap on every local schema update. This causes > TableMetadataRefCache's Map fields to reference chains of nested > UnmodifiableMaps. Eventually, this leads to a StackOverflowError on get(), > which has to traverse lots of these maps to fetch the actual value. > https://github.com/apache/cassandra/blob/4059faf5b948c5a285c25fb0f2e4c4288ee7c305/src/java/org/apache/cassandra/schema/TableMetadataRefCache.java#L53 > The issue goes away on restart, since TableMetadataRefCache is reloaded from > disk. > See CASSANDRA-17044, when TableMetadataRefCache was introduced. This issue > was discovered on a real test cluster where schema changes were failing, via > a heap dump. -- 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-19166) StackOverflowError on ALTER after many previous schema changes
[ https://issues.apache.org/jira/browse/CASSANDRA-19166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-19166: -- Bug Category: Parent values: Degradation(12984)Level 1 values: Other Exception(12998) Complexity: Normal Discovered By: User Report Fix Version/s: 5.0.x 4.1.x Severity: Normal Status: Open (was: Triage Needed) > StackOverflowError on ALTER after many previous schema changes > -- > > Key: CASSANDRA-19166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19166 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.1.x, 5.0.x > > > Since 4.1, TableMetadataRefCache re-wraps its fields in > Collections.unmodifiableMap on every local schema update. This causes > TableMetadataRefCache's Map fields to reference chains of nested > UnmodifiableMaps. Eventually, this leads to a StackOverflowError on get(), > which has to traverse lots of these maps to fetch the actual value. > https://github.com/apache/cassandra/blob/4059faf5b948c5a285c25fb0f2e4c4288ee7c305/src/java/org/apache/cassandra/schema/TableMetadataRefCache.java#L53 > The issue goes away on restart, since TableMetadataRefCache is reloaded from > disk. > See CASSANDRA-17044, when TableMetadataRefCache was introduced. This issue > was discovered on a real test cluster where schema changes were failing, via > a heap dump. -- 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-19166) StackOverflowError on ALTER after many previous schema changes
Abe Ratnofsky created CASSANDRA-19166: - Summary: StackOverflowError on ALTER after many previous schema changes Key: CASSANDRA-19166 URL: https://issues.apache.org/jira/browse/CASSANDRA-19166 Project: Cassandra Issue Type: Bug Components: Cluster/Schema Reporter: Abe Ratnofsky Assignee: Abe Ratnofsky Since 4.1, TableMetadataRefCache re-wraps its fields in Collections.unmodifiableMap on every local schema update. This causes TableMetadataRefCache's Map fields to reference chains of nested UnmodifiableMaps. Eventually, this leads to a StackOverflowError on get(), which has to traverse lots of these maps to fetch the actual value. https://github.com/apache/cassandra/blob/4059faf5b948c5a285c25fb0f2e4c4288ee7c305/src/java/org/apache/cassandra/schema/TableMetadataRefCache.java#L53 The issue goes away on restart, since TableMetadataRefCache is reloaded from disk. See CASSANDRA-17044, when TableMetadataRefCache was introduced. This issue was discovered on a real test cluster where schema changes were failing, via a heap dump. -- 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-19113) Publish shaded JVM dtest JAR on release
Abe Ratnofsky created CASSANDRA-19113: - Summary: Publish shaded JVM dtest JAR on release Key: CASSANDRA-19113 URL: https://issues.apache.org/jira/browse/CASSANDRA-19113 Project: Cassandra Issue Type: Improvement Components: Packaging Reporter: Abe Ratnofsky Currently, projects that depend on the shaded JVM dtest JAR need to clone apache/cassandra and build it themselves. Would be great to have these published on each release of Cassandra, so we can treat it as a normal dependency in adjacent projects. -- 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-18903) Incremental repair never cleans up completed sessions from CoordinatorSessions.sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-18903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785073#comment-17785073 ] Abe Ratnofsky commented on CASSANDRA-18903: --- Tests are blocked on a Python environment issue for the python-upgrade-dtests suite - see: https://the-asf.slack.com/archives/CK23JSY2K/p1699649583486419?thread_ts=1699633023.063369&cid=CK23JSY2K > Incremental repair never cleans up completed sessions from > CoordinatorSessions.sessions > --- > > Key: CASSANDRA-18903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18903 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0-beta, 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > > Currently, there is nothing cleaning up repaired sessions from > org.apache.cassandra.repair.consistent.CoordinatorSessions#sessions. This > causes memory to leak for cluster members with long uptimes and lots of > incremental repair. -- 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-18903) Incremental repair never cleans up completed sessions from CoordinatorSessions.sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-18903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784985#comment-17784985 ] Abe Ratnofsky commented on CASSANDRA-18903: --- I'm running the tests for all branches now - for some reason Jira is failing when I try to upload ci_summary + result_details multiple times - so far haven't seen any test failures for touched / related tests, only unrelated tests. Will post more results when they're done processing. > Incremental repair never cleans up completed sessions from > CoordinatorSessions.sessions > --- > > Key: CASSANDRA-18903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18903 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0-beta, 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > > Currently, there is nothing cleaning up repaired sessions from > org.apache.cassandra.repair.consistent.CoordinatorSessions#sessions. This > causes memory to leak for cluster members with long uptimes and lots of > incremental repair. -- 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-18903) Incremental repair never cleans up completed sessions from CoordinatorSessions.sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-18903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784981#comment-17784981 ] Abe Ratnofsky commented on CASSANDRA-18903: --- Results for trunk patch: Results for 4.1 patch: Only test failures are related to CI infrastructure behaving weirdly for dtest / upgrade. [^ci_summary.html] [^result_details.tar.gz] Results for trunk patch: failures in bootstrap_test.py::TestBootstrap::test_cleanup and replica_side_filtering_test.py::TestSecondaryIndexes::test_complementary_update_with_limit_on_static_column_with_not_empty_partitions which both seem like flakes to me. All branches have been rebased and are ready to commit. > Incremental repair never cleans up completed sessions from > CoordinatorSessions.sessions > --- > > Key: CASSANDRA-18903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18903 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0-beta, 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > > Currently, there is nothing cleaning up repaired sessions from > org.apache.cassandra.repair.consistent.CoordinatorSessions#sessions. This > causes memory to leak for cluster members with long uptimes and lots of > incremental repair. -- 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-18903) Incremental repair never cleans up completed sessions from CoordinatorSessions.sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-18903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-18903: -- Status: Ready to Commit (was: Review In Progress) > Incremental repair never cleans up completed sessions from > CoordinatorSessions.sessions > --- > > Key: CASSANDRA-18903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18903 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0-beta, 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > > Currently, there is nothing cleaning up repaired sessions from > org.apache.cassandra.repair.consistent.CoordinatorSessions#sessions. This > causes memory to leak for cluster members with long uptimes and lots of > incremental repair. -- 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-18903) Incremental repair never cleans up completed sessions from CoordinatorSessions.sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-18903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-18903: -- Attachment: ci_summary.html result_details.tar.gz > Incremental repair never cleans up completed sessions from > CoordinatorSessions.sessions > --- > > Key: CASSANDRA-18903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18903 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > > Currently, there is nothing cleaning up repaired sessions from > org.apache.cassandra.repair.consistent.CoordinatorSessions#sessions. This > causes memory to leak for cluster members with long uptimes and lots of > incremental repair. -- 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-18903) Incremental repair never cleans up completed sessions from CoordinatorSessions.sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-18903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776370#comment-17776370 ] Abe Ratnofsky edited comment on CASSANDRA-18903 at 10/19/23 10:44 PM: -- PRs up: ||Release branch||PR|| |trunk|[https://github.com/apache/cassandra/pull/2810|https://github.com/apache/cassandra/pull/2810]| |5.0|[https://github.com/apache/cassandra/pull/2811| https://github.com/apache/cassandra/pull/2811 ]| |4.1|[https://github.com/apache/cassandra/pull/2812|https://github.com/apache/cassandra/pull/2812]| |4.0|[https://github.com/apache/cassandra/pull/2813|https://github.com/apache/cassandra/pull/2813]| was (Author: aratnofsky): PRs up: ||Release branch||PR|| |trunk|https://github.com/apache/cassandra/pull/2810| |5.0|https://github.com/apache/cassandra/pull/2811| |4.1|https://github.com/apache/cassandra/pull/2812| |4.0|https://github.com/apache/cassandra/pull/2813| > Incremental repair never cleans up completed sessions from > CoordinatorSessions.sessions > --- > > Key: CASSANDRA-18903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18903 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, there is nothing cleaning up repaired sessions from > org.apache.cassandra.repair.consistent.CoordinatorSessions#sessions. This > causes memory to leak for cluster members with long uptimes and lots of > incremental repair. -- 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-18903) Incremental repair never cleans up completed sessions from CoordinatorSessions.sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-18903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776370#comment-17776370 ] Abe Ratnofsky commented on CASSANDRA-18903: --- PRs up: ||Release branch||PR|| |trunk|https://github.com/apache/cassandra/pull/2810| |5.0|https://github.com/apache/cassandra/pull/2811| |4.1|https://github.com/apache/cassandra/pull/2812| |4.0|https://github.com/apache/cassandra/pull/2813| > Incremental repair never cleans up completed sessions from > CoordinatorSessions.sessions > --- > > Key: CASSANDRA-18903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18903 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > > Currently, there is nothing cleaning up repaired sessions from > org.apache.cassandra.repair.consistent.CoordinatorSessions#sessions. This > causes memory to leak for cluster members with long uptimes and lots of > incremental repair. -- 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-18904) Repair vtable caches consume excessive memory
[
https://issues.apache.org/jira/browse/CASSANDRA-18904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775017#comment-17775017
]
Abe Ratnofsky commented on CASSANDRA-18904:
---
PRs up:
- trunk: https://github.com/apache/cassandra/pull/2804
- 4.1: https://github.com/apache/cassandra/pull/2805
4.1 slightly differs from trunk due to the exclusion of CASSANDRA-18816, so I'm
opening that up in a separate PR. I'll sync up all the branches based on the PR
feedback.
> Repair vtable caches consume excessive memory
> -
>
> Key: CASSANDRA-18904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18904
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Caching
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> Currently, the repair vtables
> (system_views.{repairs,repair_sessions,repair_jobs,repair_participates,repair_validations})
> are backed by caches in ActiveRepairService that are bounded by the number
> of elements in them, controlled by Config.repair_state_size and
> Config.repair_state_expires.
> The individual cached elements are mutable, and can grow to retain a
> significant amount of heap as the instance uptime increases and more repairs
> are run. In a heap dump for a real cluster, I found these caches occupying
> ~1GB of heap total between ActiveRepairService.repairs and
> ActiveRepairService.participates. Individual cached elements were reaching
> 100KB in size, so configuring the caches by number of elements introduces a
> significant amount of potential variance in the actual heap usage of these
> caches.
> We should measure these caches by the heap they retain, not by the number of
> elements. Users should not be expected to check heap dumps to calibrate the
> number of elements they configure the caches to consume - specifying a memory
> total is much more user-friendly.
--
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-18904) Repair vtable caches consume excessive memory
[
https://issues.apache.org/jira/browse/CASSANDRA-18904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774148#comment-17774148
]
Abe Ratnofsky commented on CASSANDRA-18904:
---
Here's the patch against all relevant branches:
||Release branch||Patch branch link||
|trunk|https://github.com/aratno/cassandra/tree/CASSANDRA-18904-repair-vtable-cache-excessive-memory|
|5.0|https://github.com/aratno/cassandra/tree/CASSANDRA-18904-repair-vtable-cache-excessive-memory-5.0|
|4.1|https://github.com/aratno/cassandra/tree/CASSANDRA-18904-repair-vtable-cache-excessive-memory-4.1|
I'm working with [~jmckenzie] on getting his new CI scripts running, will have
test results soon.
> Repair vtable caches consume excessive memory
> -
>
> Key: CASSANDRA-18904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18904
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Caching
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> Currently, the repair vtables
> (system_views.{repairs,repair_sessions,repair_jobs,repair_participates,repair_validations})
> are backed by caches in ActiveRepairService that are bounded by the number
> of elements in them, controlled by Config.repair_state_size and
> Config.repair_state_expires.
> The individual cached elements are mutable, and can grow to retain a
> significant amount of heap as the instance uptime increases and more repairs
> are run. In a heap dump for a real cluster, I found these caches occupying
> ~1GB of heap total between ActiveRepairService.repairs and
> ActiveRepairService.participates. Individual cached elements were reaching
> 100KB in size, so configuring the caches by number of elements introduces a
> significant amount of potential variance in the actual heap usage of these
> caches.
> We should measure these caches by the heap they retain, not by the number of
> elements. Users should not be expected to check heap dumps to calibrate the
> number of elements they configure the caches to consume - specifying a memory
> total is much more user-friendly.
--
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-18904) Repair vtable caches consume excessive memory
[
https://issues.apache.org/jira/browse/CASSANDRA-18904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772379#comment-17772379
]
Abe Ratnofsky commented on CASSANDRA-18904:
---
Here's a branch against trunk:
https://github.com/aratno/cassandra/tree/CASSANDRA-18904-repair-vtable-cache-excessive-memory
> Repair vtable caches consume excessive memory
> -
>
> Key: CASSANDRA-18904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18904
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Caching
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> Currently, the repair vtables
> (system_views.{repairs,repair_sessions,repair_jobs,repair_participates,repair_validations})
> are backed by caches in ActiveRepairService that are bounded by the number
> of elements in them, controlled by Config.repair_state_size and
> Config.repair_state_expires.
> The individual cached elements are mutable, and can grow to retain a
> significant amount of heap as the instance uptime increases and more repairs
> are run. In a heap dump for a real cluster, I found these caches occupying
> ~1GB of heap total between ActiveRepairService.repairs and
> ActiveRepairService.participates. Individual cached elements were reaching
> 100KB in size, so configuring the caches by number of elements introduces a
> significant amount of potential variance in the actual heap usage of these
> caches.
> We should measure these caches by the heap they retain, not by the number of
> elements. Users should not be expected to check heap dumps to calibrate the
> number of elements they configure the caches to consume - specifying a memory
> total is much more user-friendly.
--
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-18904) Repair vtable caches consume excessive memory
[
https://issues.apache.org/jira/browse/CASSANDRA-18904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-18904:
--
Test and Documentation Plan: Unit tests have been updated
Status: Patch Available (was: Open)
> Repair vtable caches consume excessive memory
> -
>
> Key: CASSANDRA-18904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18904
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Caching
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
>
> Currently, the repair vtables
> (system_views.{repairs,repair_sessions,repair_jobs,repair_participates,repair_validations})
> are backed by caches in ActiveRepairService that are bounded by the number
> of elements in them, controlled by Config.repair_state_size and
> Config.repair_state_expires.
> The individual cached elements are mutable, and can grow to retain a
> significant amount of heap as the instance uptime increases and more repairs
> are run. In a heap dump for a real cluster, I found these caches occupying
> ~1GB of heap total between ActiveRepairService.repairs and
> ActiveRepairService.participates. Individual cached elements were reaching
> 100KB in size, so configuring the caches by number of elements introduces a
> significant amount of potential variance in the actual heap usage of these
> caches.
> We should measure these caches by the heap they retain, not by the number of
> elements. Users should not be expected to check heap dumps to calibrate the
> number of elements they configure the caches to consume - specifying a memory
> total is much more user-friendly.
--
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
