date:20210924



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

Brandon Williams commented on CASSANDRA-16970:
--

bq. Actually, I think this test is just a bit fragile with regard to replicas.

This is correct, this test at inception will fail in a loop.  Sometimes only 
two of the three replicas will report the tombstone error.  It seems odd that 
earlier it [accepts a range of possible 
replicas|https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/test/ClientTombstoneWarningTest.java#L204]
 but then here it expects all three.  [~dcapwell] can you shed some light?

> Fix 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
> -
>
> Key: CASSANDRA-16970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16970
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
>  is 
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/org.apache.cassandra.distributed.test/ClientTombstoneWarningTest/failThresholdSinglePartition_2/]
> {code:java}
> Error Message
>  expected:<0.1=1, /127.0.0.2=1[, /127.0.0.3=1]}> but was:<0.1=1, 
> /127.0.0.2=1[]}>
>  Stacktrace
>  junit.framework.AssertionFailedError: expected:<0.1=1, /127.0.0.2=1[, 
> /127.0.0.3=1]}> but was:<0.1=1, /127.0.0.2=1[]}>
>  at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
>  at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>  at 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThreshold(ClientTombstoneWarningTest.java:227)
>  at 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition(ClientTombstoneWarningTest.java:180)
>  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16967) Probabilistic diff to sample partitions for diff testing based on probability.

2021-09-24 Thread Yifan Cai (Jira)



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

Yifan Cai updated CASSANDRA-16967:
--
Reviewers: Yifan Cai
   Status: Review In Progress  (was: Patch Available)

+1 on the patch. 
There is a minor change suggested for the logging message.

> Probabilistic diff to sample partitions for diff testing based on probability.
> --
>
> Key: CASSANDRA-16967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16967
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tool/diff
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
>
> Probabilistic diff allows us to sample partitions randomly while running diff 
> tests. It takes new config parameter `partition_sampling_probability ` that 
> ranges between (0-1) and samples partitions based on this probability. The 
> default value for this config property is 1 which means that all the 
> partitions will be diffed. The partitions that are selected are also based on 
> the JobId, for a given sampling probability and JobId we always diff on same 
> partitions.This helps in reproducing any issues that one might run into. 
> Probabilistic diff allows us to run diff jobs on large clusters by sampling 
> some partitions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16967) Probabilistic diff to sample partitions for diff testing based on probability.

2021-09-24 Thread Yifan Cai (Jira)



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

Yifan Cai updated CASSANDRA-16967:
--
Authors: Jyothsna Konisa  (was: Dinesh Joshi, Jyothsna Konisa, Yifan Cai)

> Probabilistic diff to sample partitions for diff testing based on probability.
> --
>
> Key: CASSANDRA-16967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16967
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tool/diff
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
>
> Probabilistic diff allows us to sample partitions randomly while running diff 
> tests. It takes new config parameter `partition_sampling_probability ` that 
> ranges between (0-1) and samples partitions based on this probability. The 
> default value for this config property is 1 which means that all the 
> partitions will be diffed. The partitions that are selected are also based on 
> the JobId, for a given sampling probability and JobId we always diff on same 
> partitions.This helps in reproducing any issues that one might run into. 
> Probabilistic diff allows us to run diff jobs on large clusters by sampling 
> some partitions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16967) Probabilistic diff to sample partitions for diff testing based on probability.

2021-09-24 Thread Yifan Cai (Jira)



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

Yifan Cai updated CASSANDRA-16967:
--
Reviewers: Dinesh Joshi, Yifan Cai  (was: Yifan Cai)

> Probabilistic diff to sample partitions for diff testing based on probability.
> --
>
> Key: CASSANDRA-16967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16967
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tool/diff
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
>
> Probabilistic diff allows us to sample partitions randomly while running diff 
> tests. It takes new config parameter `partition_sampling_probability ` that 
> ranges between (0-1) and samples partitions based on this probability. The 
> default value for this config property is 1 which means that all the 
> partitions will be diffed. The partitions that are selected are also based on 
> the JobId, for a given sampling probability and JobId we always diff on same 
> partitions.This helps in reproducing any issues that one might run into. 
> Probabilistic diff allows us to run diff jobs on large clusters by sampling 
> some partitions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16967) Probabilistic diff to sample partitions for diff testing based on probability.

2021-09-24 Thread Jyothsna Konisa (Jira)



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

Jyothsna Konisa updated CASSANDRA-16967:

Mentor: Yifan Cai  (was: Yifan Gu)

> Probabilistic diff to sample partitions for diff testing based on probability.
> --
>
> Key: CASSANDRA-16967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16967
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tool/diff
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
>
> Probabilistic diff allows us to sample partitions randomly while running diff 
> tests. It takes new config parameter `partition_sampling_probability ` that 
> ranges between (0-1) and samples partitions based on this probability. The 
> default value for this config property is 1 which means that all the 
> partitions will be diffed. The partitions that are selected are also based on 
> the JobId, for a given sampling probability and JobId we always diff on same 
> partitions.This helps in reproducing any issues that one might run into. 
> Probabilistic diff allows us to run diff jobs on large clusters by sampling 
> some partitions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16967) Probabilistic diff to sample partitions for diff testing based on probability.

2021-09-24 Thread Jyothsna Konisa (Jira)



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

Jyothsna Konisa updated CASSANDRA-16967:

Test and Documentation Plan: Unit testing is added in this patch
 Status: Patch Available  (was: Open)

> Probabilistic diff to sample partitions for diff testing based on probability.
> --
>
> Key: CASSANDRA-16967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16967
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tool/diff
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
>
> Probabilistic diff allows us to sample partitions randomly while running diff 
> tests. It takes new config parameter `partition_sampling_probability ` that 
> ranges between (0-1) and samples partitions based on this probability. The 
> default value for this config property is 1 which means that all the 
> partitions will be diffed. The partitions that are selected are also based on 
> the JobId, for a given sampling probability and JobId we always diff on same 
> partitions.This helps in reproducing any issues that one might run into. 
> Probabilistic diff allows us to run diff jobs on large clusters by sampling 
> some partitions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16967) Probabilistic diff to sample partitions for diff testing based on probability.

2021-09-24 Thread Jyothsna Konisa (Jira)



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

Jyothsna Konisa updated CASSANDRA-16967:

Change Category: Operability
 Complexity: Normal
Component/s: Tool/diff
 Mentor: Yifan Gu
 Status: Open  (was: Triage Needed)

> Probabilistic diff to sample partitions for diff testing based on probability.
> --
>
> Key: CASSANDRA-16967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16967
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tool/diff
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
>
> Probabilistic diff allows us to sample partitions randomly while running diff 
> tests. It takes new config parameter `partition_sampling_probability ` that 
> ranges between (0-1) and samples partitions based on this probability. The 
> default value for this config property is 1 which means that all the 
> partitions will be diffed. The partitions that are selected are also based on 
> the JobId, for a given sampling probability and JobId we always diff on same 
> partitions.This helps in reproducing any issues that one might run into. 
> Probabilistic diff allows us to run diff jobs on large clusters by sampling 
> some partitions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-16970) Fix org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition



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

Brandon Williams edited comment on CASSANDRA-16970 at 9/24/21, 9:02 PM:


-Looks like CASSANDRA-12988 is what broke this. /cc [~jmckenzie]-

Actually, I think this test is just a bit fragile with regard to replicas.


was (Author: brandon.williams):
Looks like CASSANDRA-12988 is what broke this. /cc [~jmckenzie]

> Fix 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
> -
>
> Key: CASSANDRA-16970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16970
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
>  is 
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/org.apache.cassandra.distributed.test/ClientTombstoneWarningTest/failThresholdSinglePartition_2/]
> {code:java}
> Error Message
>  expected:<0.1=1, /127.0.0.2=1[, /127.0.0.3=1]}> but was:<0.1=1, 
> /127.0.0.2=1[]}>
>  Stacktrace
>  junit.framework.AssertionFailedError: expected:<0.1=1, /127.0.0.2=1[, 
> /127.0.0.3=1]}> but was:<0.1=1, /127.0.0.2=1[]}>
>  at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
>  at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>  at 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThreshold(ClientTombstoneWarningTest.java:227)
>  at 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition(ClientTombstoneWarningTest.java:180)
>  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16970) Fix org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition



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

Brandon Williams commented on CASSANDRA-16970:
--

Looks like CASSANDRA-12988 is what broke this. /cc [~jmckenzie]

> Fix 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
> -
>
> Key: CASSANDRA-16970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16970
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
>  is 
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/org.apache.cassandra.distributed.test/ClientTombstoneWarningTest/failThresholdSinglePartition_2/]
> {code:java}
> Error Message
>  expected:<0.1=1, /127.0.0.2=1[, /127.0.0.3=1]}> but was:<0.1=1, 
> /127.0.0.2=1[]}>
>  Stacktrace
>  junit.framework.AssertionFailedError: expected:<0.1=1, /127.0.0.2=1[, 
> /127.0.0.3=1]}> but was:<0.1=1, /127.0.0.2=1[]}>
>  at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
>  at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>  at 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThreshold(ClientTombstoneWarningTest.java:227)
>  at 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition(ClientTombstoneWarningTest.java:180)
>  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16987) CQLSH shell script will fail on Python 3.10



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

Ekaterina Dimitrova commented on CASSANDRA-16987:
-

Cherry-picked to 4.0 
[here|https://github.com/ekaterinadimitrova2/cassandra/commit/ed801da8a590178110f02952124b77f474399414]
 and submitted CI run to Jenkins 
[here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/].

> CQLSH shell script will fail on Python 3.10
> ---
>
> Key: CASSANDRA-16987
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16987
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/cqlsh
>Reporter: Bowen Song
>Assignee: Bowen Song
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The `is_supported_version()` function performs a lexicographical comparison 
> between the Python version number in the format of `MAJOR.MINOR` with `3.6`. 
> This works as expected if the Python version number is between `3.0` and 
> `3.9` (inclusive), but will produce an unexpected result if the Python 
> version number is `3.10` or above.
> Recommended fix is to split the version number into two integers, 
> `$version_major` and `$version_minor` and then compare them to `3` and `6` 
> respectively.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15290) Avoid token cache invalidation for removing proxy node



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

Brandon Williams updated CASSANDRA-15290:
-
Fix Version/s: (was: 4.x)

> Avoid token cache invalidation for removing proxy node
> --
>
> Key: CASSANDRA-15290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15290
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Membership
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Low
> Fix For: 4.1
>
>
> As proxy node doesn't own token, adding/removing doesn't change token 
> ownership and no need to invalidate the token cache.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15290) Avoid token cache invalidation for removing proxy node



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

Brandon Williams updated CASSANDRA-15290:
-
  Fix Version/s: 4.1
Source Control Link: 
https://github.com/apache/cassandra/commit/b1e77baa3d7cef7b417fa787e3005a999a440418
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed, thanks!

> Avoid token cache invalidation for removing proxy node
> --
>
> Key: CASSANDRA-15290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15290
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Membership
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Low
> Fix For: 4.1, 4.x
>
>
> As proxy node doesn't own token, adding/removing doesn't change token 
> ownership and no need to invalidate the token cache.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15290) Avoid token cache invalidation for removing proxy node



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

Brandon Williams updated CASSANDRA-15290:
-
Status: Ready to Commit  (was: Review In Progress)

> Avoid token cache invalidation for removing proxy node
> --
>
> Key: CASSANDRA-15290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15290
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Membership
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Low
> Fix For: 4.x
>
>
> As proxy node doesn't own token, adding/removing doesn't change token 
> ownership and no need to invalidate the token cache.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15290) Avoid token cache invalidation for removing proxy node



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

Brandon Williams updated CASSANDRA-15290:
-
Reviewers: Aleksei Zotov, Brandon Williams
   Status: Review In Progress  (was: Needs Committer)

> Avoid token cache invalidation for removing proxy node
> --
>
> Key: CASSANDRA-15290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15290
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Membership
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Low
> Fix For: 4.x
>
>
> As proxy node doesn't own token, adding/removing doesn't change token 
> ownership and no need to invalidate the token cache.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra] branch trunk updated: Avoid token cache invalidation for removing a non-member node

2021-09-24 Thread brandonwilliams

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new b1e77ba  Avoid token cache invalidation for removing a non-member node
b1e77ba is described below

commit b1e77baa3d7cef7b417fa787e3005a999a440418
Author: Jay Zhuang 
AuthorDate: Fri Sep 24 15:20:35 2021 -0500

Avoid token cache invalidation for removing a non-member node

Patch by Jay Zhuang; reviewed by brandonwilliams and azotcsit for
CASSANDRA-15290
---
 CHANGES.txt|  1 +
 .../apache/cassandra/locator/TokenMetadata.java| 10 --
 .../cassandra/locator/TokenMetadataTest.java   | 42 ++
 3 files changed, 50 insertions(+), 3 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index b89bb31..b87dc1e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.1
+ * Avoid token cache invalidation for removing a non-member node 
(CASSANDRA-15290)
  * Allow configuration of consistency levels on auth operations 
(CASSANDRA-12988)
  * Add number of sstables in a compaction to compactionstats output 
(CASSANDRA-16844)
  * Upgrade Caffeine to 2.9.2 (CASSANDRA-15153)
diff --git a/src/java/org/apache/cassandra/locator/TokenMetadata.java 
b/src/java/org/apache/cassandra/locator/TokenMetadata.java
index ac71f07..390413a 100644
--- a/src/java/org/apache/cassandra/locator/TokenMetadata.java
+++ b/src/java/org/apache/cassandra/locator/TokenMetadata.java
@@ -496,7 +496,7 @@ public class TokenMetadata
 try
 {
 bootstrapTokens.removeValue(endpoint);
-tokenToEndpointMap.removeValue(endpoint);
+
 topology = topology.unbuild().removeEndpoint(endpoint).build();
 leavingEndpoints.remove(endpoint);
 if (replacementToOriginal.remove(endpoint) != null)
@@ -504,8 +504,12 @@ public class TokenMetadata
 logger.debug("Node {} failed during replace.", endpoint);
 }
 endpointToHostIdMap.remove(endpoint);
-sortedTokens = sortTokens();
-invalidateCachedRingsUnsafe();
+Collection removedTokens = 
tokenToEndpointMap.removeValue(endpoint);
+if (removedTokens != null && !removedTokens.isEmpty())
+{
+sortedTokens = sortTokens();
+invalidateCachedRingsUnsafe();
+}
 }
 finally
 {
diff --git a/test/unit/org/apache/cassandra/locator/TokenMetadataTest.java 
b/test/unit/org/apache/cassandra/locator/TokenMetadataTest.java
index 9e34b93..bb8a177 100644
--- a/test/unit/org/apache/cassandra/locator/TokenMetadataTest.java
+++ b/test/unit/org/apache/cassandra/locator/TokenMetadataTest.java
@@ -19,12 +19,15 @@ package org.apache.cassandra.locator;
 
 import java.net.UnknownHostException;
 import java.util.ArrayList;
+import java.util.Collection;
+import java.util.HashSet;
 import java.util.Map;
 import java.util.UUID;
 import java.util.concurrent.ExecutorService;
 import java.util.concurrent.Executors;
 import java.util.concurrent.TimeUnit;
 
+import com.google.common.collect.HashMultimap;
 import com.google.common.collect.ImmutableMultimap;
 import com.google.common.collect.Iterators;
 import com.google.common.collect.Multimap;
@@ -348,4 +351,43 @@ public class TokenMetadataTest
 assertEquals(0, tokenMetadata.getSizeOfLeavingEndpoints());
 assertEquals(0, tokenMetadata.getSizeOfMovingEndpoints());
 }
+
+
+@Test
+public void testRemoveEndpointTokenChange() throws Exception
+{
+TokenMetadata metadata = StorageService.instance.getTokenMetadata();
+metadata.clearUnsafe();
+
+Collection tokens = new HashSet<>();
+tokens.add(DatabaseDescriptor.getPartitioner().getRandomToken());
+tokens.add(DatabaseDescriptor.getPartitioner().getRandomToken());
+
+InetAddressAndPort ep1 = InetAddressAndPort.getByName("127.0.0.1");
+InetAddressAndPort ep2 = InetAddressAndPort.getByName("127.0.0.2");
+
+Multimap endpointTokens = 
HashMultimap.create();
+for (Token token : tokens)
+endpointTokens.put(ep1, token);
+
+endpointTokens.put(ep2, 
DatabaseDescriptor.getPartitioner().getRandomToken());
+
+long ver = metadata.getRingVersion();
+metadata.updateNormalTokens(endpointTokens);
+assertTrue(metadata.getRingVersion() > ver);
+
+// Remove a normal endpoint
+assertTrue(metadata.isMember(ep2));
+ver = metadata.getRingVersion();
+metadata.removeEndpoint(ep2);
+assertFalse(metadata.isMember(ep2));
+assertTrue(metadata.getRingVersion() > ver);
+
+// Remove a non-exist endpoint (e.g. proxy node is not part of token 
metadata)
+InetAddressAndPort ep3 = InetAddressAndPort.getByName("127.0.0.3");
+

[jira] [Commented] (CASSANDRA-16896) Add soft/hard limits to local reads to protect against reading too much data in a single query



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

Caleb Rackliffe commented on CASSANDRA-16896:
-

Trying Apache CI again: 
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1142/

> Add soft/hard limits to local reads to protect against reading too much data 
> in a single query
> --
>
> Key: CASSANDRA-16896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16896
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Local Write-Read Paths
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 19h
>  Remaining Estimate: 0h
>
> Add soft/hard limits to local reads to protect against reading too much data 
> in a single query.
> This is an extension of the existing work to add warnings/aborts to large 
> partitions (CASSANDRA-16850), with the core difference is that this applies 
> locally rather than at the coordinator.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16944) Single partition reads can read more SSTables than required



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

Caleb Rackliffe commented on CASSANDRA-16944:
-

Latest feedback commits LGTM

> Single partition reads can read more SSTables than required 
> 
>
> Key: CASSANDRA-16944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16944
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> For some scenarios involving row deletions, range deletions or static 
> columns, the logic of 
> {{SinglePartitionReadCommand.queryMemtableAndSSTablesInTimestampOrder}} might 
> trigger more SSTables reads that expected. 
> For row deletions and range deletions the reasons is that the logic do not 
> take them into account. Once we hit a deleted row (caused by a row deletion 
> or a range deletion) with a timestamp higher than the one of the next SStable 
> we know that we can stop reading more SSTables.
> For static columns the problems seems to have been introduced by the changes 
> in CASSANDRA-16671.  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4



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

Stefan Miklosovic updated CASSANDRA-9384:
-
Status: In Progress  (was: Patch Available)

> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Assigned] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4



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

Stefan Miklosovic reassigned CASSANDRA-9384:


Assignee: Stefan Miklosovic  (was: Dinesh Joshi)

> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16987) CQLSH shell script will fail on Python 3.10



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

Brandon Williams commented on CASSANDRA-16987:
--

bq. Brandon Williams, if you don't have any other opinion, I can push also 4.0 
CI and commit. I don't expect any difference to what we saw already for trunk 
but for completeness and to prevent any future unpleasant surprises.

Totally agree with all of that, +1.

> CQLSH shell script will fail on Python 3.10
> ---
>
> Key: CASSANDRA-16987
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16987
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/cqlsh
>Reporter: Bowen Song
>Assignee: Bowen Song
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The `is_supported_version()` function performs a lexicographical comparison 
> between the Python version number in the format of `MAJOR.MINOR` with `3.6`. 
> This works as expected if the Python version number is between `3.0` and 
> `3.9` (inclusive), but will produce an unexpected result if the Python 
> version number is `3.10` or above.
> Recommended fix is to split the version number into two integers, 
> `$version_major` and `$version_minor` and then compare them to `3` and `6` 
> respectively.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-16987) CQLSH shell script will fail on Python 3.10



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

Ekaterina Dimitrova edited comment on CASSANDRA-16987 at 9/24/21, 5:55 PM:
---

 

[~Bowen Song] all valid questions and comments. Let me clarify a bit.
{quote}I can see the test result is 7 failures (+4) , 960 skipped (-36)
{quote}
I submitted your patch to Jenkins dev which is accessible for testing patches 
pre-commit by PMC and committers. In that sense the comparison you see is to 
other patches tested there and not to the official [Jenkins post-commit builds 
history|https://jenkins-cm4.apache.org/]. What we do is comparing to the 
post-commit builds whether we introduced something new or there is history 
around some of the tests If we are not sure whether the test was broken by us 
or not. We also look at already opened tickets for tests issues - [this Jira 
filter|https://issues.apache.org/jira/issues/?filter=12350869], linked by Josh 
in one of the [project 
updates|https://lists.apache.org/thread.html/r681bcfcfa938569ae7fb86c0c309ee7d84558f1cc07eb2c1a30468c7%40%3Cdev.cassandra.apache.org%3E]
 on the mailing list. On a side note, we try to open also tickets for unrelated 
to our patch failures that no one has reported yet. 

Unfortunately, only committers and PMC members can submit Jenkins dev CI runs. 
But you might want to explore Circle CI. (Just please bear in mind that if you 
use LOWRES resources not all dtests will be able to run as they require more 
resources. Please contact me in Slack if you need more help with this or some 
info for the higher resources.)
 More information about our test environment can be found 
[here|https://cassandra.apache.org/_/development/testing.html]

 

I also agree that the mentioned failures are not related to your patch.
 * 
[dtest-novnode.scrub_test.TestScrubIndexes.test_scrub_collections_table|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1141/testReport/junit/dtest-novnode.scrub_test/TestScrubIndexes/test_scrub_collections_table/]
 - CASSANDRA-16954
 * 
[org.apache.cassandra.net.ConnectionTest.testMessageDeliveryOnReconnect|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1141/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect/]
 - CASSANDRA-16677

The rest of the failures seem like infrastructure known issues.

[~brandon.williams], if you don't have any other opinion, I can push also 4.0 
CI and commit. I don't expect any difference to what we saw already for trunk 
but for completeness and to prevent any future unpleasant surprises.


was (Author: e.dimitrova):
 

[~Bowen Song] all valid questions and comments. Let me clarify a bit.
{quote}I can see the test result is 7 failures (+4) , 960 skipped (-36)
{quote}
I submitted your patch to Jenkins dev which is accessible for testing patches 
pre-commit by PMC and committers. In that sense the comparison you see is to 
other patches tested there and not to the official [Jenkins post-commit builds 
history|https://jenkins-cm4.apache.org/]. What we do is comparing to the 
post-commit builds whether we introduced something new or there is history 
around some of the tests If we are not sure whether the test was broken by us 
or not. We also look at already opened tickets for tests issues - [this Jira 
filter|https://issues.apache.org/jira/issues/?filter=12350869], linked by Josh 
in one of the [project 
updates|https://lists.apache.org/thread.html/r681bcfcfa938569ae7fb86c0c309ee7d84558f1cc07eb2c1a30468c7%40%3Cdev.cassandra.apache.org%3E]
 on the mailing list. On a side note, we try to open also tickets for unrelated 
to our patch failures that no one has reported yet. 

Unfortunately, only committers and PMC members can submit Jenkins dev CI runs. 
But you might want to explore Circle CI. (Just please bear in mind that if you 
use LOWRES resources not all dtests will be able to run as they require more 
resources. Please contact me in Slack if you need more help with this or some 
info for the higher resources.)
 More information about our test environment can be found 
[here|https://cassandra.apache.org/_/development/testing.html]

 

I also agree that the mentioned failures are not related to your patch.
 * 
[dtest-novnode.scrub_test.TestScrubIndexes.test_scrub_collections_table|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1141/testReport/junit/dtest-novnode.scrub_test/TestScrubIndexes/test_scrub_collections_table/]
 - CASSANDRA-16954
 * 
[org.apache.cassandra.net.ConnectionTest.testMessageDeliveryOnReconnect|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1141/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect/]
 - CASSANDRA-16677

The rest of the failures seem like infrastructure known issues.

[~brandon.williams], if you don't have any other opinion,

[jira] [Comment Edited] (CASSANDRA-16987) CQLSH shell script will fail on Python 3.10



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

Ekaterina Dimitrova edited comment on CASSANDRA-16987 at 9/24/21, 5:54 PM:
---

 

[~Bowen Song] all valid questions and comments. Let me clarify a bit.
{quote}I can see the test result is 7 failures (+4) , 960 skipped (-36)
{quote}
I submitted your patch to Jenkins dev which is accessible for testing patches 
pre-commit by PMC and committers. In that sense the comparison you see is to 
other patches tested there and not to the official [Jenkins post-commit builds 
history|https://jenkins-cm4.apache.org/]. What we do is comparing to the 
post-commit builds whether we introduced something new or there is history 
around some of the tests If we are not sure whether the test was broken by us 
or not. We also look at already opened tickets for tests issues - [this Jira 
filter|https://issues.apache.org/jira/issues/?filter=12350869], linked by Josh 
in one of the [project 
updates|https://lists.apache.org/thread.html/r681bcfcfa938569ae7fb86c0c309ee7d84558f1cc07eb2c1a30468c7%40%3Cdev.cassandra.apache.org%3E]
 on the mailing list. On a side note, we try to open also tickets for unrelated 
to our patch failures that no one has reported yet. 

Unfortunately, only committers and PMC members can submit Jenkins dev CI runs. 
But you might want to explore Circle CI. (Just please bear in mind that if you 
use LOWRES resources not all dtests will be able to run as they require more 
resources. Please contact me in Slack if you need more help with this or some 
info for the higher resources.)
 More information about our test environment can be found 
[here|https://cassandra.apache.org/_/development/testing.html]

 

I also agree that the mentioned failures are not related to your patch.
 * 
[dtest-novnode.scrub_test.TestScrubIndexes.test_scrub_collections_table|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1141/testReport/junit/dtest-novnode.scrub_test/TestScrubIndexes/test_scrub_collections_table/]
 - CASSANDRA-16954
 * 
[org.apache.cassandra.net.ConnectionTest.testMessageDeliveryOnReconnect|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1141/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect/]
 - CASSANDRA-16677

The rest of the failures seem like infrastructure known issues.

[~brandon.williams], if you don't have any other opinion, I can push also 4.0 
CI and commit. I don't expect any difference to what we saw but for 
completeness and to prevent any future unpleasant surprises.


was (Author: e.dimitrova):
 

[~Bowen Song] all valid questions and comments. Let me clarify a bit.
{quote}I can see the test result is 7 failures (+4) , 960 skipped (-36)
{quote}
I submitted your patch to Jenkins dev which is accessible for testing patches 
pre-commit by PMC and committers. In that sense the comparison you see is to 
other patches tested there and not to the official [Jenkins post-commit builds 
history|https://jenkins-cm4.apache.org/]. What we do is checking there whether 
we introduced something new or there is history around some of the tests If we 
are not sure whether the test was broken by us or not. We also look at already 
opened tickets for tests issues - [this Jira 
filter|https://issues.apache.org/jira/issues/?filter=12350869], linked by Josh 
in one of the [project 
updates|https://lists.apache.org/thread.html/r681bcfcfa938569ae7fb86c0c309ee7d84558f1cc07eb2c1a30468c7%40%3Cdev.cassandra.apache.org%3E]
 on the mailing list. On a side note, we try to open also tickets for unrelated 
to our patch failures that no one has reported yet. 

Unfortunately, only committers and PMC members can submit Jenkins dev CI runs. 
But you might want to explore Circle CI. (Just please bear in mind that if you 
use LOWRES resources not all dtests will be able to run as they require more 
resources. Please contact me in Slack if you need more help with this or some 
info for the higher resources.)
More information about our test environment can be found 
[here|https://cassandra.apache.org/_/development/testing.html]

 

I also agree that the mentioned failures are not related to your patch.
 * 
[dtest-novnode.scrub_test.TestScrubIndexes.test_scrub_collections_table|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1141/testReport/junit/dtest-novnode.scrub_test/TestScrubIndexes/test_scrub_collections_table/]
 - CASSANDRA-16954
 * 
[org.apache.cassandra.net.ConnectionTest.testMessageDeliveryOnReconnect|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1141/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect/]
 - CASSANDRA-16677

The rest of the failures seem like infrastructure known issues.

[~brandon.williams], if you don't have any other opinion, I can push also 4.0 
CI and commit. I do

[jira] [Commented] (CASSANDRA-16987) CQLSH shell script will fail on Python 3.10



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

Ekaterina Dimitrova commented on CASSANDRA-16987:
-

 

[~Bowen Song] all valid questions and comments. Let me clarify a bit.
{quote}I can see the test result is 7 failures (+4) , 960 skipped (-36)
{quote}
I submitted your patch to Jenkins dev which is accessible for testing patches 
pre-commit by PMC and committers. In that sense the comparison you see is to 
other patches tested there and not to the official [Jenkins post-commit builds 
history|https://jenkins-cm4.apache.org/]. What we do is checking there whether 
we introduced something new or there is history around some of the tests If we 
are not sure whether the test was broken by us or not. We also look at already 
opened tickets for tests issues - [this Jira 
filter|https://issues.apache.org/jira/issues/?filter=12350869], linked by Josh 
in one of the [project 
updates|https://lists.apache.org/thread.html/r681bcfcfa938569ae7fb86c0c309ee7d84558f1cc07eb2c1a30468c7%40%3Cdev.cassandra.apache.org%3E]
 on the mailing list. On a side note, we try to open also tickets for unrelated 
to our patch failures that no one has reported yet. 

Unfortunately, only committers and PMC members can submit Jenkins dev CI runs. 
But you might want to explore Circle CI. (Just please bear in mind that if you 
use LOWRES resources not all dtests will be able to run as they require more 
resources. Please contact me in Slack if you need more help with this or some 
info for the higher resources.)
More information about our test environment can be found 
[here|https://cassandra.apache.org/_/development/testing.html]

 

I also agree that the mentioned failures are not related to your patch.
 * 
[dtest-novnode.scrub_test.TestScrubIndexes.test_scrub_collections_table|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1141/testReport/junit/dtest-novnode.scrub_test/TestScrubIndexes/test_scrub_collections_table/]
 - CASSANDRA-16954
 * 
[org.apache.cassandra.net.ConnectionTest.testMessageDeliveryOnReconnect|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1141/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect/]
 - CASSANDRA-16677

The rest of the failures seem like infrastructure known issues.

[~brandon.williams], if you don't have any other opinion, I can push also 4.0 
CI and commit. I don't expect any difference to what we saw but for 
completeness and to prevent any future unpleasant surprises.

> CQLSH shell script will fail on Python 3.10
> ---
>
> Key: CASSANDRA-16987
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16987
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/cqlsh
>Reporter: Bowen Song
>Assignee: Bowen Song
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The `is_supported_version()` function performs a lexicographical comparison 
> between the Python version number in the format of `MAJOR.MINOR` with `3.6`. 
> This works as expected if the Python version number is between `3.0` and 
> `3.9` (inclusive), but will produce an unexpected result if the Python 
> version number is `3.10` or above.
> Recommended fix is to split the version number into two integers, 
> `$version_major` and `$version_minor` and then compare them to `3` and `6` 
> respectively.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16927) Mockable Streaming



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

Sam Tunnicliffe updated CASSANDRA-16927:

Test and Documentation Plan: new and existing utests & dtests
 Status: Patch Available  (was: Open)

Branch: https://github.com/beobal/cassandra/tree/16927-trunk 
PR: https://github.com/beobal/cassandra/pull/7

Note: the branch dependency order is out of whack at the end of these phase 1 
issues:

16923 <- 16924 <- 16925 <- 16926 <- *16928* <- 16927 

> Mockable Streaming
> --
>
> Key: CASSANDRA-16927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16927
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Streaming and Messaging
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
>
> To support CEP-10 it is necessary to support alternative streaming 
> implementations, so that execution may be controlled. The ticket encompasses 
> two sub-tickets: firstly we make InetAddressAndPort extend InetAddress so 
> that we may 2) introduce a cross-classloader API for establishing a streaming 
> connection and sending data over it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Assigned] (CASSANDRA-16928) InetAddressAndPort to extend InetAddress



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

Sam Tunnicliffe reassigned CASSANDRA-16928:
---

Assignee: Benedict Elliott Smith

> InetAddressAndPort to extend InetAddress
> 
>
> Key: CASSANDRA-16928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16928
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
>
> Logically InetAddressAndPort encapsulates the same information as a simple 
> InetAddress. Importantly, InetAddressAndPort cannot easily be unpicked from 
> its dependencies that prohibit it being shared between classloaders. So our 
> in-jvm dtest API instead uses SocketAddress. To support a clean and efficient 
> Streaming API we need to be able to treat InetAddressAndPort as such a 
> cross-classloader type.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16927) Mockable Streaming



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

Sam Tunnicliffe updated CASSANDRA-16927:

Change Category: Quality Assurance
 Complexity: Normal
Component/s: Legacy/Streaming and Messaging
  Reviewers: Sam Tunnicliffe
   Assignee: Benedict Elliott Smith
 Status: Open  (was: Triage Needed)

> Mockable Streaming
> --
>
> Key: CASSANDRA-16927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16927
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Streaming and Messaging
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
>
> To support CEP-10 it is necessary to support alternative streaming 
> implementations, so that execution may be controlled. The ticket encompasses 
> two sub-tickets: firstly we make InetAddressAndPort extend InetAddress so 
> that we may 2) introduce a cross-classloader API for establishing a streaming 
> connection and sending data over it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16928) InetAddressAndPort to extend InetAddress



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

Sam Tunnicliffe updated CASSANDRA-16928:

Authors: Benedict Elliott Smith
Test and Documentation Plan: existing and new utests & dtests
 Status: Patch Available  (was: Open)

Branch: https://github.com/beobal/cassandra/tree/16928-trunk 
PR: https://github.com/beobal/cassandra/pull/8

Note: the branch dependency order is out of whack at the end of these phase 1 
issues:

16923 <- 16924 <- 16925 <- 16926 <- *16928* <- 16927 

> InetAddressAndPort to extend InetAddress
> 
>
> Key: CASSANDRA-16928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16928
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Logically InetAddressAndPort encapsulates the same information as a simple 
> InetAddress. Importantly, InetAddressAndPort cannot easily be unpicked from 
> its dependencies that prohibit it being shared between classloaders. So our 
> in-jvm dtest API instead uses SocketAddress. To support a clean and efficient 
> Streaming API we need to be able to treat InetAddressAndPort as such a 
> cross-classloader type.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16928) InetAddressAndPort to extend InetAddress



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

Sam Tunnicliffe updated CASSANDRA-16928:

Change Category: Quality Assurance
 Complexity: Normal
Component/s: Legacy/Core
  Reviewers: Sam Tunnicliffe
 Status: Open  (was: Triage Needed)

> InetAddressAndPort to extend InetAddress
> 
>
> Key: CASSANDRA-16928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16928
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Logically InetAddressAndPort encapsulates the same information as a simple 
> InetAddress. Importantly, InetAddressAndPort cannot easily be unpicked from 
> its dependencies that prohibit it being shared between classloaders. So our 
> in-jvm dtest API instead uses SocketAddress. To support a clean and efficient 
> Streaming API we need to be able to treat InetAddressAndPort as such a 
> cross-classloader type.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken



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

Ekaterina Dimitrova commented on CASSANDRA-16497:
-

CASSANDRA-16993 was opened to revisit/rewrite this test.

FIY - the last patch provided fails in my environment too. 

> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc1, 4.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {noformat}
> junit.framework.AssertionFailedError
>   at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
>   at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-16497) concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken



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

Ekaterina Dimitrova edited comment on CASSANDRA-16497 at 9/24/21, 5:17 PM:
---

CASSANDRA-16993 was opened to revisit/rewrite this test.

FIY - with the last patch provided the test still fails in my environment. 


was (Author: e.dimitrova):
CASSANDRA-16993 was opened to revisit/rewrite this test.

FIY - the last patch provided fails in my environment too. 

> concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution broken
> --
>
> Key: CASSANDRA-16497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16497
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Adam Holmberg
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc1, 4.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {noformat}
> junit.framework.AssertionFailedError
>   at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
>   at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> {noformat}
> https://ci-cassandra.apache.org/job/Cassandra-trunk/308/testReport/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Ekaterina Dimitrova commented on CASSANDRA-16973:
-

CASSANDRA-16993 opened

> Fix 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
> 
>
> Key: CASSANDRA-16973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.26, 3.11.12
>
>
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
>  fails in 
> [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
> h3.  
> {code:java}
> Stacktrace
> junit.framework.AssertionFailedError at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
>  at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> Standard Output
> Completed 0K batches with 0.0M events Running for 120s with load multiplier 
> 0.5
> Standard Error
> SLF4J: The following set of substitute loggers may have been accessed SLF4J: 
> during the initialization phase. Logging calls during this SLF4J: phase were 
> not honored. However, subsequent logging calls to these SLF4J: loggers will 
> work as normally expected. SLF4J: See also
> http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.cassandra.LogbackStatusListener
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16993) Rewrite concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Ekaterina Dimitrova updated CASSANDRA-16993:

Fix Version/s: 4.x
   4.0.x
   3.11.x
   3.0.x

> Rewrite concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution 
> 
>
> Key: CASSANDRA-16993
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16993
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/burn
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> This test has numerous issues in its implementation (please check 
> CASSANDRA-16497) and it was decided to rewrite it post 4.0 to jmh.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16993) Rewrite concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Ekaterina Dimitrova updated CASSANDRA-16993:

Change Category: Quality Assurance
 Complexity: Normal
Component/s: Test/burn
 Status: Open  (was: Triage Needed)

> Rewrite concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution 
> 
>
> Key: CASSANDRA-16993
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16993
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/burn
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> This test has numerous issues in its implementation (please check 
> CASSANDRA-16497) and it was decided to rewrite it post 4.0 to jmh.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16993) Rewrite concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Ekaterina Dimitrova updated CASSANDRA-16993:

Description: This test has numerous issues in its implementation (please 
check CASSANDRA-16497) and it was decided to rewrite it post 4.0 to jmh.  (was: 
++This test has numerous issues in its implementation and it was decided to 
rewrite it post 4.0 to jmh.)

> Rewrite concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution 
> 
>
> Key: CASSANDRA-16993
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16993
> Project: Cassandra
>  Issue Type: Task
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> This test has numerous issues in its implementation (please check 
> CASSANDRA-16497) and it was decided to rewrite it post 4.0 to jmh.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (CASSANDRA-16993) Rewrite concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution

Ekaterina Dimitrova created CASSANDRA-16993:
---

 Summary: Rewrite 
concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution 
 Key: CASSANDRA-16993
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16993
 Project: Cassandra
  Issue Type: Task
Reporter: Ekaterina Dimitrova


++This test has numerous issues in its implementation and it was decided to 
rewrite it post 4.0 to jmh.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
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.0' into trunk

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

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

commit 01ca6057c0f29c953bcc0cde590e27fadc1070fd
Merge: 9f15ec6 89f35a4
Author: Ekaterina Dimitrova 
AuthorDate: Fri Sep 24 12:54:10 2021 -0400

Merge branch 'cassandra-4.0' into trunk


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

[cassandra] branch trunk updated (9f15ec6 -> 01ca605)

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

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


from 9f15ec6  Evaluate consistency levels of auth reads
 add bd406c7  Ignore LongSharedExecutorPoolTest until SEPThreadpool is 
re-evaluated
 add 9107797  Merge branch 'cassandra-3.0' into cassandra-3.11
 add 89f35a4  Merge branch 'cassandra-3.11' into cassandra-4.0
 new 01ca605  Merge branch 'cassandra-4.0' into trunk

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


Summary of changes:

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

[cassandra] branch cassandra-4.0 updated (77144aa -> 89f35a4)

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

edimitrova pushed a change to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from 77144aa  Merge branch 'cassandra-3.11' into cassandra-4.0
 add bd406c7  Ignore LongSharedExecutorPoolTest until SEPThreadpool is 
re-evaluated
 add 9107797  Merge branch 'cassandra-3.0' into cassandra-3.11
 add 89f35a4  Merge branch 'cassandra-3.11' into cassandra-4.0

No new revisions were added by this update.

Summary of changes:

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

[cassandra] branch cassandra-3.11 updated (6a3440b -> 9107797)

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

edimitrova pushed a change to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from 6a3440b  Merge branch 'cassandra-3.0' into cassandra-3.11
 add bd406c7  Ignore LongSharedExecutorPoolTest until SEPThreadpool is 
re-evaluated
 add 9107797  Merge branch 'cassandra-3.0' into cassandra-3.11

No new revisions were added by this update.

Summary of changes:
 .../org/apache/cassandra/concurrent/LongSharedExecutorPoolTest.java| 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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

[cassandra] branch cassandra-3.0 updated (af85e7a -> bd406c7)

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

edimitrova pushed a change to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from af85e7a  Fix flaky ViewTest#testTruncateWhileBuilding
 add bd406c7  Ignore LongSharedExecutorPoolTest until SEPThreadpool is 
re-evaluated

No new revisions were added by this update.

Summary of changes:
 .../org/apache/cassandra/concurrent/LongSharedExecutorPoolTest.java| 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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

[jira] [Updated] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Ekaterina Dimitrova updated CASSANDRA-16973:

Fix Version/s: (was: 3.11.x)
   (was: 3.0.x)
   3.11.12
   3.0.26

> Fix 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
> 
>
> Key: CASSANDRA-16973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.26, 3.11.12
>
>
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
>  fails in 
> [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
> h3.  
> {code:java}
> Stacktrace
> junit.framework.AssertionFailedError at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
>  at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> Standard Output
> Completed 0K batches with 0.0M events Running for 120s with load multiplier 
> 0.5
> Standard Error
> SLF4J: The following set of substitute loggers may have been accessed SLF4J: 
> during the initialization phase. Logging calls during this SLF4J: phase were 
> not honored. However, subsequent logging calls to these SLF4J: loggers will 
> work as normally expected. SLF4J: See also
> http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.cassandra.LogbackStatusListener
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Ekaterina Dimitrova updated CASSANDRA-16973:

  Since Version: 3.0.25
Source Control Link: 
https://github.com/apache/cassandra/commit/bd406c7ca9650ab724a938ee6471af788c55a38e
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Fix 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
> 
>
> Key: CASSANDRA-16973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
>  fails in 
> [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
> h3.  
> {code:java}
> Stacktrace
> junit.framework.AssertionFailedError at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
>  at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> Standard Output
> Completed 0K batches with 0.0M events Running for 120s with load multiplier 
> 0.5
> Standard Error
> SLF4J: The following set of substitute loggers may have been accessed SLF4J: 
> during the initialization phase. Logging calls during this SLF4J: phase were 
> not honored. However, subsequent logging calls to these SLF4J: loggers will 
> work as normally expected. SLF4J: See also
> http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.cassandra.LogbackStatusListener
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Ekaterina Dimitrova updated CASSANDRA-16973:

Status: Ready to Commit  (was: Review In Progress)

> Fix 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
> 
>
> Key: CASSANDRA-16973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
>  fails in 
> [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
> h3.  
> {code:java}
> Stacktrace
> junit.framework.AssertionFailedError at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
>  at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> Standard Output
> Completed 0K batches with 0.0M events Running for 120s with load multiplier 
> 0.5
> Standard Error
> SLF4J: The following set of substitute loggers may have been accessed SLF4J: 
> during the initialization phase. Logging calls during this SLF4J: phase were 
> not honored. However, subsequent logging calls to these SLF4J: loggers will 
> work as normally expected. SLF4J: See also
> http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.cassandra.LogbackStatusListener
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Ekaterina Dimitrova updated CASSANDRA-16973:

Reviewers: Brandon Williams, Ekaterina Dimitrova, Ekaterina Dimitrova  
(was: Brandon Williams, Ekaterina Dimitrova)
   Brandon Williams, Ekaterina Dimitrova, Ekaterina Dimitrova
   Status: Review In Progress  (was: Patch Available)

> Fix 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
> 
>
> Key: CASSANDRA-16973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
>  fails in 
> [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
> h3.  
> {code:java}
> Stacktrace
> junit.framework.AssertionFailedError at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
>  at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> Standard Output
> Completed 0K batches with 0.0M events Running for 120s with load multiplier 
> 0.5
> Standard Error
> SLF4J: The following set of substitute loggers may have been accessed SLF4J: 
> during the initialization phase. Logging calls during this SLF4J: phase were 
> not honored. However, subsequent logging calls to these SLF4J: loggers will 
> work as normally expected. SLF4J: See also
> http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.cassandra.LogbackStatusListener
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Ekaterina Dimitrova updated CASSANDRA-16973:

Test and Documentation Plan: No new tests needed, we just ignore one test. 
Tested locally
 Status: Patch Available  (was: In Progress)

> Fix 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
> 
>
> Key: CASSANDRA-16973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
>  fails in 
> [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
> h3.  
> {code:java}
> Stacktrace
> junit.framework.AssertionFailedError at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
>  at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> Standard Output
> Completed 0K batches with 0.0M events Running for 120s with load multiplier 
> 0.5
> Standard Error
> SLF4J: The following set of substitute loggers may have been accessed SLF4J: 
> during the initialization phase. Logging calls during this SLF4J: phase were 
> not honored. However, subsequent logging calls to these SLF4J: loggers will 
> work as normally expected. SLF4J: See also
> http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.cassandra.LogbackStatusListener
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Ekaterina Dimitrova commented on CASSANDRA-16973:
-

Committed to 3.0 and 3.11, empty commit to 4.0 and trunk where we already 
ignored the test.

To https://github.com/apache/cassandra.git

   af85e7ad49..bd406c7ca9  cassandra-3.0 -> cassandra-3.0

   6a3440bd61..91077975df  cassandra-3.11 -> cassandra-3.11

   77144aa472..89f35a49a0  cassandra-4.0 -> cassandra-4.0

   9f15ec6de1..01ca6057c0  trunk -> trunk

> Fix 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
> 
>
> Key: CASSANDRA-16973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
>  fails in 
> [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
> h3.  
> {code:java}
> Stacktrace
> junit.framework.AssertionFailedError at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
>  at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> Standard Output
> Completed 0K batches with 0.0M events Running for 120s with load multiplier 
> 0.5
> Standard Error
> SLF4J: The following set of substitute loggers may have been accessed SLF4J: 
> during the initialization phase. Logging calls during this SLF4J: phase were 
> not honored. However, subsequent logging calls to these SLF4J: loggers will 
> work as normally expected. SLF4J: See also
> http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.cassandra.LogbackStatusListener
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-14612) Please add OWASP Dependency Check to the build (pom.xml)



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

Stefan Miklosovic commented on CASSANDRA-14612:
---

So, I would like to merge these but first we have to figure out 
https://issues.apache.org/jira/browse/CASSANDRA-9384

Also, we need to figure out what to do with this 
https://issues.apache.org/jira/browse/CASSANDRA-16056 

I make this ticket dependable on these two to be resolved.

I put there all suppressions and I set the bar pretty low so we detect 
everything happens with "lib" dir we ship.

3.0 [https://github.com/instaclustr/cassandra/tree/CASSANDRA-14612-3.0]
 3.11 [https://github.com/instaclustr/cassandra/tree/CASSANDRA-14612-3.11]
 4.0 [https://github.com/instaclustr/cassandra/tree/CASSANDRA-14612-4.0]
 trunk [https://github.com/instaclustr/cassandra/tree/CASSANDRA-14612-trunk]

For reference, patch for the pipeline is here: 
https://github.com/apache/cassandra-builds/pull/57

 

> Please add OWASP Dependency Check to the build (pom.xml)
> 
>
> Key: CASSANDRA-14612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14612
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Build
> Environment: All development, build, test, environments.
>Reporter: Albert Baker
>Assignee: Stefan Miklosovic
>Priority: Normal
>  Labels: build, easyfix, security
> Fix For: 3.11.x, 4.x
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an 
> outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to 
> perform a lookup for each dependant .jar to list any/all known 
> vulnerabilities for each jar. This step is needed because a manual MITRE CVE 
> lookup/check on the main component does not include checking for 
> vulnerabilities in components or in dependant libraries.
> OWASP Dependency check : 
> https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most 
> Java build/make types (ant, maven, ivy, gradle).
> Also, add the appropriate command to the nightly build to generate a report 
> of all known vulnerabilities in any/all third party libraries/dependencies 
> that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false 
> clean aggregate
> Generating this report nightly/weekly will help inform the project's 
> development team if any dependant libraries have a reported known 
> vulnerailities. Project teams that keep up with removing vulnerabilities on a 
> weekly basis will help protect businesses that rely on these open source 
> componets.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Assigned] (CASSANDRA-16970) Fix org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition



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

Brandon Williams reassigned CASSANDRA-16970:


Assignee: Brandon Williams

> Fix 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
> -
>
> Key: CASSANDRA-16970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16970
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
>  is 
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/org.apache.cassandra.distributed.test/ClientTombstoneWarningTest/failThresholdSinglePartition_2/]
> {code:java}
> Error Message
>  expected:<0.1=1, /127.0.0.2=1[, /127.0.0.3=1]}> but was:<0.1=1, 
> /127.0.0.2=1[]}>
>  Stacktrace
>  junit.framework.AssertionFailedError: expected:<0.1=1, /127.0.0.2=1[, 
> /127.0.0.3=1]}> but was:<0.1=1, /127.0.0.2=1[]}>
>  at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
>  at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>  at 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThreshold(ClientTombstoneWarningTest.java:227)
>  at 
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition(ClientTombstoneWarningTest.java:180)
>  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4



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

Stefan Miklosovic updated CASSANDRA-9384:
-
Fix Version/s: (was: 2.2.x)
   (was: 2.1.x)
   4.x
   4.0.x

> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16969) Scrub does not detect invalid partition keys



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

Brandon Williams updated CASSANDRA-16969:
-
Status: Patch Available  (was: Open)

> Scrub does not detect invalid partition keys
> 
>
> Key: CASSANDRA-16969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16969
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/sstable
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.12, 4.0.2, 4.1
>
>
> The standalone scrubber [gets the 
> key|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/Scrubber.java#L202]
>  from the file but never validates it, and this will propagate to the new 
> sstable so it will be corrupted when read later.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-12106) Add ability to blocklist / denylist a CQL partition so all requests are ignored

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

Sumanth Pasupuleti edited comment on CASSANDRA-12106 at 9/24/21, 4:47 PM:
--

[~jmckenzie] did a deeper pass, and I have following questions/suggestions
1. It maybe useful to add a documentation file around denylisting partitions
(maybe along the lines of
https://github.com/apache/cassandra/compare/trunk...sumanth-pasupuleti:feature/12106#diff-4264f2ac97017f73e4f6fff8f1cbef3082212b2edc531b57f6e8f064d3ab3e49)
2. -With regards to limiting the amount of memory we would allow the denylisted
partitions to take, we could potentially limit/throw warning based on memory as
an alternate approach to limiting based on number of partition keys. Not a
strong opinion here since we expect operators (and not end users) to use this
feature and it should be safe either ways, given we expect operators to be
informed.-
[EDIT] As I think through further, and as mentioned in CEP, it is probably best
to log a warning if denylisted partitions exceed in either number or memory
usage vs "limiting" them, in order to maintain consistency across all the
nodes' caches in terms of what partitions are denylisted.
3. We could as an alternative, allow configuring denylisting specific
operations (read vs write) per node per partition vs per node - I feel the way
it is currently implemented (per node and not per node per partition) is less
complex and easy to use and we should probably stick to that. We can revisit in
the future if needed.
4. Curious on the choice of exposing consistency level for querying denylisting
partitions. What do you think of a simpler approach doing "local execution" by
each node when querying partitions_denylisted table. The benefit would be it
can make it less complicated in terms of number of options we expose and not
needing to check if we have enough nodes for the chosen consistency level.
5. Curious on why we disable denylisting range reads by default
6. Regarding the datatype for "key" in "system_distributed.partition_denylist",
what do you think of choosing text (vs blob). Advantage would be readability of
the key, and on cache refresh, we would convert it into ByteBuffer
7. What do you think about adding nodetool commands for
a) refreshing denylist
b) adding a partition to denylist
c) removing a partition from denylist

Happy to contribute to any of these, if we decide to make any related changes

was (Author: sumanth.pasupuleti):
[~jmckenzie] did a deeper pass, and I have following questions/suggestions
1. It maybe useful to add a documentation file around denylisting partitions
(maybe along the lines of
https://github.com/apache/cassandra/compare/trunk...sumanth-pasupuleti:feature/12106#diff-4264f2ac97017f73e4f6fff8f1cbef3082212b2edc531b57f6e8f064d3ab3e49)
2. -With regards to limiting the amount of memory we would allow the denylisted
partitions to take, we could potentially limit/throw warning based on memory as
an alternate approach to limiting based on number of partition keys. Not a
strong opinion here since we expect operators (and not end users) to use this
feature and it should be safe either ways, given we expect operators to be
informed.-
[EDIT] As I think through further, and as mentioned in CEP, it is probably best
to log a warning if denylisted partitions exceed in either number or memory
usage vs "limiting" them, in order to maintain consistency across all the
nodes' caches in terms of what partitions are denylisted.
3. We could as an alternative, allow configuring denylisting specific
operations (read vs write) per node per partition vs per node - I feel the way
it is currently implemented (per node and not per node per partition) is less
complex and easy to use and we should probably stick to that. We can revisit in
the future if needed.
4. Curious on the choice of exposing consistency level for querying denylisting
partitions. What do you think of a simpler approach doing "local execution" by
each node when querying partitions_denylisted table. The benefit would be it
can make it less complicated in terms of number of options we expose and not
needing to check if we have enough nodes for the chosen consistency level.
5. Curious on why we disable denylisting range reads by default
6. Regarding the datatype for "key" in "system_distributed.partition_denylist",
what do you think of choosing text (vs blob). Advantage would be readability of
the key, and on cache refresh, we would convert it into ByteBuffer
7. What do you think about adding nodetool commands for
a) refreshing denylist
b) adding a partition to denylist
c) removing a partition from denylist

Happy to contribute to any of these, if decide to make any related changes

> Add ability to blocklist / denylist a CQL partit

[jira] [Commented] (CASSANDRA-16989) Add environment variables to CircleCI config generation script



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

Ekaterina Dimitrova commented on CASSANDRA-16989:
-

Sounds good to me. And in the meanwhile I got one more idea. :D 

We can also add a short comment to confg-2_1.yml around the env vars pointing 
to people where else they need to make updates if they change them so it is not 
a tribal knowledge. 

> Add environment variables to CircleCI config generation script
> --
>
> Key: CASSANDRA-16989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16989
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The purpose of this ticket is adding arguments to the CircleCI config 
> generation script allowing to set the values specific environment variables 
> such as {{DTEST_REPO}} or {{DTEST_BRANCH}} in the generated 
> {{.circleci/config.yml}} file. For example, we could generate a CircleCI 
> config file with MIDRES specifying a dtest repo and branch by running:
> {code}
> generate.sh -m \
>   -e DTEST_REPO=git://github.com/adelapena/cassandra-dtest.git \
>   -e DTEST_BRANCH=CASSANDRA-8272 
> {code}
> Or we could set the test multiplexer for repeating a specific test with 
> HIGHRES:
> {code}
> generate.sh -h \
>   -e REPEATED_UTEST_TARGET=testsome \
>   -e REPEATED_UTEST_CLASS=org.apache.cassandra.cql3.ViewTest \
>   -e REPEATED_UTEST_METHODS=testCompoundPartitionKey,testStaticTable \
>   -e REPEATED_UTEST_COUNT=100
> {code}
> This can be useful on its own so we don't have to manually edit the 
> {{config-2_1.yml}}/{{config.yml}}, and it can also be useful for automation 
> scripts manipulating these files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16989) Add environment variables to CircleCI config generation script

2021-09-24 Thread Jira



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

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

{quote}I had similar thoughts yesterday and maybe we can just add a note - "For 
the right parameters, please, check the list of examples in config-2_1.yml"
{quote}
Good idea, I have added that line to the description of the argument. Regarding 
the list of accepted env vars, I'm slowly becoming a believer in it. The env 
variable injection is quite basic and lacks proper yaml parsing, and the 
replacement is applied to any list item, not only env vars. So one could 
produce a little catastrophe in the config file by, for example, using {{run}} 
as an env var. Indeed this is a dev tool and not something to be used by end 
users, so probably we don't need too much validation. But given that we already 
have the check list, and it is not too large, we could leave it as it is. I 
don't have a strong preference either way.

> Add environment variables to CircleCI config generation script
> --
>
> Key: CASSANDRA-16989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16989
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The purpose of this ticket is adding arguments to the CircleCI config 
> generation script allowing to set the values specific environment variables 
> such as {{DTEST_REPO}} or {{DTEST_BRANCH}} in the generated 
> {{.circleci/config.yml}} file. For example, we could generate a CircleCI 
> config file with MIDRES specifying a dtest repo and branch by running:
> {code}
> generate.sh -m \
>   -e DTEST_REPO=git://github.com/adelapena/cassandra-dtest.git \
>   -e DTEST_BRANCH=CASSANDRA-8272 
> {code}
> Or we could set the test multiplexer for repeating a specific test with 
> HIGHRES:
> {code}
> generate.sh -h \
>   -e REPEATED_UTEST_TARGET=testsome \
>   -e REPEATED_UTEST_CLASS=org.apache.cassandra.cql3.ViewTest \
>   -e REPEATED_UTEST_METHODS=testCompoundPartitionKey,testStaticTable \
>   -e REPEATED_UTEST_COUNT=100
> {code}
> This can be useful on its own so we don't have to manually edit the 
> {{config-2_1.yml}}/{{config.yml}}, and it can also be useful for automation 
> scripts manipulating these files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16986) DROP Table should not recycle active CommitLog segments



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

Caleb Rackliffe commented on CASSANDRA-16986:
-

We could add some comments around the relevant {{CommitLog}} methods to make 
our reasoning for keeping them clear.

> DROP Table should not recycle active CommitLog segments
> ---
>
> Key: CASSANDRA-16986
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16986
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Commit Log
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 4.x
>
>
> Right now, DROP TABLE recycles all active CL segments and explicitly marks 
> intervals as clean for all dropping tables. I believe that this is not 
> necessary.
> Recycling of CL segments was introduced in CASSANDRA-3578. Back then, it was 
> necessary to recycle all active segments because:
> 1. CommitLog reused old segments after they were clean. This is no longer the 
> case, I believe, since CASSANDRA-6809.
> 2. CommitLog segments must have been closed and recycled on {{DROP TABLE}} to 
> avoid resurrecting data if a table with the same name is created. This was an 
> issue because tables didn't have unique ids yet (CASSANDRA-5202).
> Given that {{DROP TABLE}} triggers flush, which in turn cleans CL intervals 
> in Keyspace#unloadCF, I think that we can avoid the call to 
> {{forceRecycleAll}} there.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra-dtest] branch trunk updated: Revise auth CL tests to allow different CL checks

2021-09-24 Thread jmckenzie

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 955bde2  Revise auth CL tests to allow different CL checks
955bde2 is described below

commit 955bde21fae2a9f50fdf040127d77dcfcbcb4723
Author: Josh McKenzie 
AuthorDate: Thu Sep 9 09:56:19 2021 -0400

Revise auth CL tests to allow different CL checks

patch by Josh McKenzie; reviewed by Benjamin Lerer for CASSANDRA-12988
---
 auth_test.py | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/auth_test.py b/auth_test.py
index a85bca5..00f7831 100644
--- a/auth_test.py
+++ b/auth_test.py
@@ -2711,12 +2711,15 @@ class TestAuthRoles(Tester):
 class TestAuthUnavailable(Tester):
 """
 * These tests verify behavior when backends for authentication & 
authorization are unable to pull data from the
-* system_auth keyspace. Failure scenarios are simulated based on the 
assumption that internal queries for role
-* hierarchies and role properties of the "cassandra" super-user get 
CL=QUORUM (other roles get CL=LOCAL_ONE). And so
-* we expect these internal queries to fail when one of two nodes are down 
and system_auth have RF=2. Though the
-* permissions cache is used in these tests, it is always populated by 
permissions derived from the super-user status
-* (all applicable to resource) of the "cassandra" user. The 
network_authorizer is always disabled to make sure the
-* queries utilize the role/permissions cache only.
+* system_auth keyspace. Failure scenarios are simulated based on the 
default CL for auth being LOCAL_QUORUM for reads,
+* EACH_QUORUM for writes. We expect these internal queries to fail when 
one of the two nodes are down and system_auth
+* has RF=2. Though the permissions cache is used in these tests, it is 
always populated by permissions derived from
+* the super-user status (all applicable to resource) of the "cassandra" 
user. The network_authorizer is always disabled
+* to make sure the queries utilize the role/permissions cache only.
+*
+* Notably, the default CL changed from a combination of ONE, LOCAL_ONE, 
and QUORUM <= 4.0 to the above in version 4.1+;
+* we simply relax the constraint on the expected CL found in the error 
message to allow these tests to satisfy both
+* release regimes.
 """
 
 def test_authentication_handle_unavailable(self):
@@ -2750,7 +2753,7 @@ class TestAuthUnavailable(Tester):
 # AuthenticationFailed from server
 assert re.search("code=0100", str(e))
 # Message from server
-assert re.search("Unable to perform authentication:.* Cannot 
achieve consistency level QUORUM", str(e))
+assert re.search("Unable to perform authentication:.* Cannot 
achieve consistency level", str(e))
 
 def test_authentication_through_cache_handle_unavailable(self):
 """
@@ -2789,7 +2792,7 @@ class TestAuthUnavailable(Tester):
 # AuthenticationFailed from server
 assert re.search("code=0100", str(e))
 # Message from server
-assert re.search("Unable to perform authentication:.* Cannot 
achieve consistency level QUORUM", str(e))
+assert re.search("Unable to perform authentication:.* Cannot 
achieve consistency level", str(e))
 
 @since('4.0')
 def test_authentication_from_cache_while_unavailable(self):
@@ -2880,7 +2883,7 @@ class TestAuthUnavailable(Tester):
 
 node1.stop()
 
-assert_exception(cassandra, "SELECT * from ks.cf", matching="Unable to 
perform authorization of super-user permission: Cannot achieve consistency 
level QUORUM", expected=Unauthorized)
+assert_exception(cassandra, "SELECT * from ks.cf", matching="Unable to 
perform authorization of super-user permission: Cannot achieve consistency 
level", expected=Unauthorized)
 
 def test_authorization_through_cache_handle_unavailable(self):
 """
@@ -2914,7 +2917,7 @@ class TestAuthUnavailable(Tester):
 # Wait for cache to timeout
 time.sleep(1)
 
-assert_exception(cassandra, "SELECT * from ks.cf", matching="Unable to 
perform authorization of super-user permission: Cannot achieve consistency 
level QUORUM", expected=Unauthorized)
+assert_exception(cassandra, "SELECT * from ks.cf", matching="Unable to 
perform authorization of super-user permission: Cannot achieve consistency 
level", expected=Unauthorized)
 
 def test_authorization_from_cache_while_unavailable(self):
 """

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

[jira] [Updated] (CASSANDRA-16606) Update libthrift jar to at least 0.9.3-1, investigate 0.14.0



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

Stefan Miklosovic updated CASSANDRA-16606:
--
Resolution: Won't Fix
Status: Resolved  (was: Open)

> Update libthrift jar to at least 0.9.3-1, investigate 0.14.0
> 
>
> Key: CASSANDRA-16606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16606
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Thrift
>Reporter: Mark Denihan
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> Cassandra 3.x and 2.x uses libthrift 0.9.2, which has a number of 
> vulnerabilities associated with it which are applicable to Cassandra;
> CVE-2015-3254
> CVE-2018-1320 (CASSANDRA-15424)
> CVE-2019-0205 (CASSANDRA-15420)
> Updating to 0.9.3-1 will mitigate these, however that branch suffers 
> CVE-2020-13949. 
> To mitigate risks from using out of date libthrift versions, Cassandra should 
> be updated to use 0.14.0



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15420) CVE-2019-0205(Apache Thrift all versions up to and including 0.12.0) on version Cassendra 3.11.4



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

Stefan Miklosovic updated CASSANDRA-15420:
--
Resolution: Won't Fix
Status: Resolved  (was: Open)

> CVE-2019-0205(Apache Thrift all versions up to and including 0.12.0) on 
> version Cassendra 3.11.4
> 
>
> Key: CASSANDRA-15420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15420
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Thrift
>Reporter: Abhishek Singh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> *Description :**Description :* *Severity :* CVE CVSS 3: 7.5Sonatype CVSS 3: 
> 7.5
>  
>  *Weakness :* CVE CWE: 835
>  
>  *Source :* National Vulnerability Database
>  
>  *Categories :* Data 
>  *Description from CVE :* In Apache Thrift all versions up to and including 
> 0.12.0, a server or client may run into an endless loop when feed with 
> specific input data. Because the issue had already been partially fixed in 
> version 0.11.0, depending on the installed version it affects only certain 
> language bindings.
>  
>  *Explanation :* This issue has undergone the Sonatype Fast-Track process. 
> For more information, please see the Sonatype Knowledge Base Guide. 
>  *Detection :* The application is vulnerable by using this component. 
>  *Recommendation :* We recommend upgrading to a version of this component 
> that is not vulnerable to this specific issue.Note: If this component is 
> included as a bundled/transitive dependency of another component, there may 
> not be an upgrade path. In this instance, we recommend contacting the 
> maintainers who included the vulnerable package. Alternatively, we recommend 
> investigating alternative components or a potential mitigating control. 
>  *Advisories :* Project: 
> http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mâ€¦
>  
>  *CVSS Details :* CVE CVSS 3: 7.5CVSS Vector: 
> CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
> *Occurences (Paths) :* ["apache-cassandra.zip" ; "apache-cassandra.zip"]
> *CVE :* CVE-2019-0205
> *URL :* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0205
> *Remediation :* This component does not have any non-vulnerable Version. 
> Please contact the vendor to get this vulnerability fixed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15424) CVE-2018-1320 (The libthrift component is vulnerable to Improper Access Control)



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

Stefan Miklosovic updated CASSANDRA-15424:
--
Resolution: Won't Fix
Status: Resolved  (was: Open)

> CVE-2018-1320 (The libthrift component is vulnerable to Improper Access 
> Control)
> 
>
> Key: CASSANDRA-15424
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15424
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Thrift
>Reporter: Abhishek Singh
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> *Description :**Description :* *Severity :* CVE CVSS 3.0: 7.5Sonatype CVSS 
> 3.0: 8.2
>  
>  *Weakness :* CVE CWE: 20
>  
>  *Source :* National Vulnerability Database
>  
>  *Categories :* Data 
>  *Description from CVE :* Apache Thrift Java client library versions 0.5.0 
> through 0.11.0 can bypass SASL negotiation isComplete validation in the 
> org.apache.thrift.transport.TSaslTransport class. An assert used to determine 
> if the SASL handshake had successfully completed could be disabled in 
> production settings making the validation incomplete.
>  
>  *Explanation :* The libthrift component is vulnerable to Improper Access 
> Control. The open() method of the TSaslTransport class incorrectly uses an 
> assertion to validate whether or not the SASL handshake has successfully 
> completed. In some cases, such as production builds, the assertion 
> functionality can be disabled rendering the validation incomplete. In such a 
> case, an attacker can exploit this by being able to login without actually 
> successfully completing the SASL handshake. 
>  *Detection :* The application is vulnerable by using this component. 
>  *Recommendation :* We recommend upgrading to a version of this component 
> that is not vulnerable to this specific issue. 
>  *Root Cause :* Cassandra-2.2.5.nupkgTSaslTransport.class : [0.5.0, 0.12.0)
>  
>  *Advisories :* Project: 
> https://lists.apache.org/thread.html/da5234b5e78f1c99190407f...
>  
>  *CVSS Details :* CVE CVSS 3.0: 7.5
> *Occurences (Paths) :* [" apache-cassandra.zip/bin/cassandra.in.bat" ; " 
> apache-cassandra.zip/bin/cassandra.in.sh" ; " 
> apache-cassandra.zip/bin/cqlsh.bat" ; " 
> apache-cassandra.zip/bin/debug-cql.bat" ; " 
> apache-cassandra.zip/bin/source-conf.ps1" ; " 
> apache-cassandra.zip/bin/sstableloader.bat" ; " 
> apache-cassandra.zip/bin/sstablescrub.bat" ; " 
> apache-cassandra.zip/bin/sstableupgrade.bat" ; " 
> apache-cassandra.zip/bin/sstableverify.bat" ; " 
> apache-cassandra.zip/bin/stop-server" ; " 
> apache-cassandra.zip/bin/stop-server.bat" ; " 
> apache-cassandra.zip/bin/stop-server.ps1" ; " 
> apache-cassandra.zip/conf/README.txt" ; " 
> apache-cassandra.zip/conf/cassandra-rackdc.properties" ; " 
> apache-cassandra.zip/conf/cassandra-topology.properties" ; " 
> apache-cassandra.zip/conf/commitlog_archiving.properties" ; " 
> apache-cassandra.zip/conf/triggers/README.txt" ; " 
> apache-cassandra.zip/lib/ST4-4.0.8.jar" ; " 
> apache-cassandra.zip/lib/airline-0.6.jar" ; " 
> apache-cassandra.zip/lib/antlr-runtime-3.5.2.jar" ; " 
> apache-cassandra.zip/lib/commons-cli-1.1.jar" ; " 
> apache-cassandra.zip/lib/commons-lang3-3.1.jar" ; " 
> apache-cassandra.zip/lib/commons-math3-3.2.jar" ; " 
> apache-cassandra.zip/lib/compress-lzf-0.8.4.jar" ; " 
> apache-cassandra.zip/lib/concurrentlinkedhashmap-lru-1.4.jar" ; " 
> apache-cassandra.zip/lib/disruptor-3.0.1.jar" ; " 
> apache-cassandra.zip/lib/ecj-4.4.2.jar" ; " 
> apache-cassandra.zip/lib/futures-2.1.6-py2.py3-none-any.zip" ; " 
> apache-cassandra.zip/lib/high-scale-lib-1.0.6.jar" ; " 
> apache-cassandra.zip/lib/jamm-0.3.0.jar" ; " 
> apache-cassandra.zip/lib/javax.inject.jar" ; " 
> apache-cassandra.zip/lib/jbcrypt-0.3m.jar" ; " 
> apache-cassandra.zip/lib/jcl-over-slf4j-1.7.7.jar" ; " 
> apache-cassandra.zip/lib/joda-time-2.4.jar" ; " 
> apache-cassandra.zip/lib/json-simple-1.1.jar" ; " 
> apache-cassandra.zip/lib/libthrift-0.9.2.jar" ; " 
> apache-cassandra.zip/lib/licenses/ST4-4.0.8.txt" ; " 
> apache-cassandra.zip/lib/licenses/antlr-runtime-3.5.2.txt" ; " 
> apache-cassandra.zip/lib/licenses/compress-lzf-0.8.4.txt" ; " 
> apache-cassandra.zip/lib/licenses/concurrent-trees-2.4.0.txt" ; " 
> apache-cassandra.zip/lib/licenses/ecj-4.4.2.txt" ; " 
> apache-cassandra.zip/lib/licenses/futures-2.1.6.txt" ; " 
> apache-cassandra.zip/lib/licenses/high-scale-lib-1.0.6.txt" ; " 
> apache-cassandra.zip/lib/licenses/jbcrypt-0.3m.txt" ; " 
> apache-cassandra.zip/lib/licenses/jcl-over-slf4j-1.7.7.txt" ; " 
> apache-cassandra.zip/lib/licenses/jna-4.2.2.txt" ; " 
> apache-cassandra.zip/lib/licenses/jstackjunit-0.0.1.txt" ; " 
> apache-cassandra.zip/lib/licenses/log4j-over-slf4j-1.7.7.txt" ; " 
> apache-cassandra.zip/lib/licenses/

[jira] [Assigned] (CASSANDRA-16606) Update libthrift jar to at least 0.9.3-1, investigate 0.14.0



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

Stefan Miklosovic reassigned CASSANDRA-16606:
-

Assignee: Stefan Miklosovic

> Update libthrift jar to at least 0.9.3-1, investigate 0.14.0
> 
>
> Key: CASSANDRA-16606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16606
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Thrift
>Reporter: Mark Denihan
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> Cassandra 3.x and 2.x uses libthrift 0.9.2, which has a number of 
> vulnerabilities associated with it which are applicable to Cassandra;
> CVE-2015-3254
> CVE-2018-1320 (CASSANDRA-15424)
> CVE-2019-0205 (CASSANDRA-15420)
> Updating to 0.9.3-1 will mitigate these, however that branch suffers 
> CVE-2020-13949. 
> To mitigate risks from using out of date libthrift versions, Cassandra should 
> be updated to use 0.14.0



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16986) DROP Table should not recycle active CommitLog segments



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

Brandon Williams commented on CASSANDRA-16986:
--

Those are excellent points against this, imo.  Users can specify the ID and 
defeat this.

> DROP Table should not recycle active CommitLog segments
> ---
>
> Key: CASSANDRA-16986
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16986
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Commit Log
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 4.x
>
>
> Right now, DROP TABLE recycles all active CL segments and explicitly marks 
> intervals as clean for all dropping tables. I believe that this is not 
> necessary.
> Recycling of CL segments was introduced in CASSANDRA-3578. Back then, it was 
> necessary to recycle all active segments because:
> 1. CommitLog reused old segments after they were clean. This is no longer the 
> case, I believe, since CASSANDRA-6809.
> 2. CommitLog segments must have been closed and recycled on {{DROP TABLE}} to 
> avoid resurrecting data if a table with the same name is created. This was an 
> issue because tables didn't have unique ids yet (CASSANDRA-5202).
> Given that {{DROP TABLE}} triggers flush, which in turn cleans CL intervals 
> in Keyspace#unloadCF, I think that we can avoid the call to 
> {{forceRecycleAll}} there.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Brandon Williams commented on CASSANDRA-16973:
--

+1

> Fix 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
> 
>
> Key: CASSANDRA-16973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
>  fails in 
> [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
> h3.  
> {code:java}
> Stacktrace
> junit.framework.AssertionFailedError at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
>  at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> Standard Output
> Completed 0K batches with 0.0M events Running for 120s with load multiplier 
> 0.5
> Standard Error
> SLF4J: The following set of substitute loggers may have been accessed SLF4J: 
> during the initialization phase. Logging calls during this SLF4J: phase were 
> not honored. However, subsequent logging calls to these SLF4J: loggers will 
> work as normally expected. SLF4J: See also
> http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.cassandra.LogbackStatusListener
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16986) DROP Table should not recycle active CommitLog segments



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

Caleb Rackliffe commented on CASSANDRA-16986:
-

What worries me is the assumption that we'll never reuse a table ID, even with 
the current ID generation scheme.

1.) We can create tables using {{CREATE TABLE WITH ID}}, providing the same ID 
as a previously dropped table. (CASSANDRA-9179)
2.) {{DESCRIBE TABLE}} can produce output with {{WITH ID}} that could be 
unsafely replayed. (CASSANDRA-14825)
3.) {{TableId.forSystemTable()}} is deterministic. (This is only a problem if 
system tables are dropped, I guess.)

> DROP Table should not recycle active CommitLog segments
> ---
>
> Key: CASSANDRA-16986
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16986
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Commit Log
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 4.x
>
>
> Right now, DROP TABLE recycles all active CL segments and explicitly marks 
> intervals as clean for all dropping tables. I believe that this is not 
> necessary.
> Recycling of CL segments was introduced in CASSANDRA-3578. Back then, it was 
> necessary to recycle all active segments because:
> 1. CommitLog reused old segments after they were clean. This is no longer the 
> case, I believe, since CASSANDRA-6809.
> 2. CommitLog segments must have been closed and recycled on {{DROP TABLE}} to 
> avoid resurrecting data if a table with the same name is created. This was an 
> issue because tables didn't have unique ids yet (CASSANDRA-5202).
> Given that {{DROP TABLE}} triggers flush, which in turn cleans CL intervals 
> in Keyspace#unloadCF, I think that we can avoid the call to 
> {{forceRecycleAll}} there.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-12988) make the consistency level for user-level auth reads and writes configurable



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

Josh McKenzie updated CASSANDRA-12988:
--
  Fix Version/s: (was: 4.x)
 4.1
Source Control Link: 
https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=9f15ec6de11c57d5fff02fe08639b647fc0749e8
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

One minor change on commit - we'd originally performed the 
{{CassandraRoleManager.getAllRoles()}} call at CL.QUORUM deliberately and the 
PR had flipped that to AuthProperties configured level. I reverted that to 
CL.QUORUM, javadocced the method so it's clear in the future why it has what it 
has, and cleared that w/Benjamin on slack.

Going to push dtest pr shortly.

> make the consistency level for user-level auth reads and writes configurable
> 
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.1
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to 
> make it configurable, with the default still being {{LOCAL_ONE}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution



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

Ekaterina Dimitrova commented on CASSANDRA-16973:
-

I would like to suggest to add the @Ignore and open a follow up ticket for 
writing a new test and whoever has appetite can look into that? WDYT?

> Fix 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
> 
>
> Key: CASSANDRA-16973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
>  fails in 
> [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
> h3.  
> {code:java}
> Stacktrace
> junit.framework.AssertionFailedError at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
>  at 
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> Standard Output
> Completed 0K batches with 0.0M events Running for 120s with load multiplier 
> 0.5
> Standard Error
> SLF4J: The following set of substitute loggers may have been accessed SLF4J: 
> during the initialization phase. Logging calls during this SLF4J: phase were 
> not honored. However, subsequent logging calls to these SLF4J: loggers will 
> work as normally expected. SLF4J: See also
> http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.cassandra.LogbackStatusListener
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-12988) make the consistency level for user-level auth reads and writes configurable



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

Josh McKenzie updated CASSANDRA-12988:
--
Status: Ready to Commit  (was: Review In Progress)

> make the consistency level for user-level auth reads and writes configurable
> 
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to 
> make it configurable, with the default still being {{LOCAL_ONE}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra] branch trunk updated: Evaluate consistency levels of auth reads

2021-09-24 Thread jmckenzie

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 9f15ec6  Evaluate consistency levels of auth reads
9f15ec6 is described below

commit 9f15ec6de11c57d5fff02fe08639b647fc0749e8
Author: Josh McKenzie 
AuthorDate: Thu Sep 2 13:58:16 2021 -0400

Evaluate consistency levels of auth reads

Patch by Jason Brown; reviewed by Matthew Byrd, Sankalp Kohli, and Benjamin 
Lerer for CASSANDRA-12988

Co-authored by Jason Brown (jasedbr...@gmail.com)
Co-authored by Josh McKenzie (jmcken...@apache.org)
---
 CHANGES.txt|  1 +
 NEWS.txt   |  3 +
 conf/cassandra.yaml|  4 ++
 .../org/apache/cassandra/auth/AuthProperties.java  | 70 ++
 .../cassandra/auth/AuthPropertiesMXBean.java   | 29 +
 .../apache/cassandra/auth/CassandraAuthorizer.java | 38 
 .../cassandra/auth/CassandraNetworkAuthorizer.java |  6 +-
 .../cassandra/auth/CassandraRoleManager.java   | 58 +++---
 .../cassandra/auth/PasswordAuthenticator.java  |  4 +-
 src/java/org/apache/cassandra/config/Config.java   |  5 ++
 .../cassandra/config/DatabaseDescriptor.java   | 20 +++
 .../apache/cassandra/auth/AuthPropertiesTest.java  | 53 
 .../org/apache/cassandra/auth/AuthTestUtils.java   |  2 +-
 .../auth/CassandraNetworkAuthorizerTest.java   |  8 +--
 test/unit/org/apache/cassandra/auth/RolesTest.java | 21 +++
 15 files changed, 279 insertions(+), 43 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index ed95f95..b89bb31 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.1
+ * Allow configuration of consistency levels on auth operations 
(CASSANDRA-12988)
  * Add number of sstables in a compaction to compactionstats output 
(CASSANDRA-16844)
  * Upgrade Caffeine to 2.9.2 (CASSANDRA-15153)
  * Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation 
allows it (CASSANDRA-16806)
diff --git a/NEWS.txt b/NEWS.txt
index 443a5c4..77a3e1b 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -140,6 +140,9 @@ New features
   See CASSANDRA-10190 for details.
 - Support for server side DESCRIBE statements has been added. See 
CASSANDRA-14825
 - It is now possible to rate limit snapshot creation/clearing. See 
CASSANDRA-13019
+- Authentication reads and writes have been changed from a mix of ONE, 
LOCAL_ONE, and QUORUM
+  to LOCAL_QUORUM on reads and EACH_QUORUM on writes. This is configurable 
via cassandra.yaml with
+  auth_read_consistency_level and auth_write_consistency_level 
respectively. See CASSANDRA-12988.
 
 Upgrading
 -
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 25f6eb1..a868a4a 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -1426,6 +1426,10 @@ report_unconfirmed_repaired_data_mismatches: false
 # table_count_warn_threshold: 150
 # keyspace_count_warn_threshold: 40
 
+# configure the read and write consistency levels for modifications to auth 
tables
+# auth_read_consistency_level: LOCAL_QUORUM
+# auth_write_consistency_level: EACH_QUORUM
+
 #
 # EXPERIMENTAL FEATURES #
 #
diff --git a/src/java/org/apache/cassandra/auth/AuthProperties.java 
b/src/java/org/apache/cassandra/auth/AuthProperties.java
new file mode 100644
index 000..036cbe2
--- /dev/null
+++ b/src/java/org/apache/cassandra/auth/AuthProperties.java
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.auth;
+
+import javax.management.ObjectName;
+
+import org.apache.cassandra.config.DatabaseDescriptor;
+import org.apache.cassandra.db.ConsistencyLevel;
+import org.apache.cassandra.utils.MBeanWrapper;
+
+public class AuthProperties implements AuthPropertiesMXBean
+{
+public static AuthProperties instance = new 
AuthProperties(DatabaseDescriptor.getAuthWriteConsistencyLevel(),
+   
Databa

[jira] [Updated] (CASSANDRA-16606) Update libthrift jar to at least 0.9.3-1, investigate 0.14.0



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

Stefan Miklosovic updated CASSANDRA-16606:
--
Fix Version/s: (was: 2.2.x)

> Update libthrift jar to at least 0.9.3-1, investigate 0.14.0
> 
>
> Key: CASSANDRA-16606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16606
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Thrift
>Reporter: Mark Denihan
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> Cassandra 3.x and 2.x uses libthrift 0.9.2, which has a number of 
> vulnerabilities associated with it which are applicable to Cassandra;
> CVE-2015-3254
> CVE-2018-1320 (CASSANDRA-15424)
> CVE-2019-0205 (CASSANDRA-15420)
> Updating to 0.9.3-1 will mitigate these, however that branch suffers 
> CVE-2020-13949. 
> To mitigate risks from using out of date libthrift versions, Cassandra should 
> be updated to use 0.14.0



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-16989) Add environment variables to CircleCI config generation script



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

Ekaterina Dimitrova edited comment on CASSANDRA-16989 at 9/24/21, 3:10 PM:
---

{quote}I still have to update the readme with these last changes, I'll do it if 
they look good to everyone.
{quote}
+1 on the proposed changes


was (Author: e.dimitrova):
{quote}I still have to update the readme with these last changes, I'll do it if 
they look good to everyone.
{quote}
+1

> Add environment variables to CircleCI config generation script
> --
>
> Key: CASSANDRA-16989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16989
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The purpose of this ticket is adding arguments to the CircleCI config 
> generation script allowing to set the values specific environment variables 
> such as {{DTEST_REPO}} or {{DTEST_BRANCH}} in the generated 
> {{.circleci/config.yml}} file. For example, we could generate a CircleCI 
> config file with MIDRES specifying a dtest repo and branch by running:
> {code}
> generate.sh -m \
>   -e DTEST_REPO=git://github.com/adelapena/cassandra-dtest.git \
>   -e DTEST_BRANCH=CASSANDRA-8272 
> {code}
> Or we could set the test multiplexer for repeating a specific test with 
> HIGHRES:
> {code}
> generate.sh -h \
>   -e REPEATED_UTEST_TARGET=testsome \
>   -e REPEATED_UTEST_CLASS=org.apache.cassandra.cql3.ViewTest \
>   -e REPEATED_UTEST_METHODS=testCompoundPartitionKey,testStaticTable \
>   -e REPEATED_UTEST_COUNT=100
> {code}
> This can be useful on its own so we don't have to manually edit the 
> {{config-2_1.yml}}/{{config.yml}}, and it can also be useful for automation 
> scripts manipulating these files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16989) Add environment variables to CircleCI config generation script



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

Ekaterina Dimitrova commented on CASSANDRA-16989:
-

{quote}I still have to update the readme with these last changes, I'll do it if 
they look good to everyone.
{quote}
+1

> Add environment variables to CircleCI config generation script
> --
>
> Key: CASSANDRA-16989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16989
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The purpose of this ticket is adding arguments to the CircleCI config 
> generation script allowing to set the values specific environment variables 
> such as {{DTEST_REPO}} or {{DTEST_BRANCH}} in the generated 
> {{.circleci/config.yml}} file. For example, we could generate a CircleCI 
> config file with MIDRES specifying a dtest repo and branch by running:
> {code}
> generate.sh -m \
>   -e DTEST_REPO=git://github.com/adelapena/cassandra-dtest.git \
>   -e DTEST_BRANCH=CASSANDRA-8272 
> {code}
> Or we could set the test multiplexer for repeating a specific test with 
> HIGHRES:
> {code}
> generate.sh -h \
>   -e REPEATED_UTEST_TARGET=testsome \
>   -e REPEATED_UTEST_CLASS=org.apache.cassandra.cql3.ViewTest \
>   -e REPEATED_UTEST_METHODS=testCompoundPartitionKey,testStaticTable \
>   -e REPEATED_UTEST_COUNT=100
> {code}
> This can be useful on its own so we don't have to manually edit the 
> {{config-2_1.yml}}/{{config.yml}}, and it can also be useful for automation 
> scripts manipulating these files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16606) Update libthrift jar to at least 0.9.3-1, investigate 0.14.0



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

Stefan Miklosovic updated CASSANDRA-16606:
--
Summary: Update libthrift jar to at least 0.9.3-1, investigate 0.14.0  
(was: Update libthrift jar to at least 0.14.0)

> Update libthrift jar to at least 0.9.3-1, investigate 0.14.0
> 
>
> Key: CASSANDRA-16606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16606
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Thrift
>Reporter: Mark Denihan
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> Cassandra 3.x and 2.x uses libthrift 0.9.2, which has a number of 
> vulnerabilities associated with it which are applicable to Cassandra;
> CVE-2015-3254
> CVE-2018-1320 (CASSANDRA-15424)
> CVE-2019-0205 (CASSANDRA-15420)
> Updating to 0.9.3-1 will mitigate these, however that branch suffers 
> CVE-2020-13949. 
> To mitigate risks from using out of date libthrift versions, Cassandra should 
> be updated to use 0.14.0



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16989) Add environment variables to CircleCI config generation script



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

Ekaterina Dimitrova commented on CASSANDRA-16989:
-

{quote}I don't know how much we want to complicate parsing for a dev tool. I 
guess we can add that list of allowed vars, with the small drawback of having 
to maintain that list updated. I'll give it a go.
{quote}
I had similar thoughts yesterday and maybe we can just add a note - "For the 
right parameters, please, check the list of examples in _config-2_1.yml"_

Thus we don't have to maintain a few places. WDYT? 

> Add environment variables to CircleCI config generation script
> --
>
> Key: CASSANDRA-16989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16989
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The purpose of this ticket is adding arguments to the CircleCI config 
> generation script allowing to set the values specific environment variables 
> such as {{DTEST_REPO}} or {{DTEST_BRANCH}} in the generated 
> {{.circleci/config.yml}} file. For example, we could generate a CircleCI 
> config file with MIDRES specifying a dtest repo and branch by running:
> {code}
> generate.sh -m \
>   -e DTEST_REPO=git://github.com/adelapena/cassandra-dtest.git \
>   -e DTEST_BRANCH=CASSANDRA-8272 
> {code}
> Or we could set the test multiplexer for repeating a specific test with 
> HIGHRES:
> {code}
> generate.sh -h \
>   -e REPEATED_UTEST_TARGET=testsome \
>   -e REPEATED_UTEST_CLASS=org.apache.cassandra.cql3.ViewTest \
>   -e REPEATED_UTEST_METHODS=testCompoundPartitionKey,testStaticTable \
>   -e REPEATED_UTEST_COUNT=100
> {code}
> This can be useful on its own so we don't have to manually edit the 
> {{config-2_1.yml}}/{{config.yml}}, and it can also be useful for automation 
> scripts manipulating these files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16606) Update libthrift jar to at least 0.14.0



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

Stefan Miklosovic commented on CASSANDRA-16606:
---

I think we can update this to 0.9.3-1 at least. anything after it breaks the 
code and I do not have bandwidth to fix that. If you prepare a patch for 
0.14.0, I do not mind to apply that for 3.0.x and 3.11.x

> Update libthrift jar to at least 0.14.0
> ---
>
> Key: CASSANDRA-16606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16606
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Thrift
>Reporter: Mark Denihan
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> Cassandra 3.x and 2.x uses libthrift 0.9.2, which has a number of 
> vulnerabilities associated with it which are applicable to Cassandra;
> CVE-2015-3254
> CVE-2018-1320 (CASSANDRA-15424)
> CVE-2019-0205 (CASSANDRA-15420)
> Updating to 0.9.3-1 will mitigate these, however that branch suffers 
> CVE-2020-13949. 
> To mitigate risks from using out of date libthrift versions, Cassandra should 
> be updated to use 0.14.0



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Assigned] (CASSANDRA-12106) Add ability to blocklist / denylist a CQL partition so all requests are ignored



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

Josh McKenzie reassigned CASSANDRA-12106:
-

Assignee: Josh McKenzie  (was: Sumanth Pasupuleti)

> Add ability to blocklist / denylist a CQL partition so all requests are 
> ignored
> ---
>
> Key: CASSANDRA-12106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12106
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Local Write-Read Paths, Local/Config
>Reporter: Geoffrey Yu
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
> Attachments: 12106-trunk.txt
>
>
> Sometimes reads/writes to a given partition may cause problems due to the 
> data present. It would be useful to have a manual way to blocklist / denylist
>  such partitions so all read and write requests to them are rejected.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Assigned] (CASSANDRA-15420) CVE-2019-0205(Apache Thrift all versions up to and including 0.12.0) on version Cassendra 3.11.4



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

Stefan Miklosovic reassigned CASSANDRA-15420:
-

Assignee: Stefan Miklosovic

> CVE-2019-0205(Apache Thrift all versions up to and including 0.12.0) on 
> version Cassendra 3.11.4
> 
>
> Key: CASSANDRA-15420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15420
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Thrift
>Reporter: Abhishek Singh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> *Description :**Description :* *Severity :* CVE CVSS 3: 7.5Sonatype CVSS 3: 
> 7.5
>  
>  *Weakness :* CVE CWE: 835
>  
>  *Source :* National Vulnerability Database
>  
>  *Categories :* Data 
>  *Description from CVE :* In Apache Thrift all versions up to and including 
> 0.12.0, a server or client may run into an endless loop when feed with 
> specific input data. Because the issue had already been partially fixed in 
> version 0.11.0, depending on the installed version it affects only certain 
> language bindings.
>  
>  *Explanation :* This issue has undergone the Sonatype Fast-Track process. 
> For more information, please see the Sonatype Knowledge Base Guide. 
>  *Detection :* The application is vulnerable by using this component. 
>  *Recommendation :* We recommend upgrading to a version of this component 
> that is not vulnerable to this specific issue.Note: If this component is 
> included as a bundled/transitive dependency of another component, there may 
> not be an upgrade path. In this instance, we recommend contacting the 
> maintainers who included the vulnerable package. Alternatively, we recommend 
> investigating alternative components or a potential mitigating control. 
>  *Advisories :* Project: 
> http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mâ€¦
>  
>  *CVSS Details :* CVE CVSS 3: 7.5CVSS Vector: 
> CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
> *Occurences (Paths) :* ["apache-cassandra.zip" ; "apache-cassandra.zip"]
> *CVE :* CVE-2019-0205
> *URL :* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0205
> *Remediation :* This component does not have any non-vulnerable Version. 
> Please contact the vendor to get this vulnerability fixed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15420) CVE-2019-0205(Apache Thrift all versions up to and including 0.12.0) on version Cassendra 3.11.4



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

Stefan Miklosovic updated CASSANDRA-15420:
--
Fix Version/s: (was: 2.2.x)

> CVE-2019-0205(Apache Thrift all versions up to and including 0.12.0) on 
> version Cassendra 3.11.4
> 
>
> Key: CASSANDRA-15420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15420
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Thrift
>Reporter: Abhishek Singh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> *Description :**Description :* *Severity :* CVE CVSS 3: 7.5Sonatype CVSS 3: 
> 7.5
>  
>  *Weakness :* CVE CWE: 835
>  
>  *Source :* National Vulnerability Database
>  
>  *Categories :* Data 
>  *Description from CVE :* In Apache Thrift all versions up to and including 
> 0.12.0, a server or client may run into an endless loop when feed with 
> specific input data. Because the issue had already been partially fixed in 
> version 0.11.0, depending on the installed version it affects only certain 
> language bindings.
>  
>  *Explanation :* This issue has undergone the Sonatype Fast-Track process. 
> For more information, please see the Sonatype Knowledge Base Guide. 
>  *Detection :* The application is vulnerable by using this component. 
>  *Recommendation :* We recommend upgrading to a version of this component 
> that is not vulnerable to this specific issue.Note: If this component is 
> included as a bundled/transitive dependency of another component, there may 
> not be an upgrade path. In this instance, we recommend contacting the 
> maintainers who included the vulnerable package. Alternatively, we recommend 
> investigating alternative components or a potential mitigating control. 
>  *Advisories :* Project: 
> http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mâ€¦
>  
>  *CVSS Details :* CVE CVSS 3: 7.5CVSS Vector: 
> CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
> *Occurences (Paths) :* ["apache-cassandra.zip" ; "apache-cassandra.zip"]
> *CVE :* CVE-2019-0205
> *URL :* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0205
> *Remediation :* This component does not have any non-vulnerable Version. 
> Please contact the vendor to get this vulnerability fixed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15856) Security vulnerabilities with dependency jars of Cassandra 3.11.6



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

Stefan Miklosovic updated CASSANDRA-15856:
--
Resolution: Won't Fix
Status: Resolved  (was: Triage Needed)

> Security vulnerabilities with dependency jars  of Cassandra 3.11.6
> --
>
> Key: CASSANDRA-15856
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15856
> Project: Cassandra
>  Issue Type: Task
>Reporter: Kshitiz Saxena
>Priority: Normal
> Fix For: 3.11.x
>
>
> The latest release of Cassandra 3.11.6 has few dependency jars which have 
> some security vulnerabilities.
>  
> Apache Thrift (org.apache.thrift:libthrift:0.9.2) has below mentioned 
> security vulnerabilities reported
> |+[https://nvd.nist.gov/vuln/detail/CVE-2016-5397]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2018-1320]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-0205]+|
>  
> Netty Project (io.netty:netty-all:4.0.44.Final) has below mentioned security 
> vulnerabilities reported
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-16869]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20444]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20445]+|
>  
> Is there a plan to upgrade these jars in any upcoming release?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15856) Security vulnerabilities with dependency jars of Cassandra 3.11.6



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

Stefan Miklosovic commented on CASSANDRA-15856:
---

CVE-2019-0205 is addressed here 
https://issues.apache.org/jira/browse/CASSANDRA-15420

> Security vulnerabilities with dependency jars  of Cassandra 3.11.6
> --
>
> Key: CASSANDRA-15856
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15856
> Project: Cassandra
>  Issue Type: Task
>Reporter: Kshitiz Saxena
>Priority: Normal
> Fix For: 3.11.x
>
>
> The latest release of Cassandra 3.11.6 has few dependency jars which have 
> some security vulnerabilities.
>  
> Apache Thrift (org.apache.thrift:libthrift:0.9.2) has below mentioned 
> security vulnerabilities reported
> |+[https://nvd.nist.gov/vuln/detail/CVE-2016-5397]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2018-1320]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-0205]+|
>  
> Netty Project (io.netty:netty-all:4.0.44.Final) has below mentioned security 
> vulnerabilities reported
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-16869]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20444]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20445]+|
>  
> Is there a plan to upgrade these jars in any upcoming release?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15856) Security vulnerabilities with dependency jars of Cassandra 3.11.6



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

Stefan Miklosovic commented on CASSANDRA-15856:
---

CVE-2018-1320 is addressed here 
https://issues.apache.org/jira/browse/CASSANDRA-15424

> Security vulnerabilities with dependency jars  of Cassandra 3.11.6
> --
>
> Key: CASSANDRA-15856
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15856
> Project: Cassandra
>  Issue Type: Task
>Reporter: Kshitiz Saxena
>Priority: Normal
> Fix For: 3.11.x
>
>
> The latest release of Cassandra 3.11.6 has few dependency jars which have 
> some security vulnerabilities.
>  
> Apache Thrift (org.apache.thrift:libthrift:0.9.2) has below mentioned 
> security vulnerabilities reported
> |+[https://nvd.nist.gov/vuln/detail/CVE-2016-5397]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2018-1320]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-0205]+|
>  
> Netty Project (io.netty:netty-all:4.0.44.Final) has below mentioned security 
> vulnerabilities reported
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-16869]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20444]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20445]+|
>  
> Is there a plan to upgrade these jars in any upcoming release?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16989) Add environment variables to CircleCI config generation script

2021-09-24 Thread Jira



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

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

POSIX-compliant it is.

I have also added a {{-a}} flag to generate all the files, so with no flags it 
prints the help. As a bonus, if you pass env vars with {{-e}} and without any 
of the {{-l}}/{{-m}}/{{-h}}/{{-a}} flags it sets those env vars without calling 
the {{circleci}} tool.

I still have to update the readme with these last changes, I'll do it if they 
look good to everyone.

> Add environment variables to CircleCI config generation script
> --
>
> Key: CASSANDRA-16989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16989
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> The purpose of this ticket is adding arguments to the CircleCI config 
> generation script allowing to set the values specific environment variables 
> such as {{DTEST_REPO}} or {{DTEST_BRANCH}} in the generated 
> {{.circleci/config.yml}} file. For example, we could generate a CircleCI 
> config file with MIDRES specifying a dtest repo and branch by running:
> {code}
> generate.sh -m \
>   -e DTEST_REPO=git://github.com/adelapena/cassandra-dtest.git \
>   -e DTEST_BRANCH=CASSANDRA-8272 
> {code}
> Or we could set the test multiplexer for repeating a specific test with 
> HIGHRES:
> {code}
> generate.sh -h \
>   -e REPEATED_UTEST_TARGET=testsome \
>   -e REPEATED_UTEST_CLASS=org.apache.cassandra.cql3.ViewTest \
>   -e REPEATED_UTEST_METHODS=testCompoundPartitionKey,testStaticTable \
>   -e REPEATED_UTEST_COUNT=100
> {code}
> This can be useful on its own so we don't have to manually edit the 
> {{config-2_1.yml}}/{{config.yml}}, and it can also be useful for automation 
> scripts manipulating these files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16992) in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] - org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest



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

Josh McKenzie updated CASSANDRA-16992:
--
 Bug Category: Parent values: Correctness(12982)Level 1 values: Test 
Failure(12990)
   Complexity: Normal
Discovered By: DTest
 Severity: Normal
   Status: Open  (was: Triage Needed)

> in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] - 
> org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
> 
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
>  {quote}
> junit.framework.AssertionFailedError: nodetool command [repair, 
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full] 
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does 
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds 
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints 
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
>   at 
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
>   at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
>   at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
>   at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
>   at 
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
>   at 
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
>   at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
>   at 
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
>   at 
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (CASSANDRA-16992) in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] - org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest

Josh McKenzie created CASSANDRA-16992:
-

 Summary: in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] - 
org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
 Key: CASSANDRA-16992
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
 Project: Cassandra
  Issue Type: Bug
  Components: Test/dtest/java
Reporter: Josh McKenzie


Showed up on CASSANDRA-12988 test runs; can't reproduce locally.

 {quote}
junit.framework.AssertionFailedError: nodetool command [repair, 
distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full] Error 
message 'Got negative replies from endpoints [/127.0.0.2:7012]' does not 
contain any of [Did not get replies from all endpoints.]
stdout:
[2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds queried 
for parent session status and discovered repair failed.
[2021-09-22 17:37:02,187] Got negative replies from endpoints [/127.0.0.2:7012]
[2021-09-22 17:37:02,187] Repair command #4 finished with error

stderr:
error: Got negative replies from endpoints [/127.0.0.2:7012]
-- StackTrace --
java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
at 
org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
at 
org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
at 
org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
at 
org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
at 
org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)
{quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16989) Add environment variables to CircleCI config generation script



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

Ekaterina Dimitrova updated CASSANDRA-16989:

Reviewers: Berenguer Blasi, Ekaterina Dimitrova  (was: Berenguer Blasi)

> Add environment variables to CircleCI config generation script
> --
>
> Key: CASSANDRA-16989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16989
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> The purpose of this ticket is adding arguments to the CircleCI config 
> generation script allowing to set the values specific environment variables 
> such as {{DTEST_REPO}} or {{DTEST_BRANCH}} in the generated 
> {{.circleci/config.yml}} file. For example, we could generate a CircleCI 
> config file with MIDRES specifying a dtest repo and branch by running:
> {code}
> generate.sh -m \
>   -e DTEST_REPO=git://github.com/adelapena/cassandra-dtest.git \
>   -e DTEST_BRANCH=CASSANDRA-8272 
> {code}
> Or we could set the test multiplexer for repeating a specific test with 
> HIGHRES:
> {code}
> generate.sh -h \
>   -e REPEATED_UTEST_TARGET=testsome \
>   -e REPEATED_UTEST_CLASS=org.apache.cassandra.cql3.ViewTest \
>   -e REPEATED_UTEST_METHODS=testCompoundPartitionKey,testStaticTable \
>   -e REPEATED_UTEST_COUNT=100
> {code}
> This can be useful on its own so we don't have to manually edit the 
> {{config-2_1.yml}}/{{config.yml}}, and it can also be useful for automation 
> scripts manipulating these files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16977) ArrayIndexOutOfBoundsException in FunctionResource#fromName



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

Ekaterina Dimitrova commented on CASSANDRA-16977:
-

Different time zones :D Anyway, no biggie :D 

> ArrayIndexOutOfBoundsException in FunctionResource#fromName
> ---
>
> Key: CASSANDRA-16977
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16977
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Authorization
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.12, 4.0.2, 4.1
>
>
> {{FunctionResource}} can't handle functions with 0 args where it throws:
> {noformat}
> 2021-04-08 10:45:40,984 ErrorMessage.java:387 - Unexpected exception during 
> request
> java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.apache.cassandra.auth.FunctionResource.fromName(FunctionResource.java:178)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-12106) Add ability to blocklist / denylist a CQL partition so all requests are ignored



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

Sumanth Pasupuleti edited comment on CASSANDRA-12106 at 9/24/21, 2:36 PM:
--

[~jmckenzie] did a deeper pass, and I have following questions/suggestions
1. It maybe useful to add a documentation file around denylisting partitions 
(maybe along the lines of 
https://github.com/apache/cassandra/compare/trunk...sumanth-pasupuleti:feature/12106#diff-4264f2ac97017f73e4f6fff8f1cbef3082212b2edc531b57f6e8f064d3ab3e49)
2. With regards to limiting the amount of memory we would allow the denylisted 
partitions to take, we could potentially limit/throw warning based on memory as 
an alternate approach to limiting based on number of partition keys. Not a 
strong opinion here since we expect operators (and not end users) to use this 
feature and it should be safe either ways, given we expect operators to be 
informed.
[EDIT] As I think through further, and as mentioned in CEP, it is probably best 
to log a warning if denylisted partitions exceed in either number of memory 
usage vs "limiting" them, in order to maintain consistency across all the 
nodes' caches in terms of what partitions are denylisted.
3. We could as an alternative, allow configuring denylisting specific 
operations (read vs write) per node per partition vs per node - I feel the way 
it is currently implemented (per node and not per node per partition) is less 
complex and easy to use and we should probably stick to that. We can revisit in 
the future if needed.
4. Curious on the choice of exposing consistency level for querying denylisting 
partitions. What do you think of a simpler approach doing "local execution" by 
each node when querying partitions_denylisted table. The benefit would be it 
can make it less complicated in terms of number of options we expose and not 
needing to check if we have enough nodes for the chosen consistency level.
5. Curious on why we disable denylisting range reads by default
6. Regarding the datatype for "key" in "system_distributed.partition_denylist", 
what do you think of choosing text (vs blob). Advantage would be readability of 
the key, and on cache refresh, we would convert it into ByteBuffer
7. What do you think about adding nodetool commands for 
a) refreshing denylist
b) adding a partition to denylist
c) removing a partition from denylist

Happy to contribute to any of these, if decide to make any related changes


was (Author: sumanth.pasupuleti):
[~jmckenzie] did a deeper pass, and I have following questions/suggestions
1. It maybe useful to add a documentation file around denylisting partitions 
(maybe along the lines of 
https://github.com/apache/cassandra/compare/trunk...sumanth-pasupuleti:feature/12106#diff-4264f2ac97017f73e4f6fff8f1cbef3082212b2edc531b57f6e8f064d3ab3e49)
2. With regards to limiting the amount of memory we would allow the denylisted 
partitions to take, we could potentially limit/throw warning based on memory as 
an alternate approach to limiting based on number of partition keys. Not a 
strong opinion here since we expect operators (and not end users) to use this 
feature and it should be safe either ways, given we expect operators to be 
informed.
3. We could as an alternative, allow configuring denylisting specific 
operations (read vs write) per node per partition vs per node - I feel the way 
it is currently implemented (per node and not per node per partition) is less 
complex and easy to use and we should probably stick to that. We can revisit in 
the future if needed.
4. Curious on the choice of exposing consistency level for querying denylisting 
partitions. What do you think of a simpler approach doing "local execution" by 
each node when querying partitions_denylisted table. The benefit would be it 
can make it less complicated in terms of number of options we expose and not 
needing to check if we have enough nodes for the chosen consistency level.
5. Curious on why we disable denylisting range reads by default
6. Regarding the datatype for "key" in "system_distributed.partition_denylist", 
what do you think of choosing text (vs blob). Advantage would be readability of 
the key, and on cache refresh, we would convert it into ByteBuffer
7. What do you think about adding nodetool commands for 
a) refreshing denylist
b) adding a partition to denylist
c) removing a partition from denylist

Happy to contribute to any of these, if decide to make any related changes

> Add ability to blocklist / denylist a CQL partition so all requests are 
> ignored
> ---
>
> Key: CASSANDRA-12106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12106
> Project: Cassandra
>  Issue Type: New Fea

[jira] [Comment Edited] (CASSANDRA-12106) Add ability to blocklist / denylist a CQL partition so all requests are ignored

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

Sumanth Pasupuleti edited comment on CASSANDRA-12106 at 9/24/21, 2:36 PM:
--

Happy to contribute to any of these, if decide to make any related changes

was (Author: sumanth.pasupuleti):
[~jmckenzie] did a deeper pass, and I have following questions/suggestions
1. It maybe useful to add a documentation file around denylisting partitions
(maybe along the lines of
https://github.com/apache/cassandra/compare/trunk...sumanth-pasupuleti:feature/12106#diff-4264f2ac97017f73e4f6fff8f1cbef3082212b2edc531b57f6e8f064d3ab3e49)
2. With regards to limiting the amount of memory we would allow the denylisted
partitions to take, we could potentially limit/throw warning based on memory as
an alternate approach to limiting based on number of partition keys. Not a
strong opinion here since we expect operators (and not end users) to use this
feature and it should be safe either ways, given we expect operators to be
informed.
[EDIT] As I think through further, and as mentioned in CEP, it is probably best
to log a warning if denylisted partitions exceed in either number of memory
usage vs "limiting" them, in order to maintain consistency across all the
nodes' caches in terms of what partitions are denylisted.
3. We could as an alternative, allow configuring denylisting specific
operations (read vs write) per node per partition vs per node - I feel the way
it is currently implemented (per node and not per node per partition) is less
complex and easy to use and we should probably stick to that. We can revisit in
the future if needed.
4. Curious on the choice of exposing consistency level for querying denylisting
partitions. What do you think of a simpler approach doing "local execution" by
each node when querying partitions_denylisted table. The benefit would be it
can make it less complicated in terms of number of options we expose and not
needing to check if we have enough nodes for the chosen consistency level.
5. Curious on why we disable denylisting range reads by default
6. Regarding the datatype for "key" in "system_distributed.partition_denylist",
what do you think of choosing text (vs blob). Advantage would be readability of
the key, and on cache refresh, we would convert it into ByteBuffer
7. What do you think about adding nodetool commands for
a) refreshing denylist
b) adding a partition to denylist
c) removing a partition from denylist

Happy to contribute to any of these, if decide to make any related changes

> Add ability to blocklist / denylist a CQL partition s

[jira] [Updated] (CASSANDRA-16991) python dest Failure: scrub_test.py::TestScrubIndexes::test_scrub_collections_table



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

Brandon Williams updated CASSANDRA-16991:
-
Resolution: Duplicate
Status: Resolved  (was: Open)

This is mea culpa from the linked ticket, but there is a patch there to fix it.

> python dest Failure: 
> scrub_test.py::TestScrubIndexes::test_scrub_collections_table
> --
>
> Key: CASSANDRA-16991
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16991
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction, Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> scrub_test.py::TestScrubIndexes::test_scrub_collections_table
> Saw failure on CASSANDRA-12988; confirmed failure locally and also fails on 
> current trunk.
>  
> Seeing multiple stack traces come out of it. Here's one:
> {code}
> ERROR [CompactionExecutor:2] 2021-09-24 10:29:18,505 CassandraDaemon.java:581 
> - Exception in thread Thread[CompactionExecutor:2,1,main]
> java.io.IOError: org.apache.cassandra.serializers.MarshalException: 
> Unexpected extraneous bytes after list value
>         at 
> org.apache.cassandra.db.compaction.Scrubber.throwIfCannotContinue(Scrubber.java:449)
>         at 
> org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:272)
>         at 
> org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:1159)
>         at 
> org.apache.cassandra.db.compaction.CompactionManager$3.execute(CompactionManager.java:459)
>         at 
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:379)
>         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>         at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>         at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>         at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>         at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: org.apache.cassandra.serializers.MarshalException: Unexpected 
> extraneous bytes after list value
>         at 
> org.apache.cassandra.serializers.ListSerializer.validateForNativeProtocol(ListSerializer.java:82)
>         at 
> org.apache.cassandra.serializers.CollectionSerializer.validate(CollectionSerializer.java:66)
>         at 
> org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:193)
>         at 
> org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:188)
>         at 
> org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:263)
>         ... 8 common frames omitted
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16991) python dest Failure: scrub_test.py::TestScrubIndexes::test_scrub_collections_table



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

Josh McKenzie updated CASSANDRA-16991:
--
Component/s: Test/dtest/python

> python dest Failure: 
> scrub_test.py::TestScrubIndexes::test_scrub_collections_table
> --
>
> Key: CASSANDRA-16991
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16991
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction, Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> scrub_test.py::TestScrubIndexes::test_scrub_collections_table
> Saw failure on CASSANDRA-12988; confirmed failure locally and also fails on 
> current trunk.
>  
> Seeing multiple stack traces come out of it. Here's one:
> {code}
> ERROR [CompactionExecutor:2] 2021-09-24 10:29:18,505 CassandraDaemon.java:581 
> - Exception in thread Thread[CompactionExecutor:2,1,main]
> java.io.IOError: org.apache.cassandra.serializers.MarshalException: 
> Unexpected extraneous bytes after list value
>         at 
> org.apache.cassandra.db.compaction.Scrubber.throwIfCannotContinue(Scrubber.java:449)
>         at 
> org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:272)
>         at 
> org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:1159)
>         at 
> org.apache.cassandra.db.compaction.CompactionManager$3.execute(CompactionManager.java:459)
>         at 
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:379)
>         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>         at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>         at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>         at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>         at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: org.apache.cassandra.serializers.MarshalException: Unexpected 
> extraneous bytes after list value
>         at 
> org.apache.cassandra.serializers.ListSerializer.validateForNativeProtocol(ListSerializer.java:82)
>         at 
> org.apache.cassandra.serializers.CollectionSerializer.validate(CollectionSerializer.java:66)
>         at 
> org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:193)
>         at 
> org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:188)
>         at 
> org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:263)
>         ... 8 common frames omitted
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (CASSANDRA-16991) python dest Failure: scrub_test.py::TestScrubIndexes::test_scrub_collections_table

Josh McKenzie created CASSANDRA-16991:
-

 Summary: python dest Failure: 
scrub_test.py::TestScrubIndexes::test_scrub_collections_table
 Key: CASSANDRA-16991
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16991
 Project: Cassandra
  Issue Type: Bug
  Components: Local/Compaction
Reporter: Josh McKenzie


scrub_test.py::TestScrubIndexes::test_scrub_collections_table

Saw failure on CASSANDRA-12988; confirmed failure locally and also fails on 
current trunk.

 

Seeing multiple stack traces come out of it. Here's one:

{code}
ERROR [CompactionExecutor:2] 2021-09-24 10:29:18,505 CassandraDaemon.java:581 - 
Exception in thread Thread[CompactionExecutor:2,1,main]

java.io.IOError: org.apache.cassandra.serializers.MarshalException: Unexpected 
extraneous bytes after list value

        at 
org.apache.cassandra.db.compaction.Scrubber.throwIfCannotContinue(Scrubber.java:449)

        at org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:272)

        at 
org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:1159)

        at 
org.apache.cassandra.db.compaction.CompactionManager$3.execute(CompactionManager.java:459)

        at 
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:379)

        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)

        at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)

        at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

        at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)

        at java.base/java.lang.Thread.run(Thread.java:829)

Caused by: org.apache.cassandra.serializers.MarshalException: Unexpected 
extraneous bytes after list value

        at 
org.apache.cassandra.serializers.ListSerializer.validateForNativeProtocol(ListSerializer.java:82)

        at 
org.apache.cassandra.serializers.CollectionSerializer.validate(CollectionSerializer.java:66)

        at 
org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:193)

        at 
org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:188)

        at org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:263)

        ... 8 common frames omitted
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-16991) python dest Failure: scrub_test.py::TestScrubIndexes::test_scrub_collections_table



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

Josh McKenzie updated CASSANDRA-16991:
--
 Bug Category: Parent values: Correctness(12982)Level 1 values: Test 
Failure(12990)
   Complexity: Normal
Discovered By: DTest
 Severity: Low
   Status: Open  (was: Triage Needed)

> python dest Failure: 
> scrub_test.py::TestScrubIndexes::test_scrub_collections_table
> --
>
> Key: CASSANDRA-16991
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16991
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Josh McKenzie
>Priority: Normal
>
> scrub_test.py::TestScrubIndexes::test_scrub_collections_table
> Saw failure on CASSANDRA-12988; confirmed failure locally and also fails on 
> current trunk.
>  
> Seeing multiple stack traces come out of it. Here's one:
> {code}
> ERROR [CompactionExecutor:2] 2021-09-24 10:29:18,505 CassandraDaemon.java:581 
> - Exception in thread Thread[CompactionExecutor:2,1,main]
> java.io.IOError: org.apache.cassandra.serializers.MarshalException: 
> Unexpected extraneous bytes after list value
>         at 
> org.apache.cassandra.db.compaction.Scrubber.throwIfCannotContinue(Scrubber.java:449)
>         at 
> org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:272)
>         at 
> org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:1159)
>         at 
> org.apache.cassandra.db.compaction.CompactionManager$3.execute(CompactionManager.java:459)
>         at 
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:379)
>         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>         at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>         at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>         at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>         at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: org.apache.cassandra.serializers.MarshalException: Unexpected 
> extraneous bytes after list value
>         at 
> org.apache.cassandra.serializers.ListSerializer.validateForNativeProtocol(ListSerializer.java:82)
>         at 
> org.apache.cassandra.serializers.CollectionSerializer.validate(CollectionSerializer.java:66)
>         at 
> org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:193)
>         at 
> org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:188)
>         at 
> org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:263)
>         ... 8 common frames omitted
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15856) Security vulnerabilities with dependency jars of Cassandra 3.11.6



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

Stefan Miklosovic commented on CASSANDRA-15856:
---

I think that CVE-2016-5397 is not applicable here neither. I do not know about 
the rest of them yet.

> Security vulnerabilities with dependency jars  of Cassandra 3.11.6
> --
>
> Key: CASSANDRA-15856
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15856
> Project: Cassandra
>  Issue Type: Task
>Reporter: Kshitiz Saxena
>Priority: Normal
> Fix For: 3.11.x
>
>
> The latest release of Cassandra 3.11.6 has few dependency jars which have 
> some security vulnerabilities.
>  
> Apache Thrift (org.apache.thrift:libthrift:0.9.2) has below mentioned 
> security vulnerabilities reported
> |+[https://nvd.nist.gov/vuln/detail/CVE-2016-5397]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2018-1320]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-0205]+|
>  
> Netty Project (io.netty:netty-all:4.0.44.Final) has below mentioned security 
> vulnerabilities reported
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-16869]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20444]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20445]+|
>  
> Is there a plan to upgrade these jars in any upcoming release?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-12106) Add ability to blocklist / denylist a CQL partition so all requests are ignored



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

Sumanth Pasupuleti commented on CASSANDRA-12106:


[~jmckenzie] did a deeper pass, and I have following questions/suggestions
1. It maybe useful to add a documentation file around denylisting partitions 
(maybe along the lines of 
https://github.com/apache/cassandra/compare/trunk...sumanth-pasupuleti:feature/12106#diff-4264f2ac97017f73e4f6fff8f1cbef3082212b2edc531b57f6e8f064d3ab3e49)
2. With regards to limiting the amount of memory we would allow the denylisted 
partitions to take, we could potentially limit/throw warning based on memory as 
an alternate approach to limiting based on number of partition keys. Not a 
strong opinion here since we expect operators (and not end users) to use this 
feature and it should be safe either ways, given we expect operators to be 
informed.
3. We could as an alternative, allow configuring denylisting specific 
operations (read vs write) per node per partition vs per node - I feel the way 
it is currently implemented (per node and not per node per partition) is less 
complex and easy to use and we should probably stick to that. We can revisit in 
the future if needed.
4. Curious on the choice of exposing consistency level for querying denylisting 
partitions. What do you think of a simpler approach doing "local execution" by 
each node when querying partitions_denylisted table. The benefit would be it 
can make it less complicated in terms of number of options we expose and not 
needing to check if we have enough nodes for the chosen consistency level.
5. Curious on why we disable denylisting range reads by default
6. Regarding the datatype for "key" in "system_distributed.partition_denylist", 
what do you think of choosing text (vs blob). Advantage would be readability of 
the key, and on cache refresh, we would convert it into ByteBuffer
7. What do you think about adding nodetool commands for 
a) refreshing denylist
b) adding a partition to denylist
c) removing a partition from denylist

Happy to contribute to any of these, if decide to make any related changes

> Add ability to blocklist / denylist a CQL partition so all requests are 
> ignored
> ---
>
> Key: CASSANDRA-12106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12106
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Local Write-Read Paths, Local/Config
>Reporter: Geoffrey Yu
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Fix For: 4.x
>
> Attachments: 12106-trunk.txt
>
>
> Sometimes reads/writes to a given partition may cause problems due to the 
> data present. It would be useful to have a manual way to blocklist / denylist
>  such partitions so all read and write requests to them are rejected.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15856) Security vulnerabilities with dependency jars of Cassandra 3.11.6



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

Stefan Miklosovic commented on CASSANDRA-15856:
---

Netty vulnerabilities are not applicable to Cassandra.

> Security vulnerabilities with dependency jars  of Cassandra 3.11.6
> --
>
> Key: CASSANDRA-15856
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15856
> Project: Cassandra
>  Issue Type: Task
>Reporter: Kshitiz Saxena
>Priority: Normal
> Fix For: 3.11.x
>
>
> The latest release of Cassandra 3.11.6 has few dependency jars which have 
> some security vulnerabilities.
>  
> Apache Thrift (org.apache.thrift:libthrift:0.9.2) has below mentioned 
> security vulnerabilities reported
> |+[https://nvd.nist.gov/vuln/detail/CVE-2016-5397]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2018-1320]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-0205]+|
>  
> Netty Project (io.netty:netty-all:4.0.44.Final) has below mentioned security 
> vulnerabilities reported
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-16869]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20444]+|
> |+[https://nvd.nist.gov/vuln/detail/CVE-2019-20445]+|
>  
> Is there a plan to upgrade these jars in any upcoming release?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16977) ArrayIndexOutOfBoundsException in FunctionResource#fromName

2021-09-24 Thread Berenguer Blasi (Jira)



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

Berenguer Blasi commented on CASSANDRA-16977:
-

1 day. I merged 1 day later.

> ArrayIndexOutOfBoundsException in FunctionResource#fromName
> ---
>
> Key: CASSANDRA-16977
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16977
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Authorization
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.12, 4.0.2, 4.1
>
>
> {{FunctionResource}} can't handle functions with 0 args where it throws:
> {noformat}
> 2021-04-08 10:45:40,984 ErrorMessage.java:387 - Unexpected exception during 
> request
> java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.apache.cassandra.auth.FunctionResource.fromName(FunctionResource.java:178)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15417) CVE-2019-16869(Netty is vulnerable to HTTP Request Smuggling) of severity 7.5



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

Stefan Miklosovic updated CASSANDRA-15417:
--
Resolution: Not A Problem
Status: Resolved  (was: Triage Needed)

> CVE-2019-16869(Netty is vulnerable to HTTP Request Smuggling) of severity 7.5
> -
>
> Key: CASSANDRA-15417
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15417
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Abhishek Singh
>Priority: Normal
>
> *Description :*
> *Severity :* CVE CVSS 3: 7.5Sonatype CVSS 3: 7.5
> *Weakness :* CVE CWE: 444
> *Source :* National Vulnerability Database
> *Categories :* Data
> *Description from CVE :* Netty before 4.1.42.Final mishandles whitespace 
> before the colon in HTTP headers , which leads to HTTP request smuggling.
> *Explanation :* Netty is vulnerable to HTTP Request Smuggling. The 
> splitHeader method in HttpObjectDecoder.class does not properly handle HTTP 
> headers containing whitespace between the header field-name and colon. An 
> attacker can exploit this by sending such a header containing this white 
> space and have the header end up being parsed by one endpoint and not 
> another, due to inconsistencies in how the whitespace in the header is 
> handled.
> *Detection :* The application is vulnerable by using this component.
> *Recommendation :* We recommend upgrading to a version of this component that 
> is not vulnerable to this specific issue.
> *Root Cause :* 
> apache-cassandra-3.11.4-bin.tar.gzio/netty/handler/codec/http/HttpObjectDecoder.class
>  : [4.0.0.Beta1, 4.1.42.Final]
> *Advisories :* Project: [https://github.com/netty/netty/issues/9571]
> *CVSS Details :* CVE CVSS 3: 7.5CVSS Vector: 
> CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
> *Occurences (Paths) :* ["apache-cassandra.zip" ; "apache-cassandra.zip"]
> *CVE :* CVE-2019-16869
> *URL :* [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16869]
> *Remediation :* This component does not have any non-vulnerable Version. 
> Please contact the vendor to get this vulnerability fixed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15417) CVE-2019-16869(Netty is vulnerable to HTTP Request Smuggling) of severity 7.5



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

Stefan Miklosovic commented on CASSANDRA-15417:
---

I do not think we are using HTTP in Cassandra and I do not think this is 
relevant.

> CVE-2019-16869(Netty is vulnerable to HTTP Request Smuggling) of severity 7.5
> -
>
> Key: CASSANDRA-15417
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15417
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Abhishek Singh
>Priority: Normal
>
> *Description :*
> *Severity :* CVE CVSS 3: 7.5Sonatype CVSS 3: 7.5
> *Weakness :* CVE CWE: 444
> *Source :* National Vulnerability Database
> *Categories :* Data
> *Description from CVE :* Netty before 4.1.42.Final mishandles whitespace 
> before the colon in HTTP headers , which leads to HTTP request smuggling.
> *Explanation :* Netty is vulnerable to HTTP Request Smuggling. The 
> splitHeader method in HttpObjectDecoder.class does not properly handle HTTP 
> headers containing whitespace between the header field-name and colon. An 
> attacker can exploit this by sending such a header containing this white 
> space and have the header end up being parsed by one endpoint and not 
> another, due to inconsistencies in how the whitespace in the header is 
> handled.
> *Detection :* The application is vulnerable by using this component.
> *Recommendation :* We recommend upgrading to a version of this component that 
> is not vulnerable to this specific issue.
> *Root Cause :* 
> apache-cassandra-3.11.4-bin.tar.gzio/netty/handler/codec/http/HttpObjectDecoder.class
>  : [4.0.0.Beta1, 4.1.42.Final]
> *Advisories :* Project: [https://github.com/netty/netty/issues/9571]
> *CVSS Details :* CVE CVSS 3: 7.5CVSS Vector: 
> CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
> *Occurences (Paths) :* ["apache-cassandra.zip" ; "apache-cassandra.zip"]
> *CVE :* CVE-2019-16869
> *URL :* [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16869]
> *Remediation :* This component does not have any non-vulnerable Version. 
> Please contact the vendor to get this vulnerability fixed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-16977) ArrayIndexOutOfBoundsException in FunctionResource#fromName