[jira] [Comment Edited] (CASSANDRA-8612) Read metrics should be updated on all types of reads

[Claude Warren (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598285#comment-17598285
 ] 

Claude Warren edited comment on CASSANDRA-8612 at 9/1/22 5:33 AM:
--

[~cnlwsu] I created a pull request 
[https://github.com/apache/cassandra/pull/1827|https://github.com/apache/cassandra/pull/1827]
 to merge the fix for this into trunk.  Please review.


was (Author: claudenw):
[~cnlwsu] I created a pull request 
[https://github.com/apache/cassandra/pull/1827|https://github.com/apache/cassandra/pull/1827)]
 to merge the fix for this into trunk.  Please review.

> Read metrics should be updated on all types of reads
> 
>
> Key: CASSANDRA-8612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8612
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Dean Z
>Priority: Low
>  Labels: lhf, metrics
> Attachments: 0001-Update-read-metrics-on-all-types-of-reads.patch, 
> 0002-Add-more-read-metrics-into-PartitionRangeReadCommand.patch
>
>
> Metrics like "sstables per read" are not updated on a range slice.  Although 
> separating things out for each type of read could make sense like we do for 
> latencies, only exposing the metrics for one type can be a little confusing 
> when people do a query and see nothing increases.  I think its sufficient to 
> use the same metrics for all reads.



--
This message was sent by Atlassian Jira
(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-16670) Flaky ViewComplexTest, ViewFilteringTest and InsertUpdateIfConditionTest

[Jai Bheemsen Rao Dhanwada (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-16670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598748#comment-17598748
 ] 

Jai Bheemsen Rao Dhanwada commented on CASSANDRA-16670:
---

[~e.dimitrova] Were you able to find why the errors that you mentioned in the 
[comment|https://issues.apache.org/jira/browse/CASSANDRA-16670?focusedCommentId=17355084=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17355084]
 happened? We see a similar errors where the driver version is 4.13.0 and the 
server version is 4.0.5. 

> Flaky ViewComplexTest, ViewFilteringTest and InsertUpdateIfConditionTest
> 
>
> Key: CASSANDRA-16670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16670
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1-alpha1, 4.1
>
>
> *ViewComplexTest*
> Flaky 
> [test|https://ci-cassandra.apache.org/job/Cassandra-4.0/43/testReport/junit/org.apache.cassandra.cql3/ViewComplexTest/testPartialDeleteSelectedColumnWithoutFlush_3_/]
>  and move back away from 'long' section.
> *InsertUpdateIfConditionTest* (CASSANDRA-16676)
> Fails 
> [here|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/testListItem_2__clusterMinVersion_4_0_0_rc2_SNAPSHOT_/]
>  with a timeout. We can see in the history it takes quite a while in 
> [CI|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/history/]
>  _but_ it takes just 1m locally. Probably due to constrained resources. 
> Looking at the 
> [individual|https://ci-cassandra.apache.org/job/Cassandra-4.0/46/testReport/junit/org.apache.cassandra.cql3.validation.operations/InsertUpdateIfConditionTest/]
>  test cases, for compression i.e., we can see 378 at an average of 1s each it 
> can easily go over the timeout of 240s. Recommendation is to either move to 
> 'long' section of to raise the timeout for the class for CI.
> *ViewFilteringTest*
> Move back from 'long' section



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRASC-42) Introduce new handler for Keyspaces/ColumnFamily operations

[Francisco Guerrero (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRASC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francisco Guerrero updated CASSANDRASC-42:
--
Authors: Francisco Guerrero
Test and Documentation Plan: Added integration tests, unit tests, 
serialization tests
 Status: Patch Available  (was: Open)

PR: https://github.com/apache/cassandra-sidecar/pull/36
CI: 
https://app.circleci.com/pipelines/github/frankgh/cassandra-sidecar?branch=CASSANDRASC-42

> Introduce new handler for Keyspaces/ColumnFamily operations
> ---
>
> Key: CASSANDRASC-42
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-42
> Project: Sidecar for Apache Cassandra
>  Issue Type: New Feature
>  Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>  Labels: pull-request-available
>
> Keyspace information is required when doing bulk reads and writes from 
> Cassandra, including ColumnFamily (table) information. For example, column 
> type information can be used to determine a mapping to a different system 
> such as Spark. Checking whether a keyspace/column family exists before 
> starting an import operation is desired.



--
This message was sent by Atlassian Jira
(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-17873) Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11

[Ekaterina Dimitrova (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598624#comment-17598624
 ] 

Ekaterina Dimitrova edited comment on CASSANDRA-17873 at 8/31/22 8:37 PM:
--

[~bdeggleston] , do you mind to confirm my reasoning that we need Opcodes.ASM7 
in 4.0 and 4.1, please? As you were updating it last time for JDK11, I want to 
be sure I didn't miss anything. 


was (Author: e.dimitrova):
[~bdeggleston] , do you mind to confirm my reasoning that we need ASM7 in 4.0 
and 4.1, please? As you were updating it last time for JDK11, I want to be sure 
I didn't miss anything. 

> Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11
> ---
>
> Key: CASSANDRA-17873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17873
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build, Dependencies, Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc, 4.1.x, 4.x
>
>
> In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
> provide Opcodes.ASM7 but only in 1 of 3 places. 
> We need to update that for 4.0, 4.1 and trunk where we support JDK11.
> Also, I think it will be good to add one place where we update that when we 
> add new JDK support as now I see we will have to update it at 4 places at 
> least already (also for the simulator where currently it is Opcodes.ASM7 
> there, correctly added). Also, we can add a note in build.xml for people 
> updating ASM. I think many people practice updating Opcodes.ASM* with the 
> update of ASM version but in our case with update of JDK, from what I see. We 
> will need to switch to ASM9 when we add the JDK 17 support. One stop place 
> for that and adding a note for maintainers sounds like the right way to move 
> forward at least on trunk. 
> But for 4.0 and 4.1 we need at least to switch to ASM7 everywhere as far as I 
> can tell.



--
This message was sent by Atlassian Jira
(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-17873) Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11

[Ekaterina Dimitrova (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ekaterina Dimitrova updated CASSANDRA-17873:

Description: 
In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
provide Opcodes.ASM7 but only in 1 of 3 places. 

We need to update that for 4.0, 4.1 and trunk where we support JDK11.

Also, I think it will be good to add one place where we update that when we add 
new JDK support as now I see we will have to update it at 4 places at least 
already (also for the simulator where currently it is Opcodes.ASM7 there, 
correctly added). Also, we can add a note in build.xml for people updating ASM. 
I think many people practice updating Opcodes.ASM* with the update of ASM 
version but in our case with update of JDK, from what I see. We will need to 
switch to ASM9 when we add the JDK 17 support. One stop place for that and 
adding a note for maintainers sounds like the right way to move forward at 
least on trunk. 

But for 4.0 and 4.1 we need at least to switch to ASM7 everywhere as far as I 
can tell.

  was:
In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
provide Opcodes.ASM7 but only in 1 of 3 places. 

We need to update that for 4.0, 4.1 and trunk where we support JDK11.

Also, I think it will be good to add one place where we update that when we add 
new JDK support as now I see we will have to update it at 4 places at least 
already (also for the simulator where currently it is Opcodes.ASM7 there, 
correctly added). Also, we can add a note in build.xml for people updating ASM. 
I think many people practice updating Opcodes.ASM* with the update of version 
but in our case with update of JDK, from what I see. We will need to switch to 
ASM9 when we add the JDK 17 support. One stop place for that and adding a note 
for maintainers sounds like the right way to move forward at least on trunk. 

But for 4.0 and 4.1 we need at least to switch to ASM7 everywhere as far as I 
can tell.


> Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11
> ---
>
> Key: CASSANDRA-17873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17873
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build, Dependencies, Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc, 4.1.x, 4.x
>
>
> In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
> provide Opcodes.ASM7 but only in 1 of 3 places. 
> We need to update that for 4.0, 4.1 and trunk where we support JDK11.
> Also, I think it will be good to add one place where we update that when we 
> add new JDK support as now I see we will have to update it at 4 places at 
> least already (also for the simulator where currently it is Opcodes.ASM7 
> there, correctly added). Also, we can add a note in build.xml for people 
> updating ASM. I think many people practice updating Opcodes.ASM* with the 
> update of ASM version but in our case with update of JDK, from what I see. We 
> will need to switch to ASM9 when we add the JDK 17 support. One stop place 
> for that and adding a note for maintainers sounds like the right way to move 
> forward at least on trunk. 
> But for 4.0 and 4.1 we need at least to switch to ASM7 everywhere as far as I 
> can tell.



--
This message was sent by Atlassian Jira
(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-17873) Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11

[Ekaterina Dimitrova (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ekaterina Dimitrova updated CASSANDRA-17873:

Fix Version/s: 4.1-rc

> Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11
> ---
>
> Key: CASSANDRA-17873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17873
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build, Dependencies, Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc, 4.1.x, 4.x
>
>
> In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
> provide Opcodes.ASM7 but only in 1 of 3 places. 
> We need to update that for 4.0, 4.1 and trunk where we support JDK11.
> Also, I think it will be good to add one place where we update that when we 
> add new JDK support as now I see we will have to update it at 4 places at 
> least already (also for the simulator where currently it is Opcodes.ASM7 
> there, correctly added). Also, we can add a note in build.xml for people 
> updating ASM. I think many people practice updating Opcodes.ASM* with the 
> update of version but in our case with update of JDK, from what I see. We 
> will need to switch to ASM9 when we add the JDK 17 support. One stop place 
> for that and adding a note for maintainers sounds like the right way to move 
> forward at least on trunk. 
> But for 4.0 and 4.1 we need at least to switch to ASM7 everywhere as far as I 
> can tell.



--
This message was sent by Atlassian Jira
(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-17873) Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11

[Ekaterina Dimitrova (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ekaterina Dimitrova updated CASSANDRA-17873:

Component/s: Feature/UDF

> Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11
> ---
>
> Key: CASSANDRA-17873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17873
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies, Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
> provide Opcodes.ASM7 but only in 1 of 3 places. 
> We need to update that for 4.0, 4.1 and trunk where we support JDK11.
> Also, I think it will be good to add one place where we update that when we 
> add new JDK support as now I see we will have to update it at 4 places at 
> least already (also for the simulator where currently it is Opcodes.ASM7 
> there, correctly added). Also, we can add a note in build.xml for people 
> updating ASM. I think many people practice updating Opcodes.ASM* with the 
> update of version but in our case with update of JDK, from what I see. We 
> will need to switch to ASM9 when we add the JDK 17 support. One stop place 
> for that and adding a note for maintainers sounds like the right way to move 
> forward at least on trunk. 
> But for 4.0 and 4.1 we need at least to switch to ASM7 everywhere as far as I 
> can tell.



--
This message was sent by Atlassian Jira
(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-17873) Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11

[Ekaterina Dimitrova (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ekaterina Dimitrova updated CASSANDRA-17873:

Description: 
In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
provide Opcodes.ASM7 but only in 1 of 3 places. 

We need to update that for 4.0, 4.1 and trunk where we support JDK11.

Also, I think it will be good to add one place where we update that when we add 
new JDK support as now I see we will have to update it at 4 places at least 
already (also for the simulator where currently it is Opcodes.ASM7 there, 
correctly added). Also, we can add a note in build.xml for people updating ASM. 
I think many people practice updating Opcodes.ASM* with the update of version 
but in our case with update of JDK, from what I see. We will need to switch to 
ASM9 when we add the JDK 17 support. One stop place for that and adding a note 
for maintainers sounds like the right way to move forward at least on trunk. 

But for 4.0 and 4.1 we need at least to switch to ASM7 everywhere as far as I 
can tell.

  was:
In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
provide Opcodes.ASM7 but only in 1 of 3 places. 

We need to update that for 4.0, 4.1 and trunk where we support JDK11.

Also, I think it will be good to add one place where we update that when we add 
new JDK support as now I see we will have to update it at 4 places at least 
already (also for the simulator where currently it is Opcodes.ASM7 there, 
correctly added). Also, we can add a note in build.xml for people updating ASM. 
I think many people practice updating Opcodes.ASM* with the update of version 
but in our case with update of JDK, from what I see. We will need to switch to 
ASM9 when we add the JDK 17 support. One stop place for that and adding a note 
for maintainers sounds like the right way to move forward at least on trunk. 

But for 4.0 and 4.1 owe need at least to switch to ASM7 everywhere as far as I 
can tell.


> Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11
> ---
>
> Key: CASSANDRA-17873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17873
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
> provide Opcodes.ASM7 but only in 1 of 3 places. 
> We need to update that for 4.0, 4.1 and trunk where we support JDK11.
> Also, I think it will be good to add one place where we update that when we 
> add new JDK support as now I see we will have to update it at 4 places at 
> least already (also for the simulator where currently it is Opcodes.ASM7 
> there, correctly added). Also, we can add a note in build.xml for people 
> updating ASM. I think many people practice updating Opcodes.ASM* with the 
> update of version but in our case with update of JDK, from what I see. We 
> will need to switch to ASM9 when we add the JDK 17 support. One stop place 
> for that and adding a note for maintainers sounds like the right way to move 
> forward at least on trunk. 
> But for 4.0 and 4.1 we need at least to switch to ASM7 everywhere as far as I 
> can tell.



--
This message was sent by Atlassian Jira
(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-17873) Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11

[Ekaterina Dimitrova (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ekaterina Dimitrova updated CASSANDRA-17873:

Component/s: Build

> Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11
> ---
>
> Key: CASSANDRA-17873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17873
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build, Dependencies, Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
> provide Opcodes.ASM7 but only in 1 of 3 places. 
> We need to update that for 4.0, 4.1 and trunk where we support JDK11.
> Also, I think it will be good to add one place where we update that when we 
> add new JDK support as now I see we will have to update it at 4 places at 
> least already (also for the simulator where currently it is Opcodes.ASM7 
> there, correctly added). Also, we can add a note in build.xml for people 
> updating ASM. I think many people practice updating Opcodes.ASM* with the 
> update of version but in our case with update of JDK, from what I see. We 
> will need to switch to ASM9 when we add the JDK 17 support. One stop place 
> for that and adding a note for maintainers sounds like the right way to move 
> forward at least on trunk. 
> But for 4.0 and 4.1 we need at least to switch to ASM7 everywhere as far as I 
> can tell.



--
This message was sent by Atlassian Jira
(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-17873) Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11

[Ekaterina Dimitrova (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ekaterina Dimitrova updated CASSANDRA-17873:

 Bug Category: Parent values: Correctness(12982)
   Complexity: Normal
  Component/s: Dependencies
Discovered By: User Report
 Severity: Normal
 Assignee: Ekaterina Dimitrova
   Status: Open  (was: Triage Needed)

> Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11
> ---
>
> Key: CASSANDRA-17873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17873
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
> provide Opcodes.ASM7 but only in 1 of 3 places. 
> We need to update that for 4.0, 4.1 and trunk where we support JDK11.
> Also, I think it will be good to add one place where we update that when we 
> add new JDK support as now I see we will have to update it at 4 places at 
> least already (also for the simulator where currently it is Opcodes.ASM7 
> there, correctly added). Also, we can add a note in build.xml for people 
> updating ASM. I think many people practice updating Opcodes.ASM* with the 
> update of version but in our case with update of JDK, from what I see. We 
> will need to switch to ASM9 when we add the JDK 17 support. One stop place 
> for that and adding a note for maintainers sounds like the right way to move 
> forward at least on trunk. 
> But for 4.0 and 4.1 owe need at least to switch to ASM7 everywhere as far as 
> I can tell.



--
This message was sent by Atlassian Jira
(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-17873) Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11

[Ekaterina Dimitrova (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ekaterina Dimitrova updated CASSANDRA-17873:

Fix Version/s: 4.0.x
   4.1.x
   4.x

> Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11
> ---
>
> Key: CASSANDRA-17873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17873
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
> provide Opcodes.ASM7 but only in 1 of 3 places. 
> We need to update that for 4.0, 4.1 and trunk where we support JDK11.
> Also, I think it will be good to add one place where we update that when we 
> add new JDK support as now I see we will have to update it at 4 places at 
> least already (also for the simulator where currently it is Opcodes.ASM7 
> there, correctly added). Also, we can add a note in build.xml for people 
> updating ASM. I think many people practice updating Opcodes.ASM* with the 
> update of version but in our case with update of JDK, from what I see. We 
> will need to switch to ASM9 when we add the JDK 17 support. One stop place 
> for that and adding a note for maintainers sounds like the right way to move 
> forward at least on trunk. 
> But for 4.0 and 4.1 owe need at least to switch to ASM7 everywhere as far as 
> I can tell.



--
This message was sent by Atlassian Jira
(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-17873) Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11

[Ekaterina Dimitrova (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598624#comment-17598624
 ] 

Ekaterina Dimitrova commented on CASSANDRA-17873:
-

[~bdeggleston] , do you mind to confirm my reasoning that we need ASM7 in 4.0 
and 4.1, please? As you were updating it last time for JDK11, I want to be sure 
I didn't miss anything. 

> Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11
> ---
>
> Key: CASSANDRA-17873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17873
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
> provide Opcodes.ASM7 but only in 1 of 3 places. 
> We need to update that for 4.0, 4.1 and trunk where we support JDK11.
> Also, I think it will be good to add one place where we update that when we 
> add new JDK support as now I see we will have to update it at 4 places at 
> least already (also for the simulator where currently it is Opcodes.ASM7 
> there, correctly added). Also, we can add a note in build.xml for people 
> updating ASM. I think many people practice updating Opcodes.ASM* with the 
> update of version but in our case with update of JDK, from what I see. We 
> will need to switch to ASM9 when we add the JDK 17 support. One stop place 
> for that and adding a note for maintainers sounds like the right way to move 
> forward at least on trunk. 
> But for 4.0 and 4.1 owe need at least to switch to ASM7 everywhere as far as 
> I can tell.



--
This message was sent by Atlassian Jira
(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-17873) Opcodes.ASM7 should be used in UDFByteCodeVerifier to support JDK11

[Ekaterina Dimitrova (Jira)]

Ekaterina Dimitrova created CASSANDRA-17873:
---

 Summary: Opcodes.ASM7 should be used in UDFByteCodeVerifier to 
support JDK11
 Key: CASSANDRA-17873
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17873
 Project: Cassandra
  Issue Type: Bug
Reporter: Ekaterina Dimitrova


In CASSANDRA-15108 ASM was updated and UDFByteCodeVerifier was updated to 
provide Opcodes.ASM7 but only in 1 of 3 places. 

We need to update that for 4.0, 4.1 and trunk where we support JDK11.

Also, I think it will be good to add one place where we update that when we add 
new JDK support as now I see we will have to update it at 4 places at least 
already (also for the simulator where currently it is Opcodes.ASM7 there, 
correctly added). Also, we can add a note in build.xml for people updating ASM. 
I think many people practice updating Opcodes.ASM* with the update of version 
but in our case with update of JDK, from what I see. We will need to switch to 
ASM9 when we add the JDK 17 support. One stop place for that and adding a note 
for maintainers sounds like the right way to move forward at least on trunk. 

But for 4.0 and 4.1 owe need at least to switch to ASM7 everywhere as far as I 
can tell.



--
This message was sent by Atlassian Jira
(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-17719) CEP-15: Multi-partition transaction CQL support

[Caleb Rackliffe (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Caleb Rackliffe updated CASSANDRA-17719:

Summary: CEP-15: Multi-partition transaction CQL support  (was: CEP-15: 
(C*) Multi-partition transaction CQL support)

> CEP-15: Multi-partition transaction CQL support
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
>
> The dev list thread regarding CQL transaction support seems to have converged 
> on a syntax.
>  
> The thread is here: 
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>  
> The message proposing the syntax ultimately agreed on is here: 
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>  
> I'll describe my understanding of  the agreed syntax here for, but I'd 
> suggest reading through the thread.
>  
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
>   LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
>   LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
>   SELECT car.is_running, car.miles_driven;
>   IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
>   END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces 
> an order on the different types of clauses. First, assignments, then 
> select(s), then conditional updates. This may be relaxed in the future, but 
> is meant to prevent users from interleaving updates and assignments and 
> expecting read your own write behavior that we don't want to support in v1. 
> h3. Reference assignments
> {code:sql}
>   LET car = (SELECT miles_driven, is_running FROM cars WHERE 
> model=’pinto’){code}
>  
> The first part is basically assigning the result of a SELECT statement to a 
> named reference that can be used in updates/conditions and be returned to the 
> user. Tuple names belong to a global scope and must not clash with other LET 
> statements or update statements (more on that in the updates section). Also, 
> the select statement must either be a point read, with all primary key 
> columns defined, or explicitly set a limit of 1. 
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select 
> statement. Either a normal select statement, or one returning values assigned 
> by LET statements as shown in the example. Ultimately we'll want to support 
> multiple select statements and returning the results to the client. Although 
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
>  * Inserts and updates can reference values assigned earlier in the statement
>  * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
>  - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes. 
> There's no precedence of table vs reference names, so if a relevant column 
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks 
> {code:sql}
>   IF  THEN
>     ;
>     ;
>   END IF
> {code}
>  
> For v1, we only need to support a single condition in the format above. In 
> the future, we'd like to support multiple branches with multiple conditions 
> like:
>  
> {code:sql}
>   IF  THEN
>     ;
>     ;
>   ELSE IF  THEN
>     ;
>   ELSE
>     ;
>   END IF
> {code}
>  
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS 
> NOT NULL also needs to be supported. Multiple comparisons need to be 
> supported, but v1 only needs to support AND'ing them together 
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
>  = 5
>  IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and 
> individually dereferenced columns.)
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax 
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc],  It 
> could be used as a starting point, a source of ideas for approaches, or not 
> used at all. The main thing to keep in mind is that value references prevent 
> creating read commands and mutations until later in the transaction process, 
> and potentially on another machine, which means we can't 

[jira] [Commented] (CASSANDRA-17750) Remove dependency on Maven Ant Tasks

[Ekaterina Dimitrova (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598611#comment-17598611
 ] 

Ekaterina Dimitrova commented on CASSANDRA-17750:
-

[~aratnofsky] , [~dcapwell] , [~mck] - is there a plan to update now this page 
too - [https://cassandra.apache.org/_/development/dependencies.html?] ? In my 
humble opinion this is important to be done as this change affects more or less 
everyone on the project. Also, thank you for all your work here!

> Remove dependency on Maven Ant Tasks
> 
>
> Key: CASSANDRA-17750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17750
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build, Dependencies, Packaging
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 4.2
>
>  Time Spent: 10h 20m
>  Remaining Estimate: 0h
>
> Apache Cassandra depends on Maven Ant Tasks (MAT) during build, for declaring 
> dependencies and generating POM files from within build.xml. MAT has long 
> been retired (no commits since maintenance in 2015), has registered CVEs in 
> dependencies (CVE-2017-1000487), and encourages migration to its successor, 
> Maven Artifact Resolver Ant Tasks (MARAT).
> As part of CASSANDRA-16391 
> , mck migrated 
> dependency resolution to MARAT, but MAT is still included in our build for 
> generating POMs since MARAT does not have an alternative to the writepom task 
> provided by MAT. I have a patch ready that removes MAT completely, with a 
> workaround for POM generation.
> I am not advocating for any kind of migration away from Ant to an alternative 
> like Gradle or Maven, just to be extra clear.



--
This message was sent by Atlassian Jira
(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-10383) Disable auto snapshot on selected tables.

[Stefan Miklosovic (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598579#comment-17598579
 ] 

Stefan Miklosovic edited comment on CASSANDRA-10383 at 8/31/22 7:21 PM:


Hi [~aleksey], I propose this patch to be merged to trunk. Would you have some 
time to review it, please?

PR: https://github.com/apache/cassandra/pull/1831/files
aligned dtests: https://github.com/apache/cassandra-dtest/pull/201

j11 precommit build 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1238/workflows/27fca0c4-8842-4e64-8522-4da228003c1e

j8 precommit build
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1238/workflows/400b1065-5979-45af-b7ce-e35efe89c1c3

I have also run AllowAutoSnapshotTest in Circle 300 times.


was (Author: smiklosovic):
Hi [~aleksey], I propose this patch to be merged to trunk. Would you have some 
time to review it, please?

PR: https://github.com/apache/cassandra/pull/1831/files
aligned dtests: https://github.com/apache/cassandra-dtest/pull/201

j11 precommit build 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1238/workflows/27fca0c4-8842-4e64-8522-4da228003c1e

j8 precommit build
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1238/workflows/400b1065-5979-45af-b7ce-e35efe89c1c3

> Disable auto snapshot on selected tables.
> -
>
> Key: CASSANDRA-10383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10383
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config, Local/Snapshots
>Reporter: Tommy Stendahl
>Assignee: Stefan Miklosovic
>Priority: Normal
>  Labels: doc-impacting, messaging-service-bump-required
> Fix For: 4.x
>
> Attachments: 10383.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I have a use case where I would like to turn off auto snapshot for selected 
> tables, I don't want to turn it off completely since its a good feature. 
> Looking at the code I think it would be relatively easy to fix.
> My plan is to create a new table property named something like 
> "disable_auto_snapshot". If set to true it will prevent auto snapshot on the 
> table, if set to false auto snapshot will be controlled by the 
> "auto_snapshot" property in the cassandra.yaml. Default would be false.



--
This message was sent by Atlassian Jira
(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-10383) Disable auto snapshot on selected tables.

[Stefan Miklosovic (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-10383:
--
Test and Documentation Plan: junits and dtests
 Status: Patch Available  (was: In Progress)

Hi [~aleksey], I propose this patch to be merged to trunk. Would you have some 
time to review it, please?

PR: https://github.com/apache/cassandra/pull/1831/files
aligned dtests: https://github.com/apache/cassandra-dtest/pull/201

j11 precommit build 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1238/workflows/27fca0c4-8842-4e64-8522-4da228003c1e

j8 precommit build
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1238/workflows/400b1065-5979-45af-b7ce-e35efe89c1c3

> Disable auto snapshot on selected tables.
> -
>
> Key: CASSANDRA-10383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10383
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config, Local/Snapshots
>Reporter: Tommy Stendahl
>Assignee: Stefan Miklosovic
>Priority: Normal
>  Labels: doc-impacting, messaging-service-bump-required
> Fix For: 4.x
>
> Attachments: 10383.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I have a use case where I would like to turn off auto snapshot for selected 
> tables, I don't want to turn it off completely since its a good feature. 
> Looking at the code I think it would be relatively easy to fix.
> My plan is to create a new table property named something like 
> "disable_auto_snapshot". If set to true it will prevent auto snapshot on the 
> table, if set to false auto snapshot will be controlled by the 
> "auto_snapshot" property in the cassandra.yaml. Default would be false.



--
This message was sent by Atlassian Jira
(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-17871) Update debian packages for bullseye

[Brandon Williams (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-17871:
-
Test and Documentation Plan: build packages
 Status: Patch Available  (was: In Progress)

> Update debian packages for bullseye
> ---
>
> Key: CASSANDRA-17871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17871
> Project: Cassandra
>  Issue Type: Task
>  Components: Packaging
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> We are updating the buster docker image used to build debian packages to 
> bullseye (which is probably a bit overdue) in CASSANDRA-17854 Package build 
> dependencies for versions using python2 need to be updated for this to work.



--
This message was sent by Atlassian Jira
(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-17871) Update debian packages for bullseye

[Brandon Williams (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598571#comment-17598571
 ] 

Brandon Williams commented on CASSANDRA-17871:
--

After a lot of experimentation, most of this can be boiled down to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972726 which doesn't allow 
python-is-python2 along with dh-python, so when it goes to build the package 
and installs the build-deps, suddenly 'python' no longer exists.  I fixed this 
[in the 
image|https://github.com/driftx/cassandra-builds/commit/a4ac03093a4fd9b3285986db863f2ff95f358d46]
 but 2.2 still needs to declare python2-dev, which I've done 
[here|https://github.com/driftx/cassandra/commit/9c5527103c4431173d5a203751a8cf031671b96e]
 which matches 3.0/3.11 and was probably forgotten for 2.2 or added later.

> Update debian packages for bullseye
> ---
>
> Key: CASSANDRA-17871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17871
> Project: Cassandra
>  Issue Type: Task
>  Components: Packaging
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> We are updating the buster docker image used to build debian packages to 
> bullseye (which is probably a bit overdue) in CASSANDRA-17854 Package build 
> dependencies for versions using python2 need to be updated for this to work.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra-website] branch asf-staging updated (3c0b12b74 -> 8c3078df8)

[git-site-role]

This is an automated email from the ASF dual-hosted git repository.

git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git


 discard 3c0b12b74 generate docs for 538513bd
 new 8c3078df8 generate docs for 538513bd

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (3c0b12b74)
\
 N -- N -- N   refs/heads/asf-staging (8c3078df8)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 content/search-index.js |   2 +-
 site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra-website] branch asf-staging updated (7cb4bcf2e -> 3c0b12b74)

[git-site-role]

This is an automated email from the ASF dual-hosted git repository.

git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git


 discard 7cb4bcf2e generate docs for 538513bd
 new 3c0b12b74 generate docs for 538513bd

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (7cb4bcf2e)
\
 N -- N -- N   refs/heads/asf-staging (3c0b12b74)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 content/search-index.js |   2 +-
 site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-17870) nodetool/rebuild: Add flag to exclude nodes from local datacenter

[Saranya Krishnakumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Saranya Krishnakumar updated CASSANDRA-17870:
-
Attachment: fix_nodetool_rebuild.diff

> nodetool/rebuild: Add flag to exclude nodes from local datacenter
> -
>
> Key: CASSANDRA-17870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17870
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Saranya Krishnakumar
>Assignee: Saranya Krishnakumar
>Priority: Normal
> Attachments: fix_nodetool_rebuild.diff
>
>
> During expansion by Dc, when we issue nodetool/rebuild from new dc to rebuild 
> the data from other DCs. If src-dc is not passed explicitly, then C* tries to 
> rebuild the data from the same (new dc) dc. 
> We don’t exclude other nodes in the same DC. Only down sources and the local 
> node itself are excluded.
> ```
>  // We're _always_ filtering out a local node and down sources
>         addSourceFilter(new 
> RangeStreamer.FailureDetectorSourceFilter(failureDetector));
>         addSourceFilter(new RangeStreamer.ExcludeLocalNodeFilter());
> ```
> We should fix nodetool/rebuild to exclude the local DC (from where we’re 
> executing the command) while issuing nodetool/rebuild without passing src dc



--
This message was sent by Atlassian Jira
(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-17870) nodetool/rebuild: Add flag to exclude nodes from local datacenter

[Saranya Krishnakumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Saranya Krishnakumar updated CASSANDRA-17870:
-
Test and Documentation Plan: Unit test
 Status: Patch Available  (was: Open)

> nodetool/rebuild: Add flag to exclude nodes from local datacenter
> -
>
> Key: CASSANDRA-17870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17870
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Saranya Krishnakumar
>Assignee: Saranya Krishnakumar
>Priority: Normal
> Attachments: fix_nodetool_rebuild.diff
>
>
> During expansion by Dc, when we issue nodetool/rebuild from new dc to rebuild 
> the data from other DCs. If src-dc is not passed explicitly, then C* tries to 
> rebuild the data from the same (new dc) dc. 
> We don’t exclude other nodes in the same DC. Only down sources and the local 
> node itself are excluded.
> ```
>  // We're _always_ filtering out a local node and down sources
>         addSourceFilter(new 
> RangeStreamer.FailureDetectorSourceFilter(failureDetector));
>         addSourceFilter(new RangeStreamer.ExcludeLocalNodeFilter());
> ```
> We should fix nodetool/rebuild to exclude the local DC (from where we’re 
> executing the command) while issuing nodetool/rebuild without passing src dc



--
This message was sent by Atlassian Jira
(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-17872) Dtests failing intermittently on Jolokia agent

[Jira]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andres de la Peña updated CASSANDRA-17872:
--
Description: 
Some apparently unrealeted Python dtests fail with an output of the form:
{code:java}
Error Message
subprocess.CalledProcessError: Command 
'('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
 'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 'start', 
'706')' returned non-zero exit status 1.
Stacktrace
self = 

def test_role_caching_authenticated_user(self):
"""
This test is to show that the role caching in AuthenticatedUser
works correctly and revokes the roles from a logged in user
* Launch a one node cluster, with a roles cache of 2s
* Connect as the default superuser
* Create ROLES role1 and mike
* Grant permissions to role1, and role1 to mike
* Verify mike can perform expected operations
* Revoke role1, and thus read permissions, from mike.
* Try reading as mike, and verify that eventually the cache expires 
and it fails.
"""
# on older versions the cache is not initialized until used,
# we need the MBean registered so let's use it
if self.dtest_config.cassandra_version_from_build < '4.0':
self.superuser.execute("LIST ROLES")

mbean = make_mbean('auth', type='RolesCache')
>   with JolokiaAgent(self.cluster.nodelist()[0]) as jmx:

auth_test.py:1888: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
tools/jmxutils.py:309: in __enter__
self.start()
tools/jmxutils.py:187: in start
subprocess.check_output(args, stderr=subprocess.STDOUT)
/usr/lib/python3.8/subprocess.py:415: in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

input = None, capture_output = False, timeout = None, check = True
popenargs = (('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandr...t/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
 'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', ...),)
kwargs = {'stderr': -2, 'stdout': -1}
process = 
stdout = b"Couldn't start agent for PID 706\nPossible reason could be that port 
'8778' is already occupied.\nPlease check the standard output of the target 
process for a detailed error message.\n"
stderr = None, retcode = 1

def run(*popenargs,
input=None, capture_output=False, timeout=None, check=False, 
**kwargs):
"""Run command with arguments and return a CompletedProcess instance.

The returned instance will have attributes args, returncode, stdout and
stderr. By default, stdout and stderr are not captured, and those 
attributes
will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture 
them.

If check is True and the exit code was non-zero, it raises a
CalledProcessError. The CalledProcessError object will have the return 
code
in the returncode attribute, and output & stderr attributes if those 
streams
were captured.

If timeout is given, and the process takes too long, a TimeoutExpired
exception will be raised.

There is an optional argument "input", allowing you to
pass bytes or a string to the subprocess's stdin.  If you use this 
argument
you may not also use the Popen constructor's "stdin" argument, as
it will be used internally.

By default, all communication is in bytes, and therefore any "input" 
should
be bytes, and the stdout and stderr will be bytes. If in text mode, any
"input" should be a string, and stdout and stderr will be strings 
decoded
according to locale encoding, or by "encoding" if set. Text mode is
triggered by setting any of text, encoding, errors or 
universal_newlines.

The other arguments are the same as for the Popen constructor.
"""
if input is not None:
if kwargs.get('stdin') is not None:
raise ValueError('stdin and input arguments may not both be 
used.')
kwargs['stdin'] = PIPE

if capture_output:
if kwargs.get('stdout') is not None or kwargs.get('stderr') is not 
None:
raise ValueError('stdout and stderr arguments may not be used '
 'with capture_output.')
kwargs['stdout'] = PIPE
kwargs['stderr'] = PIPE

with Popen(*popenargs, **kwargs) as process:
try:
stdout, 

[jira] [Updated] (CASSANDRA-17872) Dtests failing intermittently on Jolokia agent

[Jira]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andres de la Peña updated CASSANDRA-17872:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test 
Failure(12990)

> Dtests failing intermittently on Jolokia agent
> --
>
> Key: CASSANDRA-17872
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17872
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Andres de la Peña
>Priority: Normal
>
> Some apparently unrealeted Python dtests fails with an output of the form:
> {code:java}
> Error Message
> subprocess.CalledProcessError: Command 
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 'start', 
> '706')' returned non-zero exit status 1.
> Stacktrace
> self = 
> def test_role_caching_authenticated_user(self):
> """
> This test is to show that the role caching in AuthenticatedUser
> works correctly and revokes the roles from a logged in user
> * Launch a one node cluster, with a roles cache of 2s
> * Connect as the default superuser
> * Create ROLES role1 and mike
> * Grant permissions to role1, and role1 to mike
> * Verify mike can perform expected operations
> * Revoke role1, and thus read permissions, from mike.
> * Try reading as mike, and verify that eventually the cache 
> expires and it fails.
> """
> # on older versions the cache is not initialized until used,
> # we need the MBean registered so let's use it
> if self.dtest_config.cassandra_version_from_build < '4.0':
> self.superuser.execute("LIST ROLES")
> 
> mbean = make_mbean('auth', type='RolesCache')
> >   with JolokiaAgent(self.cluster.nodelist()[0]) as jmx:
> auth_test.py:1888: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> tools/jmxutils.py:309: in __enter__
> self.start()
> tools/jmxutils.py:187: in start
> subprocess.check_output(args, stderr=subprocess.STDOUT)
> /usr/lib/python3.8/subprocess.py:415: in check_output
> return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> input = None, capture_output = False, timeout = None, check = True
> popenargs = (('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandr...t/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', ...),)
> kwargs = {'stderr': -2, 'stdout': -1}
> process = 
> stdout = b"Couldn't start agent for PID 706\nPossible reason could be that 
> port '8778' is already occupied.\nPlease check the standard output of the 
> target process for a detailed error message.\n"
> stderr = None, retcode = 1
> def run(*popenargs,
> input=None, capture_output=False, timeout=None, check=False, 
> **kwargs):
> """Run command with arguments and return a CompletedProcess instance.
> 
> The returned instance will have attributes args, returncode, stdout 
> and
> stderr. By default, stdout and stderr are not captured, and those 
> attributes
> will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture 
> them.
> 
> If check is True and the exit code was non-zero, it raises a
> CalledProcessError. The CalledProcessError object will have the 
> return code
> in the returncode attribute, and output & stderr attributes if those 
> streams
> were captured.
> 
> If timeout is given, and the process takes too long, a TimeoutExpired
> exception will be raised.
> 
> There is an optional argument "input", allowing you to
> pass bytes or a string to the subprocess's stdin.  If you use this 
> argument
> you may not also use the Popen constructor's "stdin" argument, as
> it will be used internally.
> 
> By default, all communication is in bytes, and therefore any "input" 
> should
> be bytes, and the stdout and stderr will be bytes. If in text mode, 
> any
> "input" should be a string, and stdout and stderr will be strings 
> decoded
> according to locale encoding, or by "encoding" if set. Text mode is
> triggered by setting any of text, encoding, errors or 
> universal_newlines.
> 
> The other arguments are the same as for the Popen 

[jira] [Updated] (CASSANDRA-17872) Dtests failing intermittently on Jolokia agent

[Jira]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andres de la Peña updated CASSANDRA-17872:
--
Description: 
Some apparently unrealeted Python dtests fails with an output of the form:
{code:java}
Error Message
subprocess.CalledProcessError: Command 
'('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
 'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 'start', 
'706')' returned non-zero exit status 1.
Stacktrace
self = 

def test_role_caching_authenticated_user(self):
"""
This test is to show that the role caching in AuthenticatedUser
works correctly and revokes the roles from a logged in user
* Launch a one node cluster, with a roles cache of 2s
* Connect as the default superuser
* Create ROLES role1 and mike
* Grant permissions to role1, and role1 to mike
* Verify mike can perform expected operations
* Revoke role1, and thus read permissions, from mike.
* Try reading as mike, and verify that eventually the cache expires 
and it fails.
"""
# on older versions the cache is not initialized until used,
# we need the MBean registered so let's use it
if self.dtest_config.cassandra_version_from_build < '4.0':
self.superuser.execute("LIST ROLES")

mbean = make_mbean('auth', type='RolesCache')
>   with JolokiaAgent(self.cluster.nodelist()[0]) as jmx:

auth_test.py:1888: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
tools/jmxutils.py:309: in __enter__
self.start()
tools/jmxutils.py:187: in start
subprocess.check_output(args, stderr=subprocess.STDOUT)
/usr/lib/python3.8/subprocess.py:415: in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

input = None, capture_output = False, timeout = None, check = True
popenargs = (('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandr...t/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
 'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', ...),)
kwargs = {'stderr': -2, 'stdout': -1}
process = 
stdout = b"Couldn't start agent for PID 706\nPossible reason could be that port 
'8778' is already occupied.\nPlease check the standard output of the target 
process for a detailed error message.\n"
stderr = None, retcode = 1

def run(*popenargs,
input=None, capture_output=False, timeout=None, check=False, 
**kwargs):
"""Run command with arguments and return a CompletedProcess instance.

The returned instance will have attributes args, returncode, stdout and
stderr. By default, stdout and stderr are not captured, and those 
attributes
will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture 
them.

If check is True and the exit code was non-zero, it raises a
CalledProcessError. The CalledProcessError object will have the return 
code
in the returncode attribute, and output & stderr attributes if those 
streams
were captured.

If timeout is given, and the process takes too long, a TimeoutExpired
exception will be raised.

There is an optional argument "input", allowing you to
pass bytes or a string to the subprocess's stdin.  If you use this 
argument
you may not also use the Popen constructor's "stdin" argument, as
it will be used internally.

By default, all communication is in bytes, and therefore any "input" 
should
be bytes, and the stdout and stderr will be bytes. If in text mode, any
"input" should be a string, and stdout and stderr will be strings 
decoded
according to locale encoding, or by "encoding" if set. Text mode is
triggered by setting any of text, encoding, errors or 
universal_newlines.

The other arguments are the same as for the Popen constructor.
"""
if input is not None:
if kwargs.get('stdin') is not None:
raise ValueError('stdin and input arguments may not both be 
used.')
kwargs['stdin'] = PIPE

if capture_output:
if kwargs.get('stdout') is not None or kwargs.get('stderr') is not 
None:
raise ValueError('stdout and stderr arguments may not be used '
 'with capture_output.')
kwargs['stdout'] = PIPE
kwargs['stderr'] = PIPE

with Popen(*popenargs, **kwargs) as process:
try:
stdout, 

[jira] [Created] (CASSANDRA-17872) Dtests failing intermittently on Jolokia agent

[Jira]

Andres de la Peña created CASSANDRA-17872:
-

 Summary: Dtests failing intermittently on Jolokia agent
 Key: CASSANDRA-17872
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17872
 Project: Cassandra
  Issue Type: Bug
  Components: Test/dtest/python
Reporter: Andres de la Peña


Some apparently unrealeted Python dtests fails with an output of the form:
{code:java}
Error Message
subprocess.CalledProcessError: Command 
'('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
 'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 'start', 
'706')' returned non-zero exit status 1.
Stacktrace
self = 

def test_role_caching_authenticated_user(self):
"""
This test is to show that the role caching in AuthenticatedUser
works correctly and revokes the roles from a logged in user
* Launch a one node cluster, with a roles cache of 2s
* Connect as the default superuser
* Create ROLES role1 and mike
* Grant permissions to role1, and role1 to mike
* Verify mike can perform expected operations
* Revoke role1, and thus read permissions, from mike.
* Try reading as mike, and verify that eventually the cache expires 
and it fails.
"""
# on older versions the cache is not initialized until used,
# we need the MBean registered so let's use it
if self.dtest_config.cassandra_version_from_build < '4.0':
self.superuser.execute("LIST ROLES")

mbean = make_mbean('auth', type='RolesCache')
>   with JolokiaAgent(self.cluster.nodelist()[0]) as jmx:

auth_test.py:1888: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
tools/jmxutils.py:309: in __enter__
self.start()
tools/jmxutils.py:187: in start
subprocess.check_output(args, stderr=subprocess.STDOUT)
/usr/lib/python3.8/subprocess.py:415: in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

input = None, capture_output = False, timeout = None, check = True
popenargs = (('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandr...t/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
 'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', ...),)
kwargs = {'stderr': -2, 'stdout': -1}
process = 
stdout = b"Couldn't start agent for PID 706\nPossible reason could be that port 
'8778' is already occupied.\nPlease check the standard output of the target 
process for a detailed error message.\n"
stderr = None, retcode = 1

def run(*popenargs,
input=None, capture_output=False, timeout=None, check=False, 
**kwargs):
"""Run command with arguments and return a CompletedProcess instance.

The returned instance will have attributes args, returncode, stdout and
stderr. By default, stdout and stderr are not captured, and those 
attributes
will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture 
them.

If check is True and the exit code was non-zero, it raises a
CalledProcessError. The CalledProcessError object will have the return 
code
in the returncode attribute, and output & stderr attributes if those 
streams
were captured.

If timeout is given, and the process takes too long, a TimeoutExpired
exception will be raised.

There is an optional argument "input", allowing you to
pass bytes or a string to the subprocess's stdin.  If you use this 
argument
you may not also use the Popen constructor's "stdin" argument, as
it will be used internally.

By default, all communication is in bytes, and therefore any "input" 
should
be bytes, and the stdout and stderr will be bytes. If in text mode, any
"input" should be a string, and stdout and stderr will be strings 
decoded
according to locale encoding, or by "encoding" if set. Text mode is
triggered by setting any of text, encoding, errors or 
universal_newlines.

The other arguments are the same as for the Popen constructor.
"""
if input is not None:
if kwargs.get('stdin') is not None:
raise ValueError('stdin and input arguments may not both be 
used.')
kwargs['stdin'] = PIPE

if capture_output:
if kwargs.get('stdout') is not None or kwargs.get('stderr') is not 
None:
raise ValueError('stdout and stderr arguments may not be used '
 'with 

[jira] [Updated] (CASSANDRA-17618) Fix flaky org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest

[Aleksey Yeschenko (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-17618:
--
Reviewers: Aleksey Yeschenko, Aleksey Yeschenko
   Aleksey Yeschenko, Aleksey Yeschenko  (was: Aleksey Yeschenko)
   Status: Review In Progress  (was: Patch Available)

> Fix flaky 
> org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest
> --
>
> Key: CASSANDRA-17618
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17618
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta
>
>
> The test is flaky on 4.1:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1604/workflows/243a20a5-eda2-4c28-95e8-ab6c4f85a891/jobs/10911
> {code:java}
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
>   at 
> org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest.lambda$testConnectionsAreRejectedWithInvalidConfig$81c80a4a$1(InternodeEncryptionEnforcementTest.java:91)
>   at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
>   at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
>   at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
> {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-17618) Fix flaky org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest

[Jira]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598409#comment-17598409
 ] 

Andres de la Peña commented on CASSANDRA-17618:
---

The fix looks good to me, but I'm not very familiarized with that area of the 
code, so maybe someone else (like [~aleksey] ) can take a look.

> Fix flaky 
> org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest
> --
>
> Key: CASSANDRA-17618
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17618
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta
>
>
> The test is flaky on 4.1:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1604/workflows/243a20a5-eda2-4c28-95e8-ab6c4f85a891/jobs/10911
> {code:java}
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
>   at 
> org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest.lambda$testConnectionsAreRejectedWithInvalidConfig$81c80a4a$1(InternodeEncryptionEnforcementTest.java:91)
>   at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
>   at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
>   at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
> {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-17854) Add JDK17 to our test docker images

[Brandon Williams (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598374#comment-17598374
 ] 

Brandon Williams commented on CASSANDRA-17854:
--

Created CASSANDRA-17871 to address the packages.

I'm not sure how parameterizing would have been able to help here.  If the 
build dependencies are outdated for the distro, they have to be updated.

> Add JDK17 to our test docker images
> ---
>
> Key: CASSANDRA-17854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17854
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> In preparation to support JDK 17 I want to add JDK 17 to our test images to 
> enable our CIs for testing with JDK 17
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-17871) Update debian packages for bullseye

[Brandon Williams (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-17871:
-
Change Category: Operability
 Complexity: Normal
Component/s: Packaging
  Fix Version/s: 4.x
   Assignee: Brandon Williams
 Status: Open  (was: Triage Needed)

> Update debian packages for bullseye
> ---
>
> Key: CASSANDRA-17871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17871
> Project: Cassandra
>  Issue Type: Task
>  Components: Packaging
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> We are updating the buster docker image used to build debian packages to 
> bullseye (which is probably a bit overdue) in CASSANDRA-17854 Package build 
> dependencies for versions using python2 need to be updated for this to work.



--
This message was sent by Atlassian Jira
(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-17871) Update debian packages for bullseye

[Brandon Williams (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-17871:
-
Description: We are updating the buster docker image used to build debian 
packages to bullseye (which is probably a bit overdue) in CASSANDRA-17854 
Package build dependencies for versions using python2 need to be updated for 
this to work.  (was: We are updating the buster docker image used to build 
debian packages to bullseye (which is probably a bit overdue.)  Package build 
dependencies for versions using python2 need to be updated for this to work.)

> Update debian packages for bullseye
> ---
>
> Key: CASSANDRA-17871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17871
> Project: Cassandra
>  Issue Type: Task
>Reporter: Brandon Williams
>Priority: Normal
>
> We are updating the buster docker image used to build debian packages to 
> bullseye (which is probably a bit overdue) in CASSANDRA-17854 Package build 
> dependencies for versions using python2 need to be updated for this to work.



--
This message was sent by Atlassian Jira
(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-17871) Update debian packages for bullseye

[Brandon Williams (Jira)]

Brandon Williams created CASSANDRA-17871:


 Summary: Update debian packages for bullseye
 Key: CASSANDRA-17871
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17871
 Project: Cassandra
  Issue Type: Task
Reporter: Brandon Williams


We are updating the buster docker image used to build debian packages to 
bullseye (which is probably a bit overdue.)  Package build dependencies for 
versions using python2 need to be updated for this to work.



--
This message was sent by Atlassian Jira
(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-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents

[Jira]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andres de la Peña updated CASSANDRA-17804:
--
Reviewers: Andres de la Peña, Caleb Rackliffe  (was: Caleb Rackliffe)

> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically 
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> See 
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>  
> My guess is that in some resource constrained environment, even the first 
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In 
> other words, we skip to the state of the world the last assertion in the test 
> is checking.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents

[Jira]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andres de la Peña updated CASSANDRA-17804:
--
  Since Version: 4.0-alpha2
Source Control Link: 
https://github.com/apache/cassandra/commit/1ee5df02b1f98cf38f126d47a7f3fb153f790d52
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically 
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> See 
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>  
> My guess is that in some resource constrained environment, even the first 
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In 
> other words, we skip to the state of the world the last assertion in the test 
> is checking.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents

[Jira]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598340#comment-17598340
 ] 

Andres de la Peña commented on CASSANDRA-17804:
---

Committed to 4.1 as 
[1ee5df02b1f98cf38f126d47a7f3fb153f790d52|https://github.com/apache/cassandra/commit/1ee5df02b1f98cf38f126d47a7f3fb153f790d52]
 and merged up to 
[trunk|https://github.com/apache/cassandra/commit/b39596b65c6bdbed5f2be35008291c69b41f1675].

> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically 
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> See 
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>  
> My guess is that in some resource constrained environment, even the first 
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In 
> other words, we skip to the state of the world the last assertion in the test 
> is checking.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch cassandra-4.1 updated: Fix flakiness of testAutoSnapshotTTlOnDropAfterRestart

[adelapena]

This is an automated email from the ASF dual-hosted git repository.

adelapena pushed a commit to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/cassandra-4.1 by this push:
 new 1ee5df02b1 Fix flakiness of testAutoSnapshotTTlOnDropAfterRestart
1ee5df02b1 is described below

commit 1ee5df02b1f98cf38f126d47a7f3fb153f790d52
Author: Paulo Motta 
AuthorDate: Sun Aug 14 21:00:04 2022 -0300

Fix flakiness of testAutoSnapshotTTlOnDropAfterRestart

Patch by Paulo Motta; Reviewed by Caleb Rackliffe and Andrés de la Peña for 
CASSANDRA-17804
---
 .../apache/cassandra/distributed/test/AutoSnapshotTtlTest.java | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/test/distributed/org/apache/cassandra/distributed/test/AutoSnapshotTtlTest.java
 
b/test/distributed/org/apache/cassandra/distributed/test/AutoSnapshotTtlTest.java
index afa7984b70..550cbdc6e4 100644
--- 
a/test/distributed/org/apache/cassandra/distributed/test/AutoSnapshotTtlTest.java
+++ 
b/test/distributed/org/apache/cassandra/distributed/test/AutoSnapshotTtlTest.java
@@ -121,15 +121,15 @@ public class AutoSnapshotTtlTest extends TestBaseImpl
 }
 
 /**
- * Check that when auto_snapshot_ttl=5s, snapshots created from TRUNCATE 
are expired after 10s
+ * Check that when auto_snapshot_ttl=60s, snapshots created from DROP 
TABLE are expired after a node restart
  */
 @Test
 public void testAutoSnapshotTTlOnDropAfterRestart() throws IOException
 {
-int TWENTY_SECONDS = 20; // longer TTL to allow snapshot to survive 
node restart
+int ONE_MINUTE = 60; // longer TTL to allow snapshot to survive node 
restart
 try (Cluster cluster = init(build().withNodes(1)
.withConfig(c -> 
c.with(Feature.GOSSIP)
- 
.set("auto_snapshot_ttl", String.format("%ds", TWENTY_SECONDS)))
+ 
.set("auto_snapshot_ttl", String.format("%ds", ONE_MINUTE)))
.start()))
 {
 IInvokableInstance instance = cluster.get(1);
@@ -148,8 +148,8 @@ public class AutoSnapshotTtlTest extends TestBaseImpl
 // Check snapshot is listed after restart
 
instance.nodetoolResult("listsnapshots").asserts().success().stdoutContains(SNAPSHOT_DROP_PREFIX);
 
-// Check snapshot is removed after at most 21s
-await().timeout(TWENTY_SECONDS + 1, SECONDS)
+// Check snapshot is removed after at most auto_snapshot_ttl + 1s
+await().timeout(ONE_MINUTE + 1, SECONDS)
.pollInterval(1, SECONDS)
.until(() -> 
!instance.nodetoolResult("listsnapshots").getStdout().contains(SNAPSHOT_DROP_PREFIX));
 }


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk

[adelapena]

This is an automated email from the ASF dual-hosted git repository.

adelapena pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git

commit b39596b65c6bdbed5f2be35008291c69b41f1675
Merge: 1e2b608213 1ee5df02b1
Author: Andrés de la Peña 
AuthorDate: Wed Aug 31 12:23:33 2022 +0100

Merge branch 'cassandra-4.1' into trunk

 .../apache/cassandra/distributed/test/AutoSnapshotTtlTest.java | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch trunk updated (1e2b608213 -> b39596b65c)

[adelapena]

This is an automated email from the ASF dual-hosted git repository.

adelapena pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


from 1e2b608213 Prevent a user from manually removing ephemeral snapshots
 new 1ee5df02b1 Fix flakiness of testAutoSnapshotTTlOnDropAfterRestart
 new b39596b65c Merge branch 'cassandra-4.1' into trunk

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .../apache/cassandra/distributed/test/AutoSnapshotTtlTest.java | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17854) Add JDK17 to our test docker images

[Michael Semb Wever (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598326#comment-17598326
 ] 

Michael Semb Wever commented on CASSANDRA-17854:


I agree – getting it to work on bulleye incurs less waste. 

But also curious as to how long we can use the same images across all branches, 
and if at some point we need to be parameterising the image the build scripts 
use.

> Add JDK17 to our test docker images
> ---
>
> Key: CASSANDRA-17854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17854
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> In preparation to support JDK 17 I want to add JDK 17 to our test images to 
> enable our CIs for testing with JDK 17
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17854) Add JDK17 to our test docker images

[Brandon Williams (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598318#comment-17598318
 ] 

Brandon Williams commented on CASSANDRA-17854:
--

There's a problem with bullseye building packages for versions on python2 due 
to the build deps in the package.  I can try to rework this in the buster image 
pulling in j17 from somewhere, but I think we should probably adjust the 
packages instead since buster's clock has been ticking. [~mck] WDYT?

> Add JDK17 to our test docker images
> ---
>
> Key: CASSANDRA-17854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17854
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> In preparation to support JDK 17 I want to add JDK 17 to our test images to 
> enable our CIs for testing with JDK 17
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents

[Jira]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598301#comment-17598301
 ] 

Andres de la Peña commented on CASSANDRA-17804:
---

Sure, starting commit.

> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically 
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> See 
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>  
> My guess is that in some resource constrained environment, even the first 
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In 
> other words, we skip to the state of the world the last assertion in the test 
> is checking.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents

[Jira]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andres de la Peña updated CASSANDRA-17804:
--
Status: Ready to Commit  (was: Review In Progress)

> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically 
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> See 
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>  
> My guess is that in some resource constrained environment, even the first 
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In 
> other words, we skip to the state of the world the last assertion in the test 
> is checking.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-8612) Read metrics should be updated on all types of reads

[Claude Warren (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598285#comment-17598285
 ] 

Claude Warren commented on CASSANDRA-8612:
--

[~cnlwsu] I created a pull request 
[https://github.com/apache/cassandra/pull/1827|https://github.com/apache/cassandra/pull/1827)]
 to merge the fix for this into trunk.  Please review.

> Read metrics should be updated on all types of reads
> 
>
> Key: CASSANDRA-8612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8612
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Dean Z
>Priority: Low
>  Labels: lhf, metrics
> Attachments: 0001-Update-read-metrics-on-all-types-of-reads.patch, 
> 0002-Add-more-read-metrics-into-PartitionRangeReadCommand.patch
>
>
> Metrics like "sstables per read" are not updated on a range slice.  Although 
> separating things out for each type of read could make sense like we do for 
> latencies, only exposing the metrics for one type can be a little confusing 
> when people do a query and see nothing increases.  I think its sufficient to 
> use the same metrics for all reads.



--
This message was sent by Atlassian Jira
(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-14218) Deprecate Throwables.propagate usage

[Claude Warren (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598270#comment-17598270
 ] 

Claude Warren commented on CASSANDRA-14218:
---

[~djoshi] , will you be able to review this?

> Deprecate Throwables.propagate usage
> 
>
> Key: CASSANDRA-14218
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14218
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Dependencies
>Reporter: Romain Hardouin
>Assignee: Claude Warren
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 14218-trunk.txt, 14218-trunk.txt, CASSANDRA-14218.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Google decided to deprecate guava {{Throwables.propagate}} method:
>  * [Why we deprecated 
> Throwables.propagate|https://github.com/google/guava/wiki/Why-we-deprecated-Throwables.propagate]
>  * [Documentation 
> update|https://github.com/google/guava/wiki/ThrowablesExplained/_compare/92190ee7e37d334fa5fcdb6db8d0f43a2fdf02e1...226a3060445716d479981e606f589c99eee517ca]
> We have 35 occurences in the trunk:
> {code:java}
> $ rg -c 'Throwables.propagate' *
> src/java/org/apache/cassandra/streaming/StreamReader.java:1
> src/java/org/apache/cassandra/streaming/StreamTransferTask.java:1
> src/java/org/apache/cassandra/db/SnapshotDetailsTabularData.java:1
> src/java/org/apache/cassandra/db/Memtable.java:1
> src/java/org/apache/cassandra/db/ColumnFamilyStore.java:4
> src/java/org/apache/cassandra/cache/ChunkCache.java:2
> src/java/org/apache/cassandra/utils/WrappedRunnable.java:1
> src/java/org/apache/cassandra/hints/Hint.java:1
> src/java/org/apache/cassandra/tools/LoaderOptions.java:1
> src/java/org/apache/cassandra/tools/SSTableOfflineRelevel.java:1
> src/java/org/apache/cassandra/streaming/management/ProgressInfoCompositeData.java:3
> src/java/org/apache/cassandra/streaming/management/StreamStateCompositeData.java:2
> src/java/org/apache/cassandra/streaming/management/StreamSummaryCompositeData.java:2
> src/java/org/apache/cassandra/streaming/compress/CompressedStreamReader.java:1
> src/java/org/apache/cassandra/db/compaction/Scrubber.java:1
> src/java/org/apache/cassandra/db/compaction/Verifier.java:1
> src/java/org/apache/cassandra/db/compaction/CompactionHistoryTabularData.java:1
> src/java/org/apache/cassandra/db/compaction/Upgrader.java:1
> src/java/org/apache/cassandra/io/compress/CompressionMetadata.java:1
> src/java/org/apache/cassandra/streaming/management/SessionCompleteEventCompositeData.java:2
> src/java/org/apache/cassandra/io/sstable/SSTableSimpleWriter.java:1
> src/java/org/apache/cassandra/io/sstable/ISSTableScanner.java:1
> src/java/org/apache/cassandra/streaming/management/SessionInfoCompositeData.java:3
> src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java:1
> {code}
> I don't know if we want to remove all usages but we should at least check 
> author's intention for each usage and refactor if needed.



--
This message was sent by Atlassian Jira
(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-16860) Add --older-than option to nodetool clearsnapshot

[Stefan Miklosovic (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-16860:
--
Test and Documentation Plan: 
java 11 precommit 
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/1235/workflows/30ea1555-99fd-4b17-bd24-a876ab51099c]

java 8 precommit 
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/1235/workflows/d0ebca2b-0fb7-4e2e-9bc6-9a509ca3aa74]

  was:
java 11 precommit

https://app.circleci.com/pipelines/github/instaclustr/cassandra/1234/workflows/695a67c6-5ab6-411a-8a6b-82245b0d7ca0

java 8 precommit 
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1234/workflows/ca06e0f1-9309-4e84-ac90-45743c799925


> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> h1. Summary
> Opening this issue in reference to [this WIP 
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc, 
> based on a TTL. This is to address the problem of snapshots accumulating. For 
> example, an organization I work for aims to keep snapshots for 30 days, 
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in: 
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be 
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the 
> following options:
> NAME
>  nodetool expiresnapshots - Removes snapshots that are older than a TTL
>  in days
> SYNOPSIS
>  nodetool [(-h  | --host )] [(-p  | --port )]
>  [(-pw  | --password )]
>  [(-pwf  | --password-file )]
>  [(-u  | --username )] expiresnapshots [--dry-run]
>  (-t  | --ttl )
> OPTIONS
>  --dry-run
>  Run without actually clearing snapshots
> -h , --host 
>  Node hostname or ip address
> -p , --port 
>  Remote jmx agent port number
> -pw , --password 
>  Remote jmx agent password
> -pwf , --password-file 
>  Path to the JMX password file
> -t , --ttl 
>  TTL (in days) to expire snapshots
> -u , --username 
>  Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps 
> (epoch time in miliseconds). For this reason, snapshot names that don't 
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a 
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
>  Snapshot Details:
>  Snapshot name Keyspace name Column family name True size Size on disk
>  1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
>  Starting simulated cleanup of snapshots older than 30 days
>  Clearing (dry run): 1529173922063
>  Clearing (dry run): 1599173922063
>  Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit 
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
>  Starting cleanup of snapshots older than 30 days
>  Clearing: 1529173922063
>  Clearing: 1599173922063
>  Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still 
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
>  Snapshot Details:
>  Snapshot name Keyspace name Column family name True size Size on disk
>  1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
>  - Tests
>  - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after 
> reading the contribution guide  Any advice on the following would be greatly 
> appreciated!
>  - What branch would this type of change be merged into? Currently, I'm 
> targeting {{apache:trunk}} by default
>  - Is there a test strategy/pattern for this type of change? I was not able 
> to find any existing tests for similar