[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[
https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522642#comment-17522642
]
Dinesh Joshi commented on CASSANDRA-17513:
--
For internode communication, currently it is not possible for the server to
identify itself using a client certificate. By adding this option we will be
able to present a client identity to other nodes. The nodes can use this client
certificate to authenticate the node. This makes it possible to implement
mutual TLS which is currently not possible.
{quote}The way I think is - A node has an identity that it uses to-be trusted-
be it a client or server mode with the same peer.
{quote}
You cannot use the same certificate as a client certificate and a server
certificate. They are distinct. You cannot use a client certificate as a server
certificate and vice-versa.
As far as operational overhead is concerned, this is not a required
configuration item. It is optional and won't cause "overhead" unless it is
actually used by the operator.
> Add new property to pass keystore for outbound connections
> --
>
> Key: CASSANDRA-17513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17513
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Same keystore is being set for both Inbound and outbound connections but we
> should use a keystore with server certificate for Inbound connections and a
> keystore with client certificates for outbound connections. So we should add
> a new property in Cassandra.yaml to pass outbound keystore and use it in
> SSLContextFactory for creating outbound SSL context.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522461#comment-17522461 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 3:04 AM: -- Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've not seen such a setup. It makes total sense to me to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. However it sounds odd to say I want to use Identity-A when I am acting as a server to a given peer and use Identity-B when I am acting as a client to the same peer. The way I think is - A node has an identity that it uses to-be trusted- be it a client or server mode with the same peer. We also have to be cognizant of an operational overhead managing so many keypairs. was (Author: maulin.vasavada): Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've not seen such a setup. It makes total sense to me to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. However it sounds odd to say I want to use Identity-A when I am acting as a server to a given peer and use Identity-B when I am acting as a client to the same peer. The way I think is - A node has an identity that it uses to-be trusted- be it a client or server mode with the same peer. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522461#comment-17522461 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 1:35 AM: -- Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've not seen such a setup. It makes total sense to me to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. However it sounds odd to say I want to use Identity-A when I am acting as a server to a given peer and use Identity-B when I am acting as a client to the same peer. The way I think is - A node has an identity that it uses to-be trusted- be it a client or server mode with the same peer. was (Author: maulin.vasavada): Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've never seen such a setup. It makes total sense to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. However it sounds suspicious to say I want to use Identity-A when I am acting as a server to a given peer and use Identity-B when I am acting as a client to the same peer. The way I think is - A node has an identity that it uses to-be trusted- be it a client or server mode with the same peer. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522461#comment-17522461 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 1:33 AM: -- Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've never seen such a setup. It makes total sense to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. However it sounds suspicious to say I want to use Identity-A when I am acting as a server to a given peer and use Identity-B when I am acting as a client to the same peer. The way I think is - A node has an identity that it uses to-be trusted- be it a client or server mode with the same peer. was (Author: maulin.vasavada): Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've never seen such a setup. It makes total sense to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522461#comment-17522461 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 1:30 AM: -- Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've never seen such a setup. It makes total sense to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. was (Author: maulin.vasavada): Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17370) Add flag enabling operators to restrict use of ALLOW FILTERING in queries
[ https://issues.apache.org/jira/browse/CASSANDRA-17370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522533#comment-17522533 ] Savni Nagarkar commented on CASSANDRA-17370: ||patch||ci|| |[allow_filtering\|https://github.com/apache/cassandra/pull/1453]|[j8\|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/27/workflows/e713d5d3-504c-45d1-b0e5-5e85230c5933]| > Add flag enabling operators to restrict use of ALLOW FILTERING in queries > - > > Key: CASSANDRA-17370 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17370 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics, Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > Time Spent: 2.5h > Remaining Estimate: 0h > > This ticket adds the ability for operators to disallow use of ALLOW FILTERING > predicates in CQL SELECT statements. As queries that ALLOW FILTERING can > place additional load on the database, the flag enables operators to provide > tighter bounds on performance guarantees. The patch includes a new yaml > property, as well as a hot property enabling the value to be modified via JMX > at runtime. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17370) Add flag enabling operators to restrict use of ALLOW FILTERING in queries
[ https://issues.apache.org/jira/browse/CASSANDRA-17370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522533#comment-17522533 ] Savni Nagarkar edited comment on CASSANDRA-17370 at 4/14/22 8:56 PM: - ||patch||ci|| |[allow_filtering|https://github.com/apache/cassandra/pull/1453]|[j8|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/27/workflows/e713d5d3-504c-45d1-b0e5-5e85230c5933]| was (Author: JIRAUSER284678): ||patch||ci|| |[allow_filtering\|https://github.com/apache/cassandra/pull/1453]|[j8\|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/27/workflows/e713d5d3-504c-45d1-b0e5-5e85230c5933]| > Add flag enabling operators to restrict use of ALLOW FILTERING in queries > - > > Key: CASSANDRA-17370 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17370 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics, Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > Time Spent: 2.5h > Remaining Estimate: 0h > > This ticket adds the ability for operators to disallow use of ALLOW FILTERING > predicates in CQL SELECT statements. As queries that ALLOW FILTERING can > place additional load on the database, the flag enables operators to provide > tighter bounds on performance guarantees. The patch includes a new yaml > property, as well as a hot property enabling the value to be modified via JMX > at runtime. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated: Add failed stream session message from peer to ignored log patterns
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git The following commit(s) were added to refs/heads/trunk by this push: new 4ef12909 Add failed stream session message from peer to ignored log patterns 4ef12909 is described below commit 4ef129092609821b13eee36c285dbdd89aa05c61 Author: maedhroz AuthorDate: Thu Apr 14 11:17:36 2022 -0500 Add failed stream session message from peer to ignored log patterns patch by Caleb Rackliffe; reviewed by David Capwell for CASSANDRA-17541 --- repair_tests/repair_test.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/repair_tests/repair_test.py b/repair_tests/repair_test.py index c40ce10b..17e124a3 100644 --- a/repair_tests/repair_test.py +++ b/repair_tests/repair_test.py @@ -1266,7 +1266,8 @@ class TestRepair(BaseRepairTest): "Repair session .* for range .* failed with error", "Sync failed between .* and .*", "failed to send a stream message/file to peer", -"failed to send a stream message/data to peer" +"failed to send a stream message/data to peer", +"Remote peer .* failed stream session" ] # stream session will be closed upon EOF, see CASSANDRA-15666 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17370) Add flag enabling operators to restrict use of ALLOW FILTERING in queries
[ https://issues.apache.org/jira/browse/CASSANDRA-17370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522508#comment-17522508 ] Josh McKenzie commented on CASSANDRA-17370: --- Only question I have is: did we decide to exclude system keyspaces from Guardrails universally, just for ALLOW FILTERING, something else entirely? Otherwise looks like Andres and David have covered anything I'd bring up on the review. +1 w/the tweaking to unit testing (I'm neutral on keeping in some of the removing vestigial checked exceptions here vs. doing them _all_ in another ticket. I don't think having a few here really hurts anything) > Add flag enabling operators to restrict use of ALLOW FILTERING in queries > - > > Key: CASSANDRA-17370 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17370 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics, Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > Time Spent: 2.5h > Remaining Estimate: 0h > > This ticket adds the ability for operators to disallow use of ALLOW FILTERING > predicates in CQL SELECT statements. As queries that ALLOW FILTERING can > place additional load on the database, the flag enables operators to provide > tighter bounds on performance guarantees. The patch includes a new yaml > property, as well as a hot property enabling the value to be modified via JMX > at runtime. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522501#comment-17522501 ] Jon Meredith commented on CASSANDRA-17495: -- +1 again, with some very minor feedback. > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[
https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522483#comment-17522483
]
Josh McKenzie commented on CASSANDRA-17495:
---
So this was delightful [~jonmeredith]. The test failures in
{{GuardrailColumnsPerTableTest}} were very suspicious, because they looked an
_awful lot_ like the guardrail for the alterTableEnabled DisableFlag was
inverted. And it was!
I'd missed the negation in the config provider {{getAlterEnabled()}} call, and
the double negative in the API is just subtly confusing enough that I wrote the
entire unit test with the inverted interpretation of the DisableFlag, i.e.
enabled == the disable flag is enabled and thus the feature is disabled vs.
*the feature is enabled*.
All of this being a wonderful justification for the existence of
CASSANDRA-17544.
Anyway, pushed up a commit to add that innocuous !, tidied up the flow and
comments in the unit test, confirmed the two squawking from the runs before
work locally, and fingers crossed.
[Fixing
commit|https://github.com/apache/cassandra/pull/1532/commits/c97253b5a246975c2423b97c3df14189d3ed48cc]
[JDK8
CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/212/workflows/9d736032-392a-42b4-b8b3-df26f82a73fe]
[JDK11
CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/212/workflows/b7438d19-d399-48a2-9853-46516b4e8237]
> Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
> -
>
> Key: CASSANDRA-17495
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17495
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Operators should have the ability to freeze the schema of tables in place so
> users can't mutate columns during various cluster operations. For an example
> of some of the risks see CASSANDRA-13004.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17291) Test Failure: unit test compression: testTokenGenerator_single_rack_or_single_rf
[
https://issues.apache.org/jira/browse/CASSANDRA-17291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie reassigned CASSANDRA-17291:
-
Assignee: Josh McKenzie
> Test Failure: unit test compression:
> testTokenGenerator_single_rack_or_single_rf
>
>
> Key: CASSANDRA-17291
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17291
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> org.apache.cassandra.dht.tokenallocator.OfflineTokenAllocatorTest
> [https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/168/workflows/1d30a113-c14b-4cf4-a631-bedb9eb65762/jobs/1447]
> Looks like a pretty simple / straightforward timeout
> {code}
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout.
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
> at java.util.Vector.forEach(Vector.java:1277)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522461#comment-17522461 ] Maulin Vasavada commented on CASSANDRA-17513: - Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17549) jvm-dtest unhandled exceptions failing the test no longer work
[ https://issues.apache.org/jira/browse/CASSANDRA-17549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith reassigned CASSANDRA-17549: -- Assignee: Benedict Elliott Smith > jvm-dtest unhandled exceptions failing the test no longer work > -- > > Key: CASSANDRA-17549 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17549 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: David Capwell >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > Seems that ([CASSANDRA-16925] CEP-10 Phase 1: Mockable Task Execution) > refactored and avoided using AbstractCluster.uncaughtException, this means > that the logic to detect unexpected exceptions to fail tests no longer works. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17544) Add EnableFlag to guardrails API
[
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17544:
--
Reviewers: Josh McKenzie
> Add EnableFlag to guardrails API
>
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Normal
>
> Currently we only have a DisableFlag which, for guardrails where we're
> enabling or disabling a feature, leads to some pretty odd ergonomics in the
> code. For example:
>
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state ->
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new
> EnableFlag("feature_name", state ->
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the
> guardrails framework and make the logic clearer.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17549) jvm-dtest unhandled exceptions failing the test no longer work
[ https://issues.apache.org/jira/browse/CASSANDRA-17549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-17549: --- Authors: Benedict Elliott Smith Test and Documentation Plan: new test included Status: Patch Available (was: Open) > jvm-dtest unhandled exceptions failing the test no longer work > -- > > Key: CASSANDRA-17549 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17549 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: David Capwell >Priority: Normal > Fix For: 4.1 > > > Seems that ([CASSANDRA-16925] CEP-10 Phase 1: Mockable Task Execution) > refactored and avoided using AbstractCluster.uncaughtException, this means > that the logic to detect unexpected exceptions to fail tests no longer works. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17549) jvm-dtest unhandled exceptions failing the test no longer work
[
https://issues.apache.org/jira/browse/CASSANDRA-17549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522440#comment-17522440
]
Benedict Elliott Smith commented on CASSANDRA-17549:
This was more annoying than I would have liked, and the upgrade test I have
introduced doesn't fully test the behaviour on 4.0 and back. We can strengthen
that by implementing the {{executorFor}} method on earlier versions of
Cassandra if we like.
> jvm-dtest unhandled exceptions failing the test no longer work
> --
>
> Key: CASSANDRA-17549
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17549
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.1
>
>
> Seems that ([CASSANDRA-16925] CEP-10 Phase 1: Mockable Task Execution)
> refactored and avoided using AbstractCluster.uncaughtException, this means
> that the logic to detect unexpected exceptions to fail tests no longer works.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16861) Fix flaky test test_compression_cql_options
[
https://issues.apache.org/jira/browse/CASSANDRA-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16861:
Fix Version/s: 4.0
> Fix flaky test test_compression_cql_options
> ---
>
> Key: CASSANDRA-16861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.x
>
>
> While working on another ticket, I saw test_compression_cql_options failing
> (which is not the case in Jenkins) but the Circle CI multiplexer showed it as
> being flaky:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
> {code:java}
> sstables = self.get_sstables(table='compression_opts_table',
> indexes=list())
> sstable_paths = self.get_table_paths('compression_opts_table')
> found = False
> for sstable_path in sstable_paths:
> sstable = os.path.join(sstable_path,
> sstables['compression_opts_table'][1])
> if os.path.exists(sstable):
> assert 'DEFLATE' == self._get_compression_type(sstable)
> found = True
> > assert found
> E assert False
> compression_test.py:118: AssertionError
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16861) Fix flaky test test_compression_cql_options
[
https://issues.apache.org/jira/browse/CASSANDRA-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522416#comment-17522416
]
Caleb Rackliffe commented on CASSANDRA-16861:
-
Just saw this again here:
https://app.circleci.com/pipelines/github/maedhroz/cassandra/410/workflows/b11dcf8a-2823-4fc3-91d3-dcb3d0379052/jobs/3098/tests#failed-test-0
> Fix flaky test test_compression_cql_options
> ---
>
> Key: CASSANDRA-16861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> While working on another ticket, I saw test_compression_cql_options failing
> (which is not the case in Jenkins) but the Circle CI multiplexer showed it as
> being flaky:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
> {code:java}
> sstables = self.get_sstables(table='compression_opts_table',
> indexes=list())
> sstable_paths = self.get_table_paths('compression_opts_table')
> found = False
> for sstable_path in sstable_paths:
> sstable = os.path.join(sstable_path,
> sstables['compression_opts_table'][1])
> if os.path.exists(sstable):
> assert 'DEFLATE' == self._get_compression_type(sstable)
> found = True
> > assert found
> E assert False
> compression_test.py:118: AssertionError
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522401#comment-17522401 ] Brandon Williams commented on CASSANDRA-17513: -- bq. Currently we are setting same keystore for inbound and outbound connections but we should use a keystore with server certificate to inbound connection and a keystore with client certificate to an outbound connection. What is the motivation for this? > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[
https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522399#comment-17522399
]
Jyothsna Konisa commented on CASSANDRA-17513:
-
[~maulin.vasavada] Thank you very much for your insights, We are trying to
implement mTLS internode authentication and server_encryption_options is used
for configuring SSL/TLS configurations for an internode authentication.
In an internode connection, the node that creates an inbound connection acts
like a server and needs server certificate where as the node that creates
outbound connection is like a client and it needs a client certificate.
Currently we are setting same keystore for inbound and outbound connections but
we should use a keystore with server certificate to inbound connection and a
keystore with client certificate to an outbound connection.
There are two configurations for setting up encryption options in
Cassandra.yaml file
# client_encryption_options (Between Cassandra cluster to clients)
# server_encryption_options (for internode connections between Cassandra nodes)
*client_encryption_options* is used to set encryption configuration for
communication between Cassandra cluster and clients. The server certificate
(the identity of the server) is put inside *client_encryption_options.keystore*
For example if I am a user of a Cassandra cluster and I want to perform a
CQLSH query using Java driver, during SSL handshake server
certificate({*}client_encryption_options.keystore{*}) is presented to the
client as server identity and *client_encryption_options.truststore* should
have roots that trust client certificates.
*server_encryption_options* is used to set encryption configuration for
communication between Cassandra nodes (internode authentication). Even in this
case the server certificate of a node (node's identity) is put inside
*server_encryption_options.keystore* and is presented to the other node. Also
the {*}server{*}{*}_encryption_options.truststore{*} includes trusted roots of
other node's certificates.
So, we cannot use client_encryption_options for configuring TLS/SSL options for
internode authentication. Let me know if this addressed your concern.
> Add new property to pass keystore for outbound connections
> --
>
> Key: CASSANDRA-17513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17513
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Same keystore is being set for both Inbound and outbound connections but we
> should use a keystore with server certificate for Inbound connections and a
> keystore with client certificates for outbound connections. So we should add
> a new property in Cassandra.yaml to pass outbound keystore and use it in
> SSLContextFactory for creating outbound SSL context.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17287) Replace cqlshlib/wcwidth.py with pypi module 'wcwidth'
[
https://issues.apache.org/jira/browse/CASSANDRA-17287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522332#comment-17522332
]
Brandon Williams commented on CASSANDRA-17287:
--
I think we'll need to zip load it like we do for 'six'
> Replace cqlshlib/wcwidth.py with pypi module 'wcwidth'
> --
>
> Key: CASSANDRA-17287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17287
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CQLSH sample query.jpg
>
>
> The module wcwidth implements the same Markus Kuhn algorithm defined in
> POSIX.1-2008 to return the number of cells a unicode string is expected to
> occupy.
> The module wcwidth is used by hundreds of libraries including pytest and
> prompt-toolkit (used in ipython). It replaces 379 lines of bespoke code in
> cqlshlib.
> {quote}from wcwidth import wcswidth # at [https://pypi.org/project/wcwidth/]
> print(wcswidth('コンニチハ'))
> 10
> {{from cqlshlib.wcwidth import wcswidth as cql_wcswidth}}
> print(cql_wcswidth('コンニチハ'))
> 10
> {quote}
> wcwidth appears to be used only by one line in formatting.py:
> return bval if colormap is NO_COLOR_MAP else color_text(bval, colormap,
> wcwidth.wcswidth(bval))
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17287) Replace cqlshlib/wcwidth.py with pypi module 'wcwidth'
[
https://issues.apache.org/jira/browse/CASSANDRA-17287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522322#comment-17522322
]
Brad Schoening commented on CASSANDRA-17287:
[~bereng] [~smiklosovic] does the wcwidth module need to be checked-in to /lib
like the driver for this to work in the build?
> Replace cqlshlib/wcwidth.py with pypi module 'wcwidth'
> --
>
> Key: CASSANDRA-17287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17287
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CQLSH sample query.jpg
>
>
> The module wcwidth implements the same Markus Kuhn algorithm defined in
> POSIX.1-2008 to return the number of cells a unicode string is expected to
> occupy.
> The module wcwidth is used by hundreds of libraries including pytest and
> prompt-toolkit (used in ipython). It replaces 379 lines of bespoke code in
> cqlshlib.
> {quote}from wcwidth import wcswidth # at [https://pypi.org/project/wcwidth/]
> print(wcswidth('コンニチハ'))
> 10
> {{from cqlshlib.wcwidth import wcswidth as cql_wcswidth}}
> print(cql_wcswidth('コンニチハ'))
> 10
> {quote}
> wcwidth appears to be used only by one line in formatting.py:
> return bval if colormap is NO_COLOR_MAP else color_text(bval, colormap,
> wcwidth.wcswidth(bval))
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17180) Implement heartbeat service to know last time Cassandra node was up
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522234#comment-17522234 ] Stefan Miklosovic commented on CASSANDRA-17180: --- Both 17220 and 17493 are in so this might go as well. New build: [https://app.circleci.com/pipelines/github/instaclustr/cassandra/921/workflows/17639dba-534e-4af6-8843-86cfe98bea23] PR: https://github.com/apache/cassandra/pull/1351 > Implement heartbeat service to know last time Cassandra node was up > --- > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17556) jackson-databind 2.13.2 is vulnerable to CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521905#comment-17521905 ] Brandon Williams edited comment on CASSANDRA-17556 at 4/14/22 10:44 AM: ||Branch||CI|| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-17556-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/435/workflows/bc986198-1eea-4ba4-9341-686e3ff68ccc]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17556-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/434/workflows/77804032-ff82-4a01-9c6a-bfbbc4166f0b], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/434/workflows/eb11b25f-5802-47c8-a655-03cfda6feb36]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17556-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/433/workflows/1908788a-7b92-4791-b9ea-946c2fe105cb], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/433/workflows/7e083a05-395d-4294-986f-a7c7985ffb3f]| was (Author: brandon.williams): ||Branch||CI|| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17556-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/434/workflows/77804032-ff82-4a01-9c6a-bfbbc4166f0b], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/434/workflows/eb11b25f-5802-47c8-a655-03cfda6feb36]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17556-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/433/workflows/1908788a-7b92-4791-b9ea-946c2fe105cb], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/433/workflows/7e083a05-395d-4294-986f-a7c7985ffb3f]| > jackson-databind 2.13.2 is vulnerable to CVE-2020-36518 > --- > > Key: CASSANDRA-17556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17556 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.x > > > Seems like it's technically possible to cause a DoS with nested json. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17556) jackson-databind 2.13.2 is vulnerable to CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17556: - Fix Version/s: 3.11.x > jackson-databind 2.13.2 is vulnerable to CVE-2020-36518 > --- > > Key: CASSANDRA-17556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17556 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > > Seems like it's technically possible to cause a DoS with nested json. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17556) jackson-databind 2.13.2 is vulnerable to CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522231#comment-17522231 ] Brandon Williams commented on CASSANDRA-17556: -- Alas, I don't think that ticket has bearing any longer since we forgot about it and upgraded to 2.13 in CASSANDRA-17492 without issue, also for security reasons. > jackson-databind 2.13.2 is vulnerable to CVE-2020-36518 > --- > > Key: CASSANDRA-17556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17556 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.x > > > Seems like it's technically possible to cause a DoS with nested json. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17543) ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8: strategy=NONE coordinator=1 flush=false paging=false] times out sporadically
[
https://issues.apache.org/jira/browse/CASSANDRA-17543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1755#comment-1755
]
Andres de la Peña commented on CASSANDRA-17543:
---
The runs above found [a
problem|https://app.circleci.com/pipelines/github/adelapena/cassandra/1482/workflows/877e7dd4-6e46-4610-aa3b-5a67cc7b2a9d/jobs/15338]
with the renaming of {{ReadRepairQueryTypesTester}} to
{{ReadRepairQueryTypesTest}}, I'm going back to {{ReadRepairQueryTypesTester}}:
||PR||CI||
|[4.0|https://github.com/apache/cassandra/pull/1568]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1484/workflows/3cb3846c-6016-4955-854e-c0731af6f063]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1484/workflows/36f95a15-1af7-43c1-bc5e-460eccf39706]|
|[trunk|https://github.com/apache/cassandra/pull/1569]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1485/workflows/7d05f188-0111-4c09-9293-00ce629834e6]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1485/workflows/7e7837a2-49c5-4bb8-bd0d-aec1810cc891]|
> ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8: strategy=NONE
> coordinator=1 flush=false paging=false] times out sporadically
> ---
>
> Key: CASSANDRA-17543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> org.apache.cassandra.distributed.test.ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8:
> strategy=NONE coordinator=1 flush=false paging=false]
> {noformat}
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> See
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1075/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/testUnrestrictedQueryOnSkinnyTable_8__strategy_NONE_coordinator_1_flush_false_paging_false_/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CASSANDRA-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522173#comment-17522173
]
Benjamin Lerer commented on CASSANDRA-14752:
+1 :)
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L42]
> Every time we return new bytebuffer object. Please do let me know If there
> is a better way. I'd like to contribute. Thanks!!
> {code:java}
> public ByteBuffer serialize(Boolean value)
> {
> return (value == null) ? ByteBufferUtil.EMPTY_BYTE_BUFFER
> : value ? ByteBuffer.wrap(new byte[] {1}) : ByteBuffer.wrap(new byte[] {0});
> // false
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17493) Shutdown all ScheduledExecutors as part of node drainage
[ https://issues.apache.org/jira/browse/CASSANDRA-17493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17493: -- Status: Ready to Commit (was: Review In Progress) > Shutdown all ScheduledExecutors as part of node drainage > > > Key: CASSANDRA-17493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17493 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We are currently shutting down only non-periodic executors in > StorageService#drain. We should shut down all of them. As of now, there does > not seem to be any reason why these executors should be active. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17493) Shutdown all ScheduledExecutors as part of node drainage
[ https://issues.apache.org/jira/browse/CASSANDRA-17493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17493: -- Fix Version/s: 4.1 (was: 4.x) Since Version: NA Source Control Link: https://github.com/apache/cassandra/commit/74bb6d8496d5a2a5b89a843ba764fe37b65ee331 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Shutdown all ScheduledExecutors as part of node drainage > > > Key: CASSANDRA-17493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17493 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We are currently shutting down only non-periodic executors in > StorageService#drain. We should shut down all of them. As of now, there does > not seem to be any reason why these executors should be active. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17493) Shutdown all ScheduledExecutors as part of node drainage
[ https://issues.apache.org/jira/browse/CASSANDRA-17493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17493: -- Reviewers: Jon Meredith, Stefan Miklosovic (was: Paulo Motta) Status: Review In Progress (was: Patch Available) > Shutdown all ScheduledExecutors as part of node drainage > > > Key: CASSANDRA-17493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17493 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We are currently shutting down only non-periodic executors in > StorageService#drain. We should shut down all of them. As of now, there does > not seem to be any reason why these executors should be active. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Shutdown ScheduledExecutors as part of node drainage
This is an automated email from the ASF dual-hosted git repository.
smiklosovic pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 74bb6d8496 Shutdown ScheduledExecutors as part of node drainage
74bb6d8496 is described below
commit 74bb6d8496d5a2a5b89a843ba764fe37b65ee331
Author: Stefan Miklosovic
AuthorDate: Mon Apr 11 16:25:15 2022 +0200
Shutdown ScheduledExecutors as part of node drainage
patch by Stefan Miklosovic; reviewed by Jon Meredith for CASSANDRA-17493
---
CHANGES.txt| 1 +
.../apache/cassandra/service/StorageService.java | 32 ++
.../cassandra/service/StorageServiceTest.java | 38 --
3 files changed, 63 insertions(+), 8 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 196d2471e0..09f097c22e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Shutdown ScheduledExecutors as part of node drainage (CASSANDRA-17493)
* Provide JMX endpoint to allow transient logging of blocking read repairs
(CASSANDRA-17471)
* Add guardrail for GROUP BY queries (CASSANDRA-17509)
* make pylib PEP and pylint compliant (CASSANDRA-17546)
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index d10cdb67ed..d25a7a0f99 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -810,7 +810,18 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
public void runMayThrow() throws InterruptedException,
ExecutionException, IOException
{
drain(true);
-LoggingSupportFactory.getLoggingSupport().onShutdown();
+try
+{
+ExecutorUtils.shutdownNowAndWait(1, MINUTES,
ScheduledExecutors.scheduledFastTasks);
+}
+catch (Throwable t)
+{
+logger.warn("Unable to terminate fast tasks within 1
minute.", t);
+}
+finally
+{
+LoggingSupportFactory.getLoggingSupport().onShutdown();
+}
}
}, "StorageServiceShutdownHook");
Runtime.getRuntime().addShutdownHook(drainOnShutdown);
@@ -5287,12 +5298,21 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
CommitLog.instance.shutdownBlocking();
// wait for miscellaneous tasks like sstable and commitlog segment
deletion
-ScheduledExecutors.nonPeriodicTasks.shutdown();
-if (!ScheduledExecutors.nonPeriodicTasks.awaitTermination(1,
MINUTES))
-logger.warn("Unable to terminate non-periodic tasks within 1
minute.");
-
ColumnFamilyStore.shutdownPostFlushExecutor();
-setMode(Mode.DRAINED, !isFinalShutdown);
+
+try
+{
+// we are not shutting down
ScheduledExecutors#scheduledFastTasks to be still able to progress time
+// fast-tasks executor is shut down in StorageService's
shutdown hook added to Runtime
+ExecutorUtils.shutdownNowAndWait(1, MINUTES,
+
ScheduledExecutors.nonPeriodicTasks,
+
ScheduledExecutors.scheduledTasks,
+
ScheduledExecutors.optionalTasks);
+}
+finally
+{
+setMode(Mode.DRAINED, !isFinalShutdown);
+}
}
catch (Throwable t)
{
diff --git a/test/unit/org/apache/cassandra/service/StorageServiceTest.java
b/test/unit/org/apache/cassandra/service/StorageServiceTest.java
index 84ef9809f7..e42e202a87 100644
--- a/test/unit/org/apache/cassandra/service/StorageServiceTest.java
+++ b/test/unit/org/apache/cassandra/service/StorageServiceTest.java
@@ -18,25 +18,35 @@
package org.apache.cassandra.service;
-import org.apache.cassandra.locator.EndpointsByReplica;
-import org.apache.cassandra.locator.ReplicaCollection;
+import java.util.concurrent.ScheduledFuture;
+import java.util.concurrent.atomic.AtomicInteger;
+
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
+import org.apache.cassandra.concurrent.ScheduledExecutors;
import org.apache.cassandra.config.DatabaseDescriptor;
+import org.apache.cassandra.db.commitlog.CommitLog;
import org.apache.cassandra.dht.RandomPartitioner;
import org.apache.cassandra.dht.Range;
import org.apache.cassandra.dht.Token;
import org.apache.cassandra.locator.AbstractEndpointSnitch;
import org.apache.cassandra.locator.AbstractReplicationStrategy;
+import
[jira] [Commented] (CASSANDRA-17493) Shutdown all ScheduledExecutors as part of node drainage
[ https://issues.apache.org/jira/browse/CASSANDRA-17493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522135#comment-17522135 ] Stefan Miklosovic commented on CASSANDRA-17493: --- https://app.circleci.com/pipelines/github/instaclustr/cassandra/919/workflows/090bb620-b9a8-40f4-a83c-b5d7cfd8e5c4 > Shutdown all ScheduledExecutors as part of node drainage > > > Key: CASSANDRA-17493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17493 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 2h > Remaining Estimate: 0h > > We are currently shutting down only non-periodic executors in > StorageService#drain. We should shut down all of them. As of now, there does > not seem to be any reason why these executors should be active. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
