[jira] [Assigned] (CASSANDRA-16185) Add tests to cover CommitLog metrics

2020-10-20 Thread Yasar Arafath Baigh (Jira)


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

Yasar Arafath Baigh reassigned CASSANDRA-16185:
---

Assignee: Yasar Arafath Baigh  (was: Uchenna)

> Add tests to cover CommitLog metrics
> 
>
> Key: CASSANDRA-16185
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16185
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Yasar Arafath Baigh
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The only metrics that seems to be covered by unit test for the CommitLog 
> metrics is {{oversizedMutations}}. We should add testing the other ones.



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-15944:


Fixed with 
[6d556fe8873296c0a48f747bd9855e462193252d|https://github.com/apache/cassandra-builds/commit/6d556fe8873296c0a48f747bd9855e462193252d].

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-15944:
---
Status: Resolved  (was: Open)

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-builds] branch trunk updated: ninja-fix: jvm-dtest-upgrade are not (yet) JDK11 compatible.

2020-10-20 Thread mck
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 6d556fe  ninja-fix: jvm-dtest-upgrade are not (yet) JDK11 compatible.
6d556fe is described below

commit 6d556fe8873296c0a48f747bd9855e462193252d
Author: Mick Semb Wever 
AuthorDate: Wed Oct 21 08:14:34 2020 +0200

ninja-fix: jvm-dtest-upgrade are not (yet) JDK11 compatible.

ASF CI unit tests on JDK11 (CASSANDRA-15944)
---
 jenkins-dsl/cassandra_job_dsl_seed.groovy | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy 
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index 607d612..ddd1284 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -470,7 +470,8 @@ cassandraBranches.each {
 disabled(false)
 using('Cassandra-template-test')
 axes {
-if (branchName == 'trunk') {
+// jvm-dtest-upgrade would require mixed JDK compilations 
to support JDK11+
+if (branchName == 'trunk' && targetName != 
'jvm-dtest-upgrade') {
 jdk(jdkLabel,'jdk_11_latest')
 } else {
 jdk(jdkLabel)


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



[cassandra-builds] branch trunk updated: ninja-fix: jvm-dtest-upgrade are not (yet) JDK11 compatible.

2020-10-20 Thread mck
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/trunk by this push:
 new dc057fb  ninja-fix: jvm-dtest-upgrade are not (yet) JDK11 compatible.
dc057fb is described below

commit dc057fb53b81ff866008f13d9037a5776f159ce5
Author: Mick Semb Wever 
AuthorDate: Wed Oct 21 07:40:35 2020 +0200

ninja-fix: jvm-dtest-upgrade are not (yet) JDK11 compatible.

ASF CI unit tests on JDK11 (CASSANDRA-15944)
---
 build-scripts/cassandra-test.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/build-scripts/cassandra-test.sh b/build-scripts/cassandra-test.sh
index ae2363f..709f8a7 100755
--- a/build-scripts/cassandra-test.sh
+++ b/build-scripts/cassandra-test.sh
@@ -40,6 +40,9 @@ _main() {
 if ! grep -q CASSANDRA_USE_JDK11 build.xml ; then
 echo "Skipping ${target}. JDK11 not supported against ${version}"
 exit 0
+elif [[ "${target}" == "jvm-dtest-upgrade" ]] ; then
+echo "Skipping JDK11 execution. Mixed JDK compilation required for 
${target}"
+exit 0
 fi
   fi
 


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



[jira] [Updated] (CASSANDRA-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-15944:
---
Status: Open  (was: Resolved)

It's effective, and jvm-dtest-upgrade are broken with jdk11.

It's the building of past versions in that test script that fails. I will fix 
that. Thanks for reporting it [~Bereng].

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Berenguer Blasi (Jira)


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

Berenguer Blasi edited comment on CASSANDRA-15944 at 10/21/20, 4:15 AM:


This doesn't seem to be effective yet in 
https://ci-cassandra.apache.org/job/Cassandra-trunk/ right [~mck]?


was (Author: bereng):
This doesn't seem to be effective in 
https://ci-cassandra.apache.org/job/Cassandra-trunk/ right [~mck]?

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Berenguer Blasi (Jira)


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

Berenguer Blasi commented on CASSANDRA-15944:
-

This doesn't seem to be effective in 
https://ci-cassandra.apache.org/job/Cassandra-trunk/ right [~mck]?

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-16061) transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup

2020-10-20 Thread Berenguer Blasi (Jira)


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

Berenguer Blasi commented on CASSANDRA-16061:
-

SGTM.

> transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup
> 
>
> Key: CASSANDRA-16061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16061
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Failing here, also locally:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/312/workflows/da4ce69c-e778-467e-b9f3-27ab166a8321/jobs/1945]



--
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-15865) Flaky dtest hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow

2020-10-20 Thread Berenguer Blasi (Jira)


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

Berenguer Blasi commented on CASSANDRA-15865:
-

So I managed to repro once laving it overnight 2 days ago. Staring at the code 
I added some debug in {{StorageProxy.shouldHint()}} which made it not repro 
anymore. So I guess I am in the right area of the code but can't repro anymore. 
I'll look into it a bit more. #collaborating

> Flaky dtest 
> hintedhandoff_test.py::TestHintedHandoffConfig::test_hintedhandoff_setmaxwindow
> ---
>
> Key: CASSANDRA-15865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15865
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Sam Tunnicliffe
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I've seen this fail a couple of times under JDK11, when it doesn't appear to 
> be related to the changes under test.
>  
>  



--
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-16219) when running python dtest and using JAVA_TOOL_OPTIONS to inject cassandra configurations, tests fail as they don't expect this flag in stderr

2020-10-20 Thread Jordan West (Jira)


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

Jordan West updated CASSANDRA-16219:

Reviewers: Jordan West, Jordan West  (was: Jordan West)
   Jordan West, Jordan West
   Status: Review In Progress  (was: Patch Available)

[~dcapwell] the patch LGTM. Do you have a test run with the branch? 

> when running python dtest and using JAVA_TOOL_OPTIONS to inject cassandra 
> configurations, tests fail as they don't expect this flag in stderr
> -
>
> Key: CASSANDRA-16219
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16219
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Low
> Fix For: NA
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We have many flags that are set as system properties, and rather than 
> changing the tests to support the different versions, we try to run the tests 
> with different flag settings; this causes some tests to fail as stderr will 
> contain something like the following
> JAVA_TOOL_OPTIONS: -Dcassandra.consistent.simultaneousmoves.allow=true
> We should update our tests to ignore this stderr message.



--
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-16205) Offline token allocation strategy generator tool

2020-10-20 Thread Paulo Motta (Jira)


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

Paulo Motta edited comment on CASSANDRA-16205 at 10/21/20, 2:55 AM:


We used to have a single token generator tool from CASSANDRA-3709 but it was 
removed on CASSANDRA-5261.

I'm trying to think from the user's point of view what's the benefit of using 
the {{allocate_tokens_for_local_replication_factor}} algorithm to generate 
tokens for a new cluster versus manually generating tokens by splitting the 
ring into #nodes/#vnodes segments and assign each segment in a round-robin 
fashion to each node, since the latter option will always generate a more 
balanced allocation?

I did a quick test of the offline token generator with 4 nodes, 4 tokens per 
node, RF=2 and the generated ownership was:
 * with 2 racks: 27%, 27%, 23%, 23%
 * without racks: 22%, 26%, 24%, 28%

If the objective here is to pre-generate tokens to speed up dtests on 
CASSANDRA-16079, couldn't we generate them using the latter approach on 
ccm/dtest ?


was (Author: paulo):
We used to have a single token generator tool from CASSANDRA-3709 but it was 
removed on CASSANDRA-5261.

I'm trying to think from the user's point of view what's the benefit of using 
the {{allocate_tokens_for_local_replication_factor}} algorithm to generate 
tokens for a new cluster versus manually generating tokens by splitting the 
ring into #nodes/#vnodes segments and assign each segment in a round-robin 
fashion to each node, since the latter option will always generate a more 
balanced allocation?

I did a quick test with 4 nodes, 4 tokens per node, RF=2 and the generated 
ownership was:
* with 2 racks: 27%, 27%, 23%, 23%
* without racks: 22%, 26%, 24%, 28%

If the objective here is to pre-generate tokens to speed up dtests on 
CASSANDRA-16079, couldn't we generate them using the latter approach on 
ccm/dtest ?

> Offline token allocation strategy generator tool
> 
>
> Key: CASSANDRA-16205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16205
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config, Local/Scripts
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> A command line tool to generate tokens (using the 
> allocate_tokens_for_local_replication_factor algorithm) for pre-configuration 
> of {{initial_tokens}} in cassandra.yaml.



--
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-16205) Offline token allocation strategy generator tool

2020-10-20 Thread Paulo Motta (Jira)


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

Paulo Motta commented on CASSANDRA-16205:
-

We used to have a single token generator tool from CASSANDRA-3709 but it was 
removed on CASSANDRA-5261.

I'm trying to think from the user's point of view what's the benefit of using 
the {{allocate_tokens_for_local_replication_factor}} algorithm to generate 
tokens for a new cluster versus manually generating tokens by splitting the 
ring into #nodes/#vnodes segments and assign each segment in a round-robin 
fashion to each node, since the latter option will always generate a more 
balanced allocation?

I did a quick test with 4 nodes, 4 tokens per node, RF=2 and the generated 
ownership was:
* with 2 racks: 27%, 27%, 23%, 23%
* without racks: 22%, 26%, 24%, 28%

If the objective here is to pre-generate tokens to speed up dtests on 
CASSANDRA-16079, couldn't we generate them using the latter approach on 
ccm/dtest ?

> Offline token allocation strategy generator tool
> 
>
> Key: CASSANDRA-16205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16205
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config, Local/Scripts
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> A command line tool to generate tokens (using the 
> allocate_tokens_for_local_replication_factor algorithm) for pre-configuration 
> of {{initial_tokens}} in cassandra.yaml.



--
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-16219) when running python dtest and using JAVA_TOOL_OPTIONS to inject cassandra configurations, tests fail as they don't expect this flag in stderr

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16219:
--
Test and Documentation Plan: ran with JAVA_TOOL_OPTIONS set
 Status: Patch Available  (was: Open)

> when running python dtest and using JAVA_TOOL_OPTIONS to inject cassandra 
> configurations, tests fail as they don't expect this flag in stderr
> -
>
> Key: CASSANDRA-16219
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16219
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Low
> Fix For: NA
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We have many flags that are set as system properties, and rather than 
> changing the tests to support the different versions, we try to run the tests 
> with different flag settings; this causes some tests to fail as stderr will 
> contain something like the following
> JAVA_TOOL_OPTIONS: -Dcassandra.consistent.simultaneousmoves.allow=true
> We should update our tests to ignore this stderr message.



--
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-16219) when running python dtest and using JAVA_TOOL_OPTIONS to inject cassandra configurations, tests fail as they don't expect this flag in stderr

2020-10-20 Thread David Capwell (Jira)
David Capwell created CASSANDRA-16219:
-

 Summary: when running python dtest and using JAVA_TOOL_OPTIONS to 
inject cassandra configurations, tests fail as they don't expect this flag in 
stderr
 Key: CASSANDRA-16219
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16219
 Project: Cassandra
  Issue Type: Improvement
  Components: Test/dtest/python
Reporter: David Capwell
Assignee: David Capwell


We have many flags that are set as system properties, and rather than changing 
the tests to support the different versions, we try to run the tests with 
different flag settings; this causes some tests to fail as stderr will contain 
something like the following

JAVA_TOOL_OPTIONS: -Dcassandra.consistent.simultaneousmoves.allow=true

We should update our tests to ignore this stderr message.




--
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-16219) when running python dtest and using JAVA_TOOL_OPTIONS to inject cassandra configurations, tests fail as they don't expect this flag in stderr

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16219:
--
Change Category: Quality Assurance
 Complexity: Low Hanging Fruit
  Fix Version/s: NA
   Priority: Low  (was: Normal)
 Status: Open  (was: Triage Needed)

> when running python dtest and using JAVA_TOOL_OPTIONS to inject cassandra 
> configurations, tests fail as they don't expect this flag in stderr
> -
>
> Key: CASSANDRA-16219
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16219
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Low
> Fix For: NA
>
>
> We have many flags that are set as system properties, and rather than 
> changing the tests to support the different versions, we try to run the tests 
> with different flag settings; this causes some tests to fail as stderr will 
> contain something like the following
> JAVA_TOOL_OPTIONS: -Dcassandra.consistent.simultaneousmoves.allow=true
> We should update our tests to ignore this stderr message.



--
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-16209) Log Warning Rather than Verbose Trace when Preview Repair Validation Conflicts with Incremental Repair

2020-10-20 Thread David Capwell (Jira)


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

David Capwell edited comment on CASSANDRA-16209 at 10/20/20, 11:05 PM:
---

CI Results: Yellow, looks like flaky test in vnode that passed in no-vnode

Branch: trunk
Circle: 
https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16209-trunk-CA2DA0FE-A62A-424A-863D-D9A2A523EEDA
Jenkins: https://ci-cassandra.apache.org/job/Cassandra-devbranch/118/



was (Author: dcapwell):
Starting commit

CI Results (pending):

Branch: trunk
Circle: 
https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16209-trunk-CA2DA0FE-A62A-424A-863D-D9A2A523EEDA
Jenkins: https://ci-cassandra.apache.org/job/Cassandra-devbranch/118/


> Log Warning Rather than Verbose Trace when Preview Repair Validation 
> Conflicts with Incremental Repair
> --
>
> Key: CASSANDRA-16209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16209
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta3
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When a preview repair on repaired data identifies which SSTables to validate, 
> it might come across an SSTable that's still pending for an in-progress 
> incremental repair session. It makes sense that we immediately fail the 
> preview repair in that case, but the resulting error and verbose stack trace 
> in the logs is a bit too severe a reaction. We should downgrade this to a 
> simple warning message.



--
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-16209) Log Warning Rather than Verbose Trace when Preview Repair Validation Conflicts with Incremental Repair

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16209:
--
  Fix Version/s: (was: 4.0-beta)
 4.0-beta3
Source Control Link: 
https://github.com/apache/cassandra/commit/8818f3442e4f1321bacb7150fe5ef6fd63f2a2d0
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Log Warning Rather than Verbose Trace when Preview Repair Validation 
> Conflicts with Incremental Repair
> --
>
> Key: CASSANDRA-16209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16209
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta3
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When a preview repair on repaired data identifies which SSTables to validate, 
> it might come across an SSTable that's still pending for an in-progress 
> incremental repair session. It makes sense that we immediately fail the 
> preview repair in that case, but the resulting error and verbose stack trace 
> in the logs is a bit too severe a reaction. We should downgrade this to a 
> simple warning message.



--
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: Log Warning Rather than Verbose Trace when Preview Repair Validation Conflicts with Incremental Repair

2020-10-20 Thread dcapwell
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 2edc5bb  Log Warning Rather than Verbose Trace when Preview Repair 
Validation Conflicts with Incremental Repair
2edc5bb is described below

commit 2edc5bb441eb7e3ccd549333012ef00fd1d5c428
Author: Caleb Rackliffe 
AuthorDate: Tue Oct 20 14:58:57 2020 -0700

Log Warning Rather than Verbose Trace when Preview Repair Validation 
Conflicts with Incremental Repair

patch by Caleb Rackliffe; reviewed by David Capwell, Marcus Eriksson for 
CASSANDRA-16209
---
 ...pairConflictWithIncrementalRepairException.java |  27 
 .../apache/cassandra/repair/ValidationManager.java |   5 +
 .../apache/cassandra/streaming/PreviewKind.java|   3 +-
 .../utils/concurrent/SimpleCondition.java  |   7 +-
 .../distributed/test/PreviewRepairTest.java| 169 +
 5 files changed, 180 insertions(+), 31 deletions(-)

diff --git 
a/src/java/org/apache/cassandra/repair/PreviewRepairConflictWithIncrementalRepairException.java
 
b/src/java/org/apache/cassandra/repair/PreviewRepairConflictWithIncrementalRepairException.java
new file mode 100644
index 000..09be1a4
--- /dev/null
+++ 
b/src/java/org/apache/cassandra/repair/PreviewRepairConflictWithIncrementalRepairException.java
@@ -0,0 +1,27 @@
+/*
+ * 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.repair;
+
+public class PreviewRepairConflictWithIncrementalRepairException extends 
IllegalStateException
+{
+public PreviewRepairConflictWithIncrementalRepairException(String s)
+{
+super(s);
+}
+}
diff --git a/src/java/org/apache/cassandra/repair/ValidationManager.java 
b/src/java/org/apache/cassandra/repair/ValidationManager.java
index 4bbffbf..eb6ec96 100644
--- a/src/java/org/apache/cassandra/repair/ValidationManager.java
+++ b/src/java/org/apache/cassandra/repair/ValidationManager.java
@@ -161,6 +161,11 @@ public class ValidationManager
 {
 doValidation(cfs, validator);
 }
+catch (PreviewRepairConflictWithIncrementalRepairException e)
+{
+validator.fail();
+logger.warn(e.getMessage());
+}
 catch (Throwable e)
 {
 // we need to inform the remote end of our failure, 
otherwise it will hang on repair forever
diff --git a/src/java/org/apache/cassandra/streaming/PreviewKind.java 
b/src/java/org/apache/cassandra/streaming/PreviewKind.java
index b5467de..3d0bff9 100644
--- a/src/java/org/apache/cassandra/streaming/PreviewKind.java
+++ b/src/java/org/apache/cassandra/streaming/PreviewKind.java
@@ -25,6 +25,7 @@ import com.google.common.base.Predicates;
 
 import org.apache.cassandra.io.sstable.format.SSTableReader;
 import org.apache.cassandra.io.sstable.metadata.StatsMetadata;
+import 
org.apache.cassandra.repair.PreviewRepairConflictWithIncrementalRepairException;
 import org.apache.cassandra.repair.consistent.ConsistentSession;
 import org.apache.cassandra.repair.consistent.LocalSession;
 import org.apache.cassandra.service.ActiveRepairService;
@@ -92,7 +93,7 @@ public enum PreviewKind
 else if (session.getState() == 
ConsistentSession.State.FINALIZED)
 return true;
 else if (session.getState() != ConsistentSession.State.FAILED)
-throw new IllegalStateException(String.format("SSTable %s 
is marked pending for non-finalized incremental repair session %s, failing 
preview repair", sstable, sstableMetadata.pendingRepair));
+throw new 
PreviewRepairConflictWithIncrementalRepairException(String.format("SSTable %s 
is marked pending for non-finalized incremental repair session %s, failing 
preview repair", sstable, sstableMetadata.pendingRepair));
 }
 return sstableMetadata.repairedAt != 
ActiveRepairService.UNREPAIRED_SSTABLE;
 }
diff --git 
a/src/java/org/apache/cassandra/utils/concurr

[jira] [Commented] (CASSANDRA-16209) Log Warning Rather than Verbose Trace when Preview Repair Validation Conflicts with Incremental Repair

2020-10-20 Thread David Capwell (Jira)


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

David Capwell commented on CASSANDRA-16209:
---

Starting commit

CI Results (pending):

Branch: trunk
Circle: 
https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16209-trunk-CA2DA0FE-A62A-424A-863D-D9A2A523EEDA
Jenkins: https://ci-cassandra.apache.org/job/Cassandra-devbranch/118/


> Log Warning Rather than Verbose Trace when Preview Repair Validation 
> Conflicts with Incremental Repair
> --
>
> Key: CASSANDRA-16209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16209
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When a preview repair on repaired data identifies which SSTables to validate, 
> it might come across an SSTable that's still pending for an in-progress 
> incremental repair session. It makes sense that we immediately fail the 
> preview repair in that case, but the resulting error and verbose stack trace 
> in the logs is a bit too severe a reaction. We should downgrade this to a 
> simple warning message.



--
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-16209) Log Warning Rather than Verbose Trace when Preview Repair Validation Conflicts with Incremental Repair

2020-10-20 Thread David Capwell (Jira)


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

David Capwell commented on CASSANDRA-16209:
---

+1 from me, ill start the commit.

> Log Warning Rather than Verbose Trace when Preview Repair Validation 
> Conflicts with Incremental Repair
> --
>
> Key: CASSANDRA-16209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16209
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When a preview repair on repaired data identifies which SSTables to validate, 
> it might come across an SSTable that's still pending for an in-progress 
> incremental repair session. It makes sense that we immediately fail the 
> preview repair in that case, but the resulting error and verbose stack trace 
> in the logs is a bit too severe a reaction. We should downgrade this to a 
> simple warning message.



--
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-16209) Log Warning Rather than Verbose Trace when Preview Repair Validation Conflicts with Incremental Repair

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16209:
--
Reviewers: David Capwell, Marcus Eriksson  (was: Marcus Eriksson)

> Log Warning Rather than Verbose Trace when Preview Repair Validation 
> Conflicts with Incremental Repair
> --
>
> Key: CASSANDRA-16209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16209
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When a preview repair on repaired data identifies which SSTables to validate, 
> it might come across an SSTable that's still pending for an in-progress 
> incremental repair session. It makes sense that we immediately fail the 
> preview repair in that case, but the resulting error and verbose stack trace 
> in the logs is a bit too severe a reaction. We should downgrade this to a 
> simple warning message.



--
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-16144) TLS connections to the storage port on a node without server encryption configured causes java.io.IOException accessing missing keystore

2020-10-20 Thread David Capwell (Jira)


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

David Capwell commented on CASSANDRA-16144:
---

Finished my first review, left comments in PR.

Can we also make sure that this patch is in-sync with the changes in 
CASSANDRA-15262, just want to make sure we don't revert those changes (looks 
like visibility is getting changed a little bit)

> TLS connections to the storage port on a node without server encryption 
> configured causes java.io.IOException accessing missing keystore
> 
>
> Key: CASSANDRA-16144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16144
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> If a TLS connection is requested against a node with all encryption disabled 
> by configuration,
> configured with
> {code}
> server_encryption_options: {optional:false, internode_encryption: none}
> {code}
> it logs the following error if no keystore exists for the node.
> {code}
> INFO  [Messaging-EventLoop-3-3] 2020-09-15T14:30:02,952 : - 
> 127.0.0.1:7000->127.0.1.1:7000-URGENT_MESSAGES-[no-channel] failed to connect
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection 
> refused: local1-i1/127.0.1.1:7000
> Caused by: java.net.ConnectException: Connection refused
>at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[?:?]
>at 
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779) ~[?:?]
>at 
> io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:330)
>  ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334)
>  ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:702) 
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
>  ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576) 
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) 
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>  [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) 
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>  [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.lang.Thread.run(Thread.java:834) [?:?]
> WARN  [Messaging-EventLoop-3-9] 2020-09-15T14:30:06,375 : - Failed to 
> initialize a channel. Closing: [id: 0x0746c157, L:/127.0.0.1:7000 - 
> R:/127.0.0.1:59623]
> java.io.IOException: failed to build trust manager store for secure 
> connections
>at 
> org.apache.cassandra.security.SSLFactory.buildKeyManagerFactory(SSLFactory.java:232)
>  ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at 
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:300)
>  ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at 
> org.apache.cassandra.security.SSLFactory.getOrCreateSslContext(SSLFactory.java:276)
>  ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at 
> org.apache.cassandra.security.SSLFactory.getOrCreateSslContext(SSLFactory.java:257)
>  ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at 
> org.apache.cassandra.net.InboundConnectionInitiator$Initializer.initChannel(InboundConnectionInitiator.java:107)
>  ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at 
> org.apache.cassandra.net.InboundConnectionInitiator$Initializer.initChannel(InboundConnectionInitiator.java:71)
>  ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at 
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129) 
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112) 
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:9

[jira] [Commented] (CASSANDRA-16144) TLS connections to the storage port on a node without server encryption configured causes java.io.IOException accessing missing keystore

2020-10-20 Thread David Capwell (Jira)


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

David Capwell commented on CASSANDRA-16144:
---

CI is failing

{code}
[junit-timeout] Testsuite: 
org.apache.cassandra.distributed.test.AbstractEncryptionOptionsTest
[junit-timeout] Testsuite: 
org.apache.cassandra.distributed.test.AbstractEncryptionOptionsTest Tests run: 
1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.046 sec
[junit-timeout] 
[junit-timeout] Testcase: 
initializationError(org.apache.cassandra.distributed.test.AbstractEncryptionOptionsTest):
 Caused an ERROR
[junit-timeout] No runnable methods
[junit-timeout] java.lang.Exception: No runnable methods
[junit-timeout] at 
java.lang.reflect.Constructor.newInstance(Constructor.java:423)
{code}

Our builds are not smart, they search for files with the following pattern: 
{code:java}
*Test.java
{code}

since your abstract class matches that pattern, it tried to run it and failed.

Also the new yaml test failed

{code}
[junit-timeout] Testsuite: org.apache.cassandra.distributed.test.JVMDTestTest
[junit-timeout] Testsuite: org.apache.cassandra.distributed.test.JVMDTestTest 
Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 151.146 sec
[junit-timeout] 
[junit-timeout] Testcase: 
nonSharedConfigClassTest(org.apache.cassandra.distributed.test.JVMDTestTest): 
Caused an ERROR
[junit-timeout] Unable to find getter for property 'enabled' on object 
org.apache.cassandra.config.EncryptionOptions@bb156a7f:java.lang.reflect.InvocationTargetException
[junit-timeout] org.yaml.snakeyaml.error.YAMLException: Unable to find getter 
for property 'enabled' on object 
org.apache.cassandra.config.EncryptionOptions@bb156a7f:java.lang.reflect.InvocationTargetException
[junit-timeout] at 
org.yaml.snakeyaml.introspector.MethodProperty.get(MethodProperty.java:86)
[junit-timeout] at 
org.yaml.snakeyaml.representer.Representer.representJavaBean(Representer.java:108)
[junit-timeout] at 
org.yaml.snakeyaml.representer.Representer$RepresentJavaBean.representData(Representer.java:80)
[junit-timeout] at 
org.yaml.snakeyaml.representer.BaseRepresenter.representData(BaseRepresenter.java:106)
[junit-timeout] at 
org.yaml.snakeyaml.representer.BaseRepresenter.representMapping(BaseRepresenter.java:157)
[junit-timeout] at 
org.yaml.snakeyaml.representer.SafeRepresenter$RepresentMap.representData(SafeRepresenter.java:321)
[junit-timeout] at 
org.yaml.snakeyaml.representer.BaseRepresenter.representData(BaseRepresenter.java:95)
[junit-timeout] at 
org.yaml.snakeyaml.representer.BaseRepresenter.represent(BaseRepresenter.java:65)
[junit-timeout] at org.yaml.snakeyaml.Yaml.represent(Yaml.java:232)
[junit-timeout] at 
org.apache.cassandra.config.YamlConfigurationLoader.fromMap(YamlConfigurationLoader.java:147)
{code}

> TLS connections to the storage port on a node without server encryption 
> configured causes java.io.IOException accessing missing keystore
> 
>
> Key: CASSANDRA-16144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16144
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> If a TLS connection is requested against a node with all encryption disabled 
> by configuration,
> configured with
> {code}
> server_encryption_options: {optional:false, internode_encryption: none}
> {code}
> it logs the following error if no keystore exists for the node.
> {code}
> INFO  [Messaging-EventLoop-3-3] 2020-09-15T14:30:02,952 : - 
> 127.0.0.1:7000->127.0.1.1:7000-URGENT_MESSAGES-[no-channel] failed to connect
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection 
> refused: local1-i1/127.0.1.1:7000
> Caused by: java.net.ConnectException: Connection refused
>at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[?:?]
>at 
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779) ~[?:?]
>at 
> io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:330)
>  ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334)
>  ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:702) 
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOpti

[jira] [Updated] (CASSANDRA-16218) Simplify the almost duplicated code for calculating serialization size and serialization

2020-10-20 Thread Yifan Cai (Jira)


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

Yifan Cai updated CASSANDRA-16218:
--
Status: Open  (was: Triage Needed)

> Simplify the almost duplicated code for calculating serialization size and 
> serialization
> 
>
> Key: CASSANDRA-16218
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16218
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Client, Messaging/Internode
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The current pattern of counting the serialization size and the actual 
> serialization in the codebase is error-prone and hard to maintain. Those 2 
> code paths have almost the same code repeated. 
>  
> The pattern can be found in {{org.apache.cassandra.net.Message#Serializer}} 
> and numerous locations that use {{org.apache.cassandra.transport.CBCodec}}. 
>  
> I am proposing a new approach that lets both methods share the same code 
> path. The code basically looks like the below (in the case of 
> {{org.apache.cassandra.net.Message#Serializer}}).
> {code:java}
> // A fake DataOutputPlus that simply increment the size when invoking write* 
> methods
> public class SizeCountingDataOutput implements DataOutputPlus
> {
>  private int size = 0;
>  public int getSize()
>  {
>return size;
>  }
>  public void write(int b)
>  {
>size += 1;
>  }
>  public void write(byte[] b)
>  {
>size += b.length;
>  }
>  ...
> }
> {code}
> Therefore, in the size calculation, we can supply the fake data output and 
> call serialize to get the size.
> {code:java}
> private  int serializedSize(Message message, int version)
> {
>  SizeCountingDataOutput out = new SizeCountingDataOutput();
>  try
>  {
>serialize(message, out, version);
>  }
>  catch (IOException exception)
>  {
>throw new AssertionError("It should not happen!", exception);
>  }
>  return out.getSize();
> // The original implementation
> // return version >= VERSION_40 ? serializedSizePost40(message, version) : 
> serializedSizePre40(message, version);
> }
> {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-16177) jvm_upgrade_dtests job issue in CircleCI MIDRES

2020-10-20 Thread David Capwell (Jira)


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

David Capwell commented on CASSANDRA-16177:
---

committed, thanks!

> jvm_upgrade_dtests job issue in CircleCI MIDRES
> ---
>
> Key: CASSANDRA-16177
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16177
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: NA
>
>
> jvm_upgrade_dtests work well in HIGHRES, but we see the following issue with 
> MIDRES:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/349/workflows/04bccc52-4e3e-41e2-9c04-93501ea4ce77/jobs/2167/steps



--
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: jvm_upgrade_dtests job in CircleCI MIDRES is allocated too many resources so fails

2020-10-20 Thread dcapwell
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 1e2d800  jvm_upgrade_dtests job in CircleCI MIDRES is allocated too 
many resources so fails
1e2d800 is described below

commit 1e2d800421fe482fc2f16a814f44477cb284a93a
Author: Ekaterina Dimitrova 
AuthorDate: Tue Oct 20 14:13:34 2020 -0700

jvm_upgrade_dtests job in CircleCI MIDRES is allocated too many resources 
so fails

patch by Ekaterina Dimitrova; reviewed by David Capwell for CASSANDRA-16177
---
 .circleci/config-2_1.yml.mid_res.patch | 2 +-
 .circleci/config.yml.MIDRES| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.circleci/config-2_1.yml.mid_res.patch 
b/.circleci/config-2_1.yml.mid_res.patch
index 56b0887..f0b5598 100644
--- a/.circleci/config-2_1.yml.mid_res.patch
+++ b/.circleci/config-2_1.yml.mid_res.patch
@@ -25,7 +25,7 @@ index ab621241a4..9c11f60d5d 100644
 -#exec_resource_class: xlarge
 -  parallelism: 1
 +exec_resource_class: large
-+  parallelism: 10
++  parallelism: 4
 +
 +j8_large_par_executor: &j8_large_par_executor
 +  executor:
diff --git a/.circleci/config.yml.MIDRES b/.circleci/config.yml.MIDRES
index 979ee15..482174b 100644
--- a/.circleci/config.yml.MIDRES
+++ b/.circleci/config.yml.MIDRES
@@ -6,7 +6,7 @@ jobs:
 resource_class: large
 working_directory: ~/
 shell: /bin/bash -eo pipefail -l
-parallelism: 10
+parallelism: 4
 steps:
 - attach_workspace:
 at: /home/cassandra


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



[jira] [Updated] (CASSANDRA-16177) jvm_upgrade_dtests job issue in CircleCI MIDRES

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16177:
--
  Fix Version/s: (was: 4.0-beta)
 NA
  Since Version: NA
Source Control Link: 
https://github.com/apache/cassandra/commit/1e2d800421fe482fc2f16a814f44477cb284a93a
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> jvm_upgrade_dtests job issue in CircleCI MIDRES
> ---
>
> Key: CASSANDRA-16177
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16177
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: NA
>
>
> jvm_upgrade_dtests work well in HIGHRES, but we see the following issue with 
> MIDRES:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/349/workflows/04bccc52-4e3e-41e2-9c04-93501ea4ce77/jobs/2167/steps



--
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-16177) jvm_upgrade_dtests job issue in CircleCI MIDRES

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16177:
--
Status: Ready to Commit  (was: Review In Progress)

> jvm_upgrade_dtests job issue in CircleCI MIDRES
> ---
>
> Key: CASSANDRA-16177
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16177
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> jvm_upgrade_dtests work well in HIGHRES, but we see the following issue with 
> MIDRES:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/349/workflows/04bccc52-4e3e-41e2-9c04-93501ea4ce77/jobs/2167/steps



--
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-16177) jvm_upgrade_dtests job issue in CircleCI MIDRES

2020-10-20 Thread David Capwell (Jira)


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

David Capwell commented on CASSANDRA-16177:
---

+1

> jvm_upgrade_dtests job issue in CircleCI MIDRES
> ---
>
> Key: CASSANDRA-16177
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16177
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> jvm_upgrade_dtests work well in HIGHRES, but we see the following issue with 
> MIDRES:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/349/workflows/04bccc52-4e3e-41e2-9c04-93501ea4ce77/jobs/2167/steps



--
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-16177) jvm_upgrade_dtests job issue in CircleCI MIDRES

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16177:
--
Reviewers: David Capwell, David Capwell  (was: David Capwell)
   David Capwell, David Capwell
   Status: Review In Progress  (was: Patch Available)

> jvm_upgrade_dtests job issue in CircleCI MIDRES
> ---
>
> Key: CASSANDRA-16177
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16177
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> jvm_upgrade_dtests work well in HIGHRES, but we see the following issue with 
> MIDRES:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/349/workflows/04bccc52-4e3e-41e2-9c04-93501ea4ce77/jobs/2167/steps



--
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-16218) Simplify the almost duplicated code for calculating serialization size and serialization

2020-10-20 Thread Yifan Cai (Jira)


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

Yifan Cai updated CASSANDRA-16218:
--
Change Category: Code Clarity
 Complexity: Normal
  Fix Version/s: 4.0-beta

> Simplify the almost duplicated code for calculating serialization size and 
> serialization
> 
>
> Key: CASSANDRA-16218
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16218
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Client, Messaging/Internode
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The current pattern of counting the serialization size and the actual 
> serialization in the codebase is error-prone and hard to maintain. Those 2 
> code paths have almost the same code repeated. 
>  
> The pattern can be found in {{org.apache.cassandra.net.Message#Serializer}} 
> and numerous locations that use {{org.apache.cassandra.transport.CBCodec}}. 
>  
> I am proposing a new approach that lets both methods share the same code 
> path. The code basically looks like the below (in the case of 
> {{org.apache.cassandra.net.Message#Serializer}}).
> {code:java}
> // A fake DataOutputPlus that simply increment the size when invoking write* 
> methods
> public class SizeCountingDataOutput implements DataOutputPlus
> {
>  private int size = 0;
>  public int getSize()
>  {
>return size;
>  }
>  public void write(int b)
>  {
>size += 1;
>  }
>  public void write(byte[] b)
>  {
>size += b.length;
>  }
>  ...
> }
> {code}
> Therefore, in the size calculation, we can supply the fake data output and 
> call serialize to get the size.
> {code:java}
> private  int serializedSize(Message message, int version)
> {
>  SizeCountingDataOutput out = new SizeCountingDataOutput();
>  try
>  {
>serialize(message, out, version);
>  }
>  catch (IOException exception)
>  {
>throw new AssertionError("It should not happen!", exception);
>  }
>  return out.getSize();
> // The original implementation
> // return version >= VERSION_40 ? serializedSizePost40(message, version) : 
> serializedSizePre40(message, version);
> }
> {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-16218) Simplify the almost duplicated code for calculating serialization size and serialization

2020-10-20 Thread Yifan Cai (Jira)
Yifan Cai created CASSANDRA-16218:
-

 Summary: Simplify the almost duplicated code for calculating 
serialization size and serialization
 Key: CASSANDRA-16218
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16218
 Project: Cassandra
  Issue Type: Improvement
  Components: Messaging/Client, Messaging/Internode
Reporter: Yifan Cai
Assignee: Yifan Cai


The current pattern of counting the serialization size and the actual 
serialization in the codebase is error-prone and hard to maintain. Those 2 code 
paths have almost the same code repeated. 
 
The pattern can be found in {{org.apache.cassandra.net.Message#Serializer}} and 
numerous locations that use {{org.apache.cassandra.transport.CBCodec}}. 
 
I am proposing a new approach that lets both methods share the same code path. 
The code basically looks like the below (in the case of 
{{org.apache.cassandra.net.Message#Serializer}}).

{code:java}
// A fake DataOutputPlus that simply increment the size when invoking write* 
methods
public class SizeCountingDataOutput implements DataOutputPlus
{
 private int size = 0;

 public int getSize()
 {
   return size;
 }

 public void write(int b)
 {
   size += 1;
 }

 public void write(byte[] b)
 {
   size += b.length;
 }
 ...
}
{code}

Therefore, in the size calculation, we can supply the fake data output and call 
serialize to get the size.

{code:java}
private  int serializedSize(Message message, int version)
{
 SizeCountingDataOutput out = new SizeCountingDataOutput();
 try
 {
   serialize(message, out, version);
 }
 catch (IOException exception)
 {
   throw new AssertionError("It should not happen!", exception);
 }
 return out.getSize();
// The original implementation
// return version >= VERSION_40 ? serializedSizePost40(message, version) : 
serializedSizePre40(message, version);
}
{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] [Assigned] (CASSANDRA-9633) Add ability to encrypt sstables

2020-10-20 Thread Josh McKenzie (Jira)


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

Josh McKenzie reassigned CASSANDRA-9633:


Assignee: shylaja kokoori

> Add ability to encrypt sstables
> ---
>
> Key: CASSANDRA-9633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9633
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: shylaja kokoori
>Priority: Normal
>  Labels: encryption, security, sstable
> Fix For: 4.x
>
>
> Add option to allow encrypting of sstables.
> I have a version of this functionality built on cassandra 2.0 that 
> piggy-backs on the existing sstable compression functionality and ICompressor 
> interface (similar in nature to what DataStax Enterprise does). However, if 
> we're adding the feature to the main OSS product, I'm not sure if we want to 
> use the pluggable compression framework or if it's worth investigating a 
> different path. I think there's a lot of upside in reusing the sstable 
> compression scheme, but perhaps add a new component in cqlsh for table 
> encryption and a corresponding field in CFMD.
> Encryption configuration in the yaml can use the same mechanism as 
> CASSANDRA-6018 (which is currently pending internal review).



--
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-16124) nodetool enablebinary throws exception

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16124:
--
Resolution: Duplicate
Status: Resolved  (was: Open)

> nodetool enablebinary throws exception
> --
>
> Key: CASSANDRA-16124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16124
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: Tommy Stendahl
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> I think there is a bug in 3.11.8, if you disable the Native port its not 
> possible to enable it (without restarting Cassandra).
> {quote}> nodetool statusbinary
>  running
>  > nodetool disablebinary
>  > nodetool statusbinary
>  not running
>  > nodetool enablebinary
>  error: Error starting native transport: setup() must be called first for 
> CassandraDaemon
>  – StackTrace –
>  java.lang.RuntimeException: Error starting native transport: setup() must be 
> called first for CassandraDaemon
>  at 
> org.apache.cassandra.service.StorageService.startNativeTransport(StorageService.java:429)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
>  at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
>  at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
>  at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
>  at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
>  at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
>  at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
>  at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>  at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
>  at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
>  at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>  at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
>  at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
>  at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
>  at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
>  at sun.rmi.transport.Transport$1.run(Transport.java:200)
>  at sun.rmi.transport.Transport$1.run(Transport.java:197)
>  at java.security.AccessController.doPrivileged(Native Method)
>  at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>  at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
>  at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
>  at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
>  at java.security.AccessController.doPrivileged(Native Method)
>  at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> {quote}
> I think this was introduced with CASSANDRA-15967. In 
> {{CassandraDaemon.stopNativeTransport()}} {{nativeTransportService}} is set 
> to {{null}} and when {{CassandraDaemon.startNativeTransport()}} is called the 
> exception is thrown. By adding a call to 
> {{CassandraDaemon.initializeNativeTransport()}} before calling 
> {{CassandraDaemon.startNativeTransport()}} works but I'm not sure what the 
> intention here is.



--
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-16091) rpc server gets wrongly initialized with rpc_enabled:false

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16091:
--
Resolution: Duplicate
Status: Resolved  (was: Open)

> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception 
> is thrown:
> {code:java}
>  java.lang.RuntimeException: Client SSL is not supported for non-blocking 
> sockets (hsha). Please remove client ssl from the configuration.
>   at 
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
>   at 
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
>   at 
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
>   at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
>   at 
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
>   at 
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in 
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7 
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which 
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does 
> resolve the issue, as expected, but this does seem like a regression, hence 
> the Jira 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-16091) rpc server gets wrongly initialized with rpc_enabled:false

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16091:
--
Status: Patch Available  (was: Ready to Commit)

> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception 
> is thrown:
> {code:java}
>  java.lang.RuntimeException: Client SSL is not supported for non-blocking 
> sockets (hsha). Please remove client ssl from the configuration.
>   at 
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
>   at 
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
>   at 
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
>   at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
>   at 
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
>   at 
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in 
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7 
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which 
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does 
> resolve the issue, as expected, but this does seem like a regression, hence 
> the Jira 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-16091) rpc server gets wrongly initialized with rpc_enabled:false

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16091:
--
Status: Open  (was: Patch Available)

> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception 
> is thrown:
> {code:java}
>  java.lang.RuntimeException: Client SSL is not supported for non-blocking 
> sockets (hsha). Please remove client ssl from the configuration.
>   at 
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
>   at 
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
>   at 
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
>   at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
>   at 
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
>   at 
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in 
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7 
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which 
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does 
> resolve the issue, as expected, but this does seem like a regression, hence 
> the Jira 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-16091) rpc server gets wrongly initialized with rpc_enabled:false

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16091:
--
Reviewers: David Capwell, David Capwell  (was: David Capwell)
   David Capwell, David Capwell
   Status: Review In Progress  (was: Patch Available)

> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception 
> is thrown:
> {code:java}
>  java.lang.RuntimeException: Client SSL is not supported for non-blocking 
> sockets (hsha). Please remove client ssl from the configuration.
>   at 
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
>   at 
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
>   at 
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
>   at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
>   at 
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
>   at 
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in 
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7 
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which 
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does 
> resolve the issue, as expected, but this does seem like a regression, hence 
> the Jira 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-16091) rpc server gets wrongly initialized with rpc_enabled:false

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16091:
--
Status: Ready to Commit  (was: Review In Progress)

> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception 
> is thrown:
> {code:java}
>  java.lang.RuntimeException: Client SSL is not supported for non-blocking 
> sockets (hsha). Please remove client ssl from the configuration.
>   at 
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
>   at 
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
>   at 
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
>   at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
>   at 
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
>   at 
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in 
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7 
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which 
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does 
> resolve the issue, as expected, but this does seem like a regression, hence 
> the Jira 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-16091) rpc server gets wrongly initialized with rpc_enabled:false

2020-10-20 Thread David Capwell (Jira)


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

David Capwell updated CASSANDRA-16091:
--
Test and Documentation Plan: a
 Status: Patch Available  (was: In Progress)

> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception 
> is thrown:
> {code:java}
>  java.lang.RuntimeException: Client SSL is not supported for non-blocking 
> sockets (hsha). Please remove client ssl from the configuration.
>   at 
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
>   at 
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
>   at 
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
>   at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
>   at 
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
>   at 
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in 
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7 
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which 
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does 
> resolve the issue, as expected, but this does seem like a regression, hence 
> the Jira 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-16091) rpc server gets wrongly initialized with rpc_enabled:false

2020-10-20 Thread David Capwell (Jira)


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

David Capwell commented on CASSANDRA-16091:
---

fixed in CASSANDRA-16127

> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception 
> is thrown:
> {code:java}
>  java.lang.RuntimeException: Client SSL is not supported for non-blocking 
> sockets (hsha). Please remove client ssl from the configuration.
>   at 
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
>   at 
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
>   at 
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
>   at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
>   at 
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
>   at 
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in 
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7 
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which 
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does 
> resolve the issue, as expected, but this does seem like a regression, hence 
> the Jira 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] [Comment Edited] (CASSANDRA-15935) Improve machinery for testing consistency in presence of range movements

2020-10-20 Thread Alex Petrov (Jira)


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

Alex Petrov edited comment on CASSANDRA-15935 at 10/20/20, 6:12 PM:


[~dcapwell] Thanks for one more pass. Addressed remaining review points. I did 
run upgrade dtests, but only from 4.0 branch, which as lead me to think they 
should work everywhere. I've fixed them now, and made sure they run from other 
versions, too.

I've made several more small improvements, most are cosmetic, related to your 
comments, or just API improvements (like switch from {{int... to int i, int... 
more}} to avoid situations where people would supply no IDs and expect it'd run 
on all instances).


was (Author: ifesdjeen):
[~dcapwell] Thanks for one more pass. Addressed remaining review points. I did 
run upgrade dtests, but only from 4.0 branch, which as lead me to think they 
should work everywhere. I've fixed them now, and made sure they run from other 
versions, too.

I've made several more small improvements, most are cosmetic, related to your 
comments, or just API improvements (like switch from {{int... }} to {{int i, 
int... more}} to avoid situations where people would supply no IDs and expect 
it'd run on all instances).

> Improve machinery for testing consistency in presence of range movements
> 
>
> Key: CASSANDRA-15935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15935
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
>
> Currently, we can test range movements only by adding and bootstrapping a new 
> node. This is both inefficient and insufficient for large-scale tests. We 
> need a possibility to dynamically change ring ownership over the lifetime of 
> cluster, with a flexibility to changing gossip status of the node from 
> perspective of other participants, adding and removing nodes from other 
> nodes' views on demand.



--
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-16217) Minimal 4.0 COMPACT STORAGE backport

2020-10-20 Thread Alex Petrov (Jira)
Alex Petrov created CASSANDRA-16217:
---

 Summary: Minimal 4.0 COMPACT STORAGE backport
 Key: CASSANDRA-16217
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16217
 Project: Cassandra
  Issue Type: Bug
Reporter: Alex Petrov
Assignee: Alex Petrov


There are several behavioural changes related to compact storage, and these 
differences are larger than most of us have anticipated: we first thought 
there’ll be that “appearing column”, but there’s implicit nulls in clusterings 
thing, and row vs column deletion.

Some of the recent issues on the subject are: CASSANDRA-16048, which allows to 
ignore these differences. The other one was trying to improve user experience 
of anyone still using compact storage: CASSANDRA-15811.

Easily reproducible differernces are:

(1) hidden columns show up, which breaks SELECT * queries
 (2) DELETE v and UPDATE v WITH TTL would result into row removals in non-dense 
compact tables (CASSANDRA-16069)
 (3) INSERT allows skipping clusterings, which are filled with nulls by default.

Some of these are tricky to support, as 15811 has shown. Anyone on OSS side who 
might want to upgrade to 4.0 while still using compact storage might be 
affected by being forced into one of these behaviours.

Possible solutions are to document these behaviours, or to bring back a minimal 
set of COMPACT STORAGE to keep supporting these.

It looks like it is possible to leave some of the functionality related to 
DENSE flag and allow it to be present in 4.0, but only for these three (and 
potential related, however not direrclty visible) cases.

[~e.dimitrova] since you were working on removal on compact storage, wanted to 
reassure that this is not a revert of your patch. On contrary: your patch was 
instrumental in identifying the right places.

cc [~slebresne] [~aleksey] [~benedict] [~marcuse]

Preliminary patch: [https://github.com/apache/cassandra/pull/785]



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-15944:
---
  Fix Version/s: (was: 4.0-beta)
 4.0-beta3
Source Control Link: 
https://github.com/apache/cassandra-builds/commit/1b42de84695589e0e44f891b7ce7453da82dd470
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever edited comment on CASSANDRA-15944 at 10/20/20, 4:07 PM:
---

Used this approach to maintain build numbers after deleting the jobs… 
(important to keep results separated on nightlies.a.o)
https://stackoverflow.com/a/33495326 


was (Author: michaelsembwever):
Used this approach to maintain build numbers after deleting the jobs…
https://stackoverflow.com/a/33495326 

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-15944:


Used this approach to maintain build numbers after deleting the jobs…
https://stackoverflow.com/a/33495326 

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-builds] branch trunk updated: ASF CI unit tests on JDK11

2020-10-20 Thread mck
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 1b42de8  ASF CI unit tests on JDK11
1b42de8 is described below

commit 1b42de84695589e0e44f891b7ce7453da82dd470
Author: Mick Semb Wever 
AuthorDate: Tue Oct 20 11:20:06 2020 +0200

ASF CI unit tests on JDK11

 patch by Mick Semb Wever; reviewed by Brandon Williams CASSANDRA-15944
---
 jenkins-dsl/cassandra_job_dsl_seed.groovy | 38 ++-
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy 
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index f779d24..607d612 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -180,12 +180,10 @@ matrixJob('Cassandra-template-artifacts') {
 /**
  * Ant test template
  */
-job('Cassandra-template-test') {
+matrixJob('Cassandra-template-test') {
 disabled(true)
 description(jobDescription)
 concurrentBuild()
-jdk(jdkLabel)
-label(slaveLabel)
 compressBuildLog()
 logRotator {
 numToKeep(10)
@@ -468,9 +466,17 @@ cassandraBranches.each {
 println("Skipping ${targetName} on branch ${branchName}")
 
 } else {
-job("${jobNamePrefix}-${targetName}") {
+matrixJob("${jobNamePrefix}-${targetName}") {
 disabled(false)
 using('Cassandra-template-test')
+axes {
+if (branchName == 'trunk') {
+jdk(jdkLabel,'jdk_11_latest')
+} else {
+jdk(jdkLabel)
+}
+label('label', slaveLabel)
+}
 configure { node ->
 node / scm / branches / 'hudson.plugins.git.BranchSpec' / 
name(branchName)
 }
@@ -592,7 +598,7 @@ matrixJob('Cassandra-devbranch-artifacts') {
 description(jobDescription)
 concurrentBuild()
 axes {
-jdk('jdk_1.8_latest','jdk_11_latest')
+jdk(jdkLabel,'jdk_11_latest')
 label('label', slaveLabel)
 }
 compressBuildLog()
@@ -666,11 +672,13 @@ matrixJob('Cassandra-devbranch-artifacts') {
 testTargets.each {
 def targetName = it
 
-job("Cassandra-devbranch-${targetName}") {
+matrixJob("Cassandra-devbranch-${targetName}") {
 description(jobDescription)
 concurrentBuild()
-jdk(jdkLabel)
-label(slaveLabel)
+axes {
+jdk(jdkLabel,'jdk_11_latest')
+label('label', slaveLabel)
+}
 compressBuildLog()
 logRotator {
 numToKeep(10)
@@ -766,12 +774,6 @@ dtestTargets.each {
 description(jobDescription)
 concurrentBuild()
 compressBuildLog()
-jdk(jdkLabel)
-if (targetName == 'dtest-large') {
-label(largeSlaveLabel)
-} else {
-label(slaveLabel)
-}
 compressBuildLog()
 logRotator {
 numToKeep(10)
@@ -799,8 +801,12 @@ dtestTargets.each {
 }
 (1..splits).each { values << it.toString() }
 text('split', values)
-label('label', slaveLabel)
-}
+if (targetName == 'dtest-large') {
+label(largeSlaveLabel)
+} else {
+label(slaveLabel)
+}
+ }
 properties {
 githubProjectUrl(githubRepo)
 priorityJobProperty {


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



[cassandra-builds] branch trunk updated: ASF CI unit tests on JDK11

2020-10-20 Thread mck
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 1b42de8  ASF CI unit tests on JDK11
1b42de8 is described below

commit 1b42de84695589e0e44f891b7ce7453da82dd470
Author: Mick Semb Wever 
AuthorDate: Tue Oct 20 11:20:06 2020 +0200

ASF CI unit tests on JDK11

 patch by Mick Semb Wever; reviewed by Brandon Williams CASSANDRA-15944
---
 jenkins-dsl/cassandra_job_dsl_seed.groovy | 38 ++-
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy 
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index f779d24..607d612 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -180,12 +180,10 @@ matrixJob('Cassandra-template-artifacts') {
 /**
  * Ant test template
  */
-job('Cassandra-template-test') {
+matrixJob('Cassandra-template-test') {
 disabled(true)
 description(jobDescription)
 concurrentBuild()
-jdk(jdkLabel)
-label(slaveLabel)
 compressBuildLog()
 logRotator {
 numToKeep(10)
@@ -468,9 +466,17 @@ cassandraBranches.each {
 println("Skipping ${targetName} on branch ${branchName}")
 
 } else {
-job("${jobNamePrefix}-${targetName}") {
+matrixJob("${jobNamePrefix}-${targetName}") {
 disabled(false)
 using('Cassandra-template-test')
+axes {
+if (branchName == 'trunk') {
+jdk(jdkLabel,'jdk_11_latest')
+} else {
+jdk(jdkLabel)
+}
+label('label', slaveLabel)
+}
 configure { node ->
 node / scm / branches / 'hudson.plugins.git.BranchSpec' / 
name(branchName)
 }
@@ -592,7 +598,7 @@ matrixJob('Cassandra-devbranch-artifacts') {
 description(jobDescription)
 concurrentBuild()
 axes {
-jdk('jdk_1.8_latest','jdk_11_latest')
+jdk(jdkLabel,'jdk_11_latest')
 label('label', slaveLabel)
 }
 compressBuildLog()
@@ -666,11 +672,13 @@ matrixJob('Cassandra-devbranch-artifacts') {
 testTargets.each {
 def targetName = it
 
-job("Cassandra-devbranch-${targetName}") {
+matrixJob("Cassandra-devbranch-${targetName}") {
 description(jobDescription)
 concurrentBuild()
-jdk(jdkLabel)
-label(slaveLabel)
+axes {
+jdk(jdkLabel,'jdk_11_latest')
+label('label', slaveLabel)
+}
 compressBuildLog()
 logRotator {
 numToKeep(10)
@@ -766,12 +774,6 @@ dtestTargets.each {
 description(jobDescription)
 concurrentBuild()
 compressBuildLog()
-jdk(jdkLabel)
-if (targetName == 'dtest-large') {
-label(largeSlaveLabel)
-} else {
-label(slaveLabel)
-}
 compressBuildLog()
 logRotator {
 numToKeep(10)
@@ -799,8 +801,12 @@ dtestTargets.each {
 }
 (1..splits).each { values << it.toString() }
 text('split', values)
-label('label', slaveLabel)
-}
+if (targetName == 'dtest-large') {
+label(largeSlaveLabel)
+} else {
+label(slaveLabel)
+}
+ }
 properties {
 githubProjectUrl(githubRepo)
 priorityJobProperty {


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



[jira] [Assigned] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta

2020-10-20 Thread Alex Petrov (Jira)


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

Alex Petrov reassigned CASSANDRA-15299:
---

Assignee: Sam Tunnicliffe  (was: Alex Petrov)

> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol 
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Sam Tunnicliffe
>Priority: Normal
>  Labels: protocolv5
> Fix For: 4.0-alpha
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it 
> introduced checksumming/CRC32 to request and response bodies. It’s an 
> important step forward, but it doesn’t cover the entire stream. In 
> particular, the message header is not covered by a checksum or a crc, which 
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of 
> computing the CRC32 on the bytes written on the wire - losing the properties 
> of the CRC32. In some cases, due to this sequencing, attempting to decompress 
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order, 
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for 
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since 
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression 
> operate on individual message bodies rather than frames of multiple complete 
> messages. In reality, this has several important additional downsides. To 
> name a couple:
> # For compression, we are getting poor compression ratios for smaller 
> messages - when operating on tiny sequences of bytes. In reality, for most 
> small requests and responses we are discarding the compressed value as it’d 
> be smaller than the uncompressed one - incurring both redundant allocations 
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages. 
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the 
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we 
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode 
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed, 
> and that we do it before native protocol v5 graduates from beta. See 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
>  and 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-15944:
---
Reviewers: Brandon Williams, Michael Semb Wever
   Status: Review In Progress  (was: Patch Available)

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-15944:
---
Status: Ready to Commit  (was: Review In Progress)

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15962) Digest for some queries is different depending whether the data are retrieved from sstable or memtable

2020-10-20 Thread Jacek Lewandowski (Jira)


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

Jacek Lewandowski commented on CASSANDRA-15962:
---

Here is the PR against trunk, now it works, additional change in 
{{BTreeRow:filter}} - added back {{|| !filter.allFetchedColumnsAreQueried()}} 
to {{mayFilterColumns}} initializer

https://github.com/apache/cassandra/pull/784


> Digest for some queries is different depending whether the data are retrieved 
> from sstable or memtable
> --
>
> Key: CASSANDRA-15962
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15962
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0, 3.11.x
>
> Attachments: DigestTest.java
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Not sure into which category should I assign this ticket.
>  
> Basically when reading using certain column filters, the digest is different 
> depending whether we read from sstable and memtable. This happens on 
> {{trunk}} and {{cassandra-3.11}} branches. However it works properly on 
> {{cassandra-3.0}} branch.
>  
> I'm attaching a simple test for trunk to demonstrate what I mean. 
>  
> Please verify my test and my conclusions
>  



--
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-16061) transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup

2020-10-20 Thread Adam Holmberg (Jira)


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

Adam Holmberg commented on CASSANDRA-16061:
---

I see. Did the thing you were chasing manifest the same symptoms? I did try 
reducing VM resources but just found it was creating timeouts due to trying to 
run four nodes in an unreasonable amount of resources.
I think I would still advocate for increasing this timeout based on what we're 
seeing in ci-cassandra. In the mean time I will set back to open in case 
someone else wants to take a shot at reproducing.

> transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup
> 
>
> Key: CASSANDRA-16061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16061
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Failing here, also locally:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/312/workflows/da4ce69c-e778-467e-b9f3-27ab166a8321/jobs/1945]



--
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-16061) transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup

2020-10-20 Thread Adam Holmberg (Jira)


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

Adam Holmberg updated CASSANDRA-16061:
--
Status: Open  (was: Patch Available)

> transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup
> 
>
> Key: CASSANDRA-16061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16061
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Failing here, also locally:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/312/workflows/da4ce69c-e778-467e-b9f3-27ab166a8321/jobs/1945]



--
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-16167) Rename master branch to trunk in cassandra-sidecar

2020-10-20 Thread Chris Lohfink (Jira)


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

Chris Lohfink commented on CASSANDRA-16167:
---

Thanks!

> Rename master branch to trunk in cassandra-sidecar
> --
>
> Key: CASSANDRA-16167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16167
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Priority: Normal
>




--
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-15582) 4.0 quality testing: metrics

2020-10-20 Thread Benjamin Lerer (Jira)


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

Benjamin Lerer updated CASSANDRA-15582:
---
Description: 
The goal of this ticket is to have a proper testing of the different metrics 
exposed via JMX, and to ensure that metrics that are not in used in 4.0 have 
been properly deprecated.

The following table show the current status of the metric tests and can be used 
to track the progress of that ticket:

|| Metrics || Status || test types || JIRA tickets ||
| Batch | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15718 | 
| BufferPool | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15773 |
| Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
| Client | {color:#DE350B}*TESTS MISSING*{color}| unit tests | CASSANDRA-16216 |
| ClientRequest |{color:#DE350B}*NO TESTS*{color} | in-jvm tests | 
CASSANDRA-16183 |
| ClientRequestSize | {color:#00875A}*COVERED*{color} | unit tests | 
CASSANDRA-16184 |
| Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
| CommitLog | {color:#DE350B}*TESTS MISSING*{color} | unit tests | 
CASSANDRA-16185 |
| Compaction | {color:#DE350B}*TESTS MISSING*{color} | unit tests | 
CASSANDRA-16192 |
| CQL | {color:#00875A}*COVERED*{color}| unit tests | |
| HintService | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16189 |
| Messaging/Internode| {color:#DE350B}*NO TESTS*{color} | in-jvm dtests | 
CASSANDRA-16193 |
| ReadRepair| {color:#DE350B}*TESTS MISSING*{color} | dtests,in-jvm dtests | 
CASSANDRA-16187 | 
| Repair | {color:#DE350B}*NO TESTS*{color} | in-jvm dtests | CASSANDRA-16191 |
| Storage | {color:#00875A}*COVERED*{color}| unit tests | |
| Streaming | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16190 |
| Keyspace | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests | 
CASSANDRA-16188 |
| Table | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests | 
CASSANDRA-16188 |
| ThreadPoolMetrics |{color:#DE350B}*NO TESTS*{color} | unit tests | 
CASSANDRA-16186 |


  was:
The goal of this ticket is to have a proper testing of the different metrics 
exposed via JMX, and to ensure that metrics that are not in used in 4.0 have 
been properly deprecated.

The following table show the current status of the metric tests and can be used 
to track the progress of that ticket:

|| Metrics || Status || test types || JIRA tickets ||
| Batch | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15718 | 
| BufferPool | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15773 |
| Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
| ClientRequest |{color:#DE350B}*NO TESTS*{color} | in-jvm tests | 
CASSANDRA-16183 |
| ClientRequestSize | {color:#00875A}*COVERED*{color} | unit tests | 
CASSANDRA-16184 |
| Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
| CommitLog | {color:#DE350B}*TESTS MISSING*{color} | unit tests | 
CASSANDRA-16185 |
| Compaction | {color:#DE350B}*TESTS MISSING*{color} | unit tests | 
CASSANDRA-16192 |
| CQL | {color:#00875A}*COVERED*{color}| unit tests | |
| HintService | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16189 |
| Messaging/Internode| {color:#DE350B}*NO TESTS*{color} | in-jvm dtests | 
CASSANDRA-16193 |
| ReadRepair| {color:#DE350B}*TESTS MISSING*{color} | dtests,in-jvm dtests | 
CASSANDRA-16187 | 
| Repair | {color:#DE350B}*NO TESTS*{color} | in-jvm dtests | CASSANDRA-16191 |
| Storage | {color:#00875A}*COVERED*{color}| unit tests | |
| Streaming | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16190 |
| Keyspace | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests | 
CASSANDRA-16188 |
| Table | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests | 
CASSANDRA-16188 |
| ThreadPoolMetrics |{color:#DE350B}*NO TESTS*{color} | unit tests | 
CASSANDRA-16186 |



> 4.0 quality testing: metrics
> 
>
> Key: CASSANDRA-15582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15582
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: Screen Shot 2020-04-07 at 5.47.17 PM.png
>
>
> The goal of this ticket is to have a proper testing of the different metrics 
> exposed via JMX, and to ensure that metrics that are not in used in 4.0 have 
> been properly deprecated.
> The following table show the current status of the metric tests and can be 
> used to track the progress of that ticket:
> || Metrics || Status || test types || JIRA tickets ||
> | Batch | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15718 | 
> | BufferPool | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-

[jira] [Updated] (CASSANDRA-16216) Add tests to cover ClientMetrics metrics

2020-10-20 Thread Benjamin Lerer (Jira)


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

Benjamin Lerer updated CASSANDRA-16216:
---
Status: Open  (was: Triage Needed)

> Add tests to cover ClientMetrics metrics
> 
>
> Key: CASSANDRA-16216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16216
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java, Test/unit
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 4.0-beta
>
>




--
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-16216) Add tests to cover ClientMetrics metrics

2020-10-20 Thread Sumanth Pasupuleti (Jira)


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

Sumanth Pasupuleti updated CASSANDRA-16216:
---
Change Category: Quality Assurance
 Complexity: Normal

> Add tests to cover ClientMetrics metrics
> 
>
> Key: CASSANDRA-16216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16216
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java, Test/unit
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 4.0-beta
>
>




--
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-16216) Add tests to cover ClientMetrics metrics

2020-10-20 Thread Sumanth Pasupuleti (Jira)
Sumanth Pasupuleti created CASSANDRA-16216:
--

 Summary: Add tests to cover ClientMetrics metrics
 Key: CASSANDRA-16216
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16216
 Project: Cassandra
  Issue Type: Improvement
  Components: Test/dtest/java, Test/unit
Reporter: Sumanth Pasupuleti
Assignee: Sumanth Pasupuleti






--
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-16216) Add tests to cover ClientMetrics metrics

2020-10-20 Thread Sumanth Pasupuleti (Jira)


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

Sumanth Pasupuleti updated CASSANDRA-16216:
---
Fix Version/s: 4.0-beta

> Add tests to cover ClientMetrics metrics
> 
>
> Key: CASSANDRA-16216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16216
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java, Test/unit
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 4.0-beta
>
>




--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Brandon Williams (Jira)


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

Brandon Williams commented on CASSANDRA-15944:
--

LGTM, +1

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15935) Improve machinery for testing consistency in presence of range movements

2020-10-20 Thread Alex Petrov (Jira)


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

Alex Petrov commented on CASSANDRA-15935:
-

[~dcapwell] Thanks for one more pass. Addressed remaining review points. I did 
run upgrade dtests, but only from 4.0 branch, which as lead me to think they 
should work everywhere. I've fixed them now, and made sure they run from other 
versions, too.

I've made several more small improvements, most are cosmetic, related to your 
comments, or just API improvements (like switch from {{int... }} to {{int i, 
int... more}} to avoid situations where people would supply no IDs and expect 
it'd run on all instances).

> Improve machinery for testing consistency in presence of range movements
> 
>
> Key: CASSANDRA-15935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15935
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
>
> Currently, we can test range movements only by adding and bootstrapping a new 
> node. This is both inefficient and insufficient for large-scale tests. We 
> need a possibility to dynamically change ring ownership over the lifetime of 
> cluster, with a flexibility to changing gossip status of the node from 
> perspective of other participants, adding and removing nodes from other 
> nodes' views on demand.



--
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-16170) Rename master branch to trunk in cassandra-harry

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever reassigned CASSANDRA-16170:
--

Assignee: (was: Michael Semb Wever)

> Rename master branch to trunk in cassandra-harry
> 
>
> Key: CASSANDRA-16170
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16170
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Priority: Normal
>
> ref: 
> https://the-asf.slack.com/archives/CK23JSY2K/p1603178258238100?thread_ts=1603177458.237800&cid=CK23JSY2K



--
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-16169) Rename master branch to trunk in cassandra-in-jvm-dtest-api

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever reassigned CASSANDRA-16169:
--

Assignee: (was: Michael Semb Wever)

> Rename master branch to trunk in cassandra-in-jvm-dtest-api
> ---
>
> Key: CASSANDRA-16169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16169
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Priority: Normal
>




--
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-16167) Rename master branch to trunk in cassandra-sidecar

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever reassigned CASSANDRA-16167:
--

Assignee: (was: Michael Semb Wever)

> Rename master branch to trunk in cassandra-sidecar
> --
>
> Key: CASSANDRA-16167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16167
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Priority: Normal
>




--
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-16170) Rename master branch to trunk in cassandra-harry

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-16170:
---
Resolution: Fixed
Status: Resolved  (was: Triage Needed)

> Rename master branch to trunk in cassandra-harry
> 
>
> Key: CASSANDRA-16170
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16170
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> ref: 
> https://the-asf.slack.com/archives/CK23JSY2K/p1603178258238100?thread_ts=1603177458.237800&cid=CK23JSY2K



--
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-16170) Rename master branch to trunk in cassandra-harry

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-16170:


trunk branch is now default. the master branch deleted.
fyi [~ifesdjeen]

> Rename master branch to trunk in cassandra-harry
> 
>
> Key: CASSANDRA-16170
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16170
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> ref: 
> https://the-asf.slack.com/archives/CK23JSY2K/p1603178258238100?thread_ts=1603177458.237800&cid=CK23JSY2K



--
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-harry] branch trunk updated (4dbf969 -> 7360458)

2020-10-20 Thread mck
This is an automated email from the ASF dual-hosted git repository.

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


from 4dbf969  Initialize empty repository
 add 1d7f66e  Harry: generator library and extensible framework for fuzz 
testing Apache Cassandra
 add 3705021  Readme improvements
 add c950d3a  Add license headers and NOTICE according to PMC 
review/feedback.
 add a8270c7  Patch introduces the following changes:
 add b6921d4  Ninja: Add asf.yml
 add 6adedb0  Update README.md
 add 4fc41eb  Rename .asf.yml to .asf.yaml
 add 372e5f0  Add a renamed .asf.yaml back
 add 7360458  Update jackson dependency to 2.11.3 to force yaml to 1.26

No new revisions were added by this update.

Summary of changes:
 .asf.yaml  |  10 +
 LICENSE.txt| 209 +
 Makefile   |  27 +
 NOTICE.txt |   5 +
 README.md  | 541 
 conf/example.yaml  |  90 ++
 docker/Dockerfile.local|  35 +
 docker/run-local.sh|  17 +
 docker/run.sh  | 105 +++
 harry-core/pom.xml |  86 ++
 harry-core/src/harry/core/Configuration.java   | 908 +
 harry-core/src/harry/core/Run.java |  73 ++
 .../src/harry/corruptor/AddExtraRowCorruptor.java  |  90 ++
 .../src/harry/corruptor/ChangeValueCorruptor.java  |  85 ++
 .../src/harry/corruptor/HideRowCorruptor.java  |  49 ++
 .../src/harry/corruptor/HideValueCorruptor.java|  74 ++
 .../harry/corruptor/QueryResponseCorruptor.java|  71 ++
 harry-core/src/harry/corruptor/RowCorruptor.java   |  50 ++
 .../src/harry/corruptor/ShowValueCorruptor.java|  77 ++
 harry-core/src/harry/data/ResultSetRow.java|  60 ++
 harry-core/src/harry/ddl/ColumnSpec.java   | 338 
 harry-core/src/harry/ddl/SchemaGenerators.java | 407 +
 harry-core/src/harry/ddl/SchemaSpec.java   | 330 
 harry-core/src/harry/generators/Bijections.java| 416 ++
 .../src/harry/generators/BooleanGenerator.java |  29 +
 harry-core/src/harry/generators/Bytes.java |  42 +
 harry-core/src/harry/generators/Collections.java   | 248 ++
 .../src/harry/generators/DataGenerators.java   | 468 +++
 harry-core/src/harry/generators/Generator.java | 131 +++
 harry-core/src/harry/generators/Generators.java|  92 +++
 harry-core/src/harry/generators/PCGFastPure.java   | 145 
 harry-core/src/harry/generators/PcgRSUFast.java|  81 ++
 .../src/harry/generators/RandomGenerator.java  |  87 ++
 harry-core/src/harry/generators/RngUtils.java  |  96 +++
 .../src/harry/generators/StringBijection.java  | 171 
 harry-core/src/harry/generators/Surjections.java   | 167 
 .../generators/distribution/Distribution.java  | 137 
 harry-core/src/harry/model/DataTracker.java| 123 +++
 .../src/harry/model/DescriptorSelectorBuilder.java | 104 +++
 harry-core/src/harry/model/DoNothingModel.java |  38 +
 harry-core/src/harry/model/ExhaustiveChecker.java  | 647 +++
 harry-core/src/harry/model/Model.java  |  69 ++
 harry-core/src/harry/model/OpSelectors.java| 627 ++
 harry-core/src/harry/model/QuiescentChecker.java   | 118 +++
 harry-core/src/harry/model/SelectHelper.java   | 127 +++
 .../harry/model/StatelessVisibleRowsChecker.java   | 124 +++
 harry-core/src/harry/model/VisibleRowsChecker.java | 248 ++
 .../model/clock/ApproximateMonotonicClock.java | 280 +++
 harry-core/src/harry/model/clock/OffsetClock.java  |  61 ++
 harry-core/src/harry/model/sut/NoOpSut.java|  44 +
 harry-core/src/harry/model/sut/PrintlnSut.java |  48 ++
 .../src/harry/model/sut/SystemUnderTest.java   |  54 ++
 .../src/harry/operations/CompiledStatement.java|  56 ++
 harry-core/src/harry/operations/DeleteHelper.java  | 127 +++
 harry-core/src/harry/operations/Relation.java  | 350 
 harry-core/src/harry/operations/WriteHelper.java   | 148 
 harry-core/src/harry/reconciler/Reconciler.java| 250 ++
 .../src/harry/runner/AbstractPartitionVisitor.java | 103 +++
 .../runner/DefaultPartitionVisitorFactory.java | 198 +
 harry-core/src/harry/runner/DefaultRowVisitor.java |  68 ++
 harry-core/src/harry/runner/PartitionVisitor.java  |  26 +
 harry-core/src/harry/runner/Query.java | 298 +++
 harry-core/src/harry/runner/QuerySelector.java | 300 +++
 harry-core/src/harry/runner/RowVisitor.java|  61 ++
 harry-core/src/harry/runner/Runner.java| 396 +
 harry-core/src/harry/runner/Validator.java | 119 +++
 harry-cor

[jira] [Assigned] (CASSANDRA-16188) Add more tests to cover Keyspace and Table metrics

2020-10-20 Thread Sumanth Pasupuleti (Jira)


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

Sumanth Pasupuleti reassigned CASSANDRA-16188:
--

Assignee: Sumanth Pasupuleti

> Add more tests to cover Keyspace and Table metrics 
> ---
>
> Key: CASSANDRA-16188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16188
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java, Test/unit
>Reporter: Benjamin Lerer
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Several Keyspace and Table related metrics are currently not tested.



--
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-16167) Rename master branch to trunk in cassandra-sidecar

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-16167:
---
Resolution: Fixed
Status: Resolved  (was: Triage Needed)

> Rename master branch to trunk in cassandra-sidecar
> --
>
> Key: CASSANDRA-16167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16167
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>




--
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-16167) Rename master branch to trunk in cassandra-sidecar

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-16167:


trunk is now default. the master branch deleted.
fyi [~rustyrazorblade] [~djoshi] [~clohfink] [~andrew.tolbert]

> Rename master branch to trunk in cassandra-sidecar
> --
>
> Key: CASSANDRA-16167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16167
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>




--
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] (CASSANDRASC-27) CDC reader in Apache Cassandra Sidecar

2020-10-20 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot updated CASSANDRASC-27:
--
Labels: pull-request-available  (was: )

> CDC reader in Apache Cassandra Sidecar
> --
>
> Key: CASSANDRASC-27
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-27
> Project: Sidecar for Apache Cassandra
>  Issue Type: New Feature
>Reporter: Vinay Chella
>Assignee: Tharanga Sampath Gamaethige
>Priority: Normal
>  Labels: pull-request-available
>
> Apache Cassandra has the CDC (Change Data Capture) features since 3.8. This 
> is further enhanced with (CASS-12148) in Cassandra 4.0.
> However, there’s no generally available mechanism to stream changes out of a 
> Cassandra database; hence the utility of this feature is limited if not 
> absent.
> Many applications use Cassandra as their primary data store. For various 
> reasons(Caching, analyzing, indexing, etc), this data needs to be 
> synchronized with derived/secondary data stores.  We would like to emit 
> change streams in real-time to consumers so that changes to Cassandra can be 
> used for various purposes.
> *Goals*
>  * Enhance Apache Cassandra sidecar with a CDC reader that can read and emit 
> changes in real-time. Priority for the initial implementation is safety and 
> correctness, performance enhancements will follow in subsequent iterations
> *Nongoals*
>  * Modify Cassandra storage engine to emit changes
>  
> *Proposal*
> [https://docs.google.com/document/d/11YywfJTm29szZOVOSRbtfvClbmMQtJ8WyCB7_CUgo-U/edit?usp=sharing]
>  
> *PR*
> https://github.com/apache/cassandra-sidecar/pull/16
>  



--
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-16169) Rename master branch to trunk in cassandra-in-jvm-dtest-api

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-16169:
---
Resolution: Fixed
Status: Resolved  (was: Triage Needed)

> Rename master branch to trunk in cassandra-in-jvm-dtest-api
> ---
>
> Key: CASSANDRA-16169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16169
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>




--
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-16169) Rename master branch to trunk in cassandra-in-jvm-dtest-api

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-16169:


fyi [~ifesdjeen] [~jwest] [~marcuse] [~yifanc] [~dcapwell]

> Rename master branch to trunk in cassandra-in-jvm-dtest-api
> ---
>
> Key: CASSANDRA-16169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16169
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>




--
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-16169) Rename master branch to trunk in cassandra-in-jvm-dtest-api

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-16169:


trunk is now default. master branch is deleted.

> Rename master branch to trunk in cassandra-in-jvm-dtest-api
> ---
>
> Key: CASSANDRA-16169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16169
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>




--
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-15962) Digest for some queries is different depending whether the data are retrieved from sstable or memtable

2020-10-20 Thread Jacek Lewandowski (Jira)


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

Jacek Lewandowski commented on CASSANDRA-15962:
---

Unfortunately, it does not work on trunk (regardless the code is patched or 
not, the test fails). I need to investigate that more

> Digest for some queries is different depending whether the data are retrieved 
> from sstable or memtable
> --
>
> Key: CASSANDRA-15962
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15962
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0, 3.11.x
>
> Attachments: DigestTest.java
>
>
> Not sure into which category should I assign this ticket.
>  
> Basically when reading using certain column filters, the digest is different 
> depending whether we read from sstable and memtable. This happens on 
> {{trunk}} and {{cassandra-3.11}} branches. However it works properly on 
> {{cassandra-3.0}} branch.
>  
> I'm attaching a simple test for trunk to demonstrate what I mean. 
>  
> Please verify my test and my conclusions
>  



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-15944:
---
Reviewers:   (was: Michael Semb Wever)

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-15944:


Have tested with a local jenkins installation.
Confirmed that jobs run and that the workspace directories do not contain 
spaces.

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15962) Digest for some queries is different depending whether the data are retrieved from sstable or memtable

2020-10-20 Thread Jacek Lewandowski (Jira)


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

Jacek Lewandowski commented on CASSANDRA-15962:
---

{quote}Could you include the DigestTest you wrote into the PR?{quote}

Sure



{quote}Changes to SelectStatement (special casing of the filter for super 
columns on range queries, as is done for slice ones) looks legit, but unrelated 
and a problem on 3.0. We should either split to another ticket (probably 
ideal), or have a 3.0 branch with that fix. It would also be good to have a 
test (one that shows the problem that exists and is fixed by this 
change).{quote}

{quote}Similarly, the change to AbstractReadExecutor also look legit but 
unrelated and exists in 3.0. That one is pretty minor since I don't think it 
has visible consequence, so not worth a ticket of its own, but would nice to 
include with whatever we do for my previous point so it gets into 3.0.{quote}

I agree that those changes are unrelated, I've removed them



{quote}BTreeRow#filter: we should reuse/extract the 
!queriedByUserTester.test(column) test from the isSkippable initializer as 
value for shouldSkipValue instead of redoing the work by calling 
!filter.fetchedColumnIsQueried(column).{quote}

Ok, I've done that



{quote}I'd store the result of filter.fetchedColumnIsQueried(column)) in a 
variable at the beginning of the function, to avoid potentially repeating the 
call multiple times. Mostly because it'll be imo more readable, but it also 
avoid bad cases where we repeat it for vary many cells.{quote}

Ok, I've done that



{quote}Nit: The path != null in the shouldSkipValue initializer is unecessary: 
cells of complex columns are guaranteed to have a non-null path (see assertion 
in BufferCell ctor).{quote}

Ok, I've removed that



{quote}It would be nice to avoid the repetition of 
cellTest.fetchedCellIsQueried(path) as well, readability wise.{quote}

Ok, I've done that


> Digest for some queries is different depending whether the data are retrieved 
> from sstable or memtable
> --
>
> Key: CASSANDRA-15962
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15962
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0, 3.11.x
>
> Attachments: DigestTest.java
>
>
> Not sure into which category should I assign this ticket.
>  
> Basically when reading using certain column filters, the digest is different 
> depending whether we read from sstable and memtable. This happens on 
> {{trunk}} and {{cassandra-3.11}} branches. However it works properly on 
> {{cassandra-3.0}} branch.
>  
> I'm attaching a simple test for trunk to demonstrate what I mean. 
>  
> Please verify my test and my conclusions
>  



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-15944:
---
Status: Patch Available  (was: In Progress)

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-15944:


PR @ 
https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:mck/15944
This commit will require all existing test jobs to be deleted/renamed as the 
test job type changes from {{job}} to {{matrixJob}}.

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15582) 4.0 quality testing: metrics

2020-10-20 Thread Benjamin Lerer (Jira)


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

Benjamin Lerer updated CASSANDRA-15582:
---
Description: 
The goal of this ticket is to have a proper testing of the different metrics 
exposed via JMX, and to ensure that metrics that are not in used in 4.0 have 
been properly deprecated.

The following table show the current status of the metric tests and can be used 
to track the progress of that ticket:

|| Metrics || Status || test types || JIRA tickets ||
| Batch | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15718 | 
| BufferPool | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15773 |
| Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
| ClientRequest |{color:#DE350B}*NO TESTS*{color} | in-jvm tests | 
CASSANDRA-16183 |
| ClientRequestSize | {color:#00875A}*COVERED*{color} | unit tests | 
CASSANDRA-16184 |
| Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
| CommitLog | {color:#DE350B}*TESTS MISSING*{color} | unit tests | 
CASSANDRA-16185 |
| Compaction | {color:#DE350B}*TESTS MISSING*{color} | unit tests | 
CASSANDRA-16192 |
| CQL | {color:#00875A}*COVERED*{color}| unit tests | |
| HintService | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16189 |
| Messaging/Internode| {color:#DE350B}*NO TESTS*{color} | in-jvm dtests | 
CASSANDRA-16193 |
| ReadRepair| {color:#DE350B}*TESTS MISSING*{color} | dtests,in-jvm dtests | 
CASSANDRA-16187 | 
| Repair | {color:#DE350B}*NO TESTS*{color} | in-jvm dtests | CASSANDRA-16191 |
| Storage | {color:#00875A}*COVERED*{color}| unit tests | |
| Streaming | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16190 |
| Keyspace | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests | 
CASSANDRA-16188 |
| Table | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests | 
CASSANDRA-16188 |
| ThreadPoolMetrics |{color:#DE350B}*NO TESTS*{color} | unit tests | 
CASSANDRA-16186 |


  was:
The goal of this ticket is to have a proper testing of the different metrics 
exposed via JMX, and to ensure that metrics that are not in used in 4.0 have 
been properly deprecated.

The following table show the current status of the metric tests and can be used 
to track the progress of that ticket:

|| Metrics || Status || test types || JIRA tickets ||
| Batch | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15718 | 
| BufferPool | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15773 |
| Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
| ClientRequest |{color:#DE350B}*NO TESTS*{color} | in-jvm tests | 
CASSANDRA-16183 |
| ClientRequestSize | {color:#DE350B}*CAN BE IMPROVED*{color} | unit tests | 
CASSANDRA-16184 |
| Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
| CommitLog | {color:#DE350B}*TESTS MISSING*{color} | unit tests | 
CASSANDRA-16185 |
| Compaction | {color:#DE350B}*TESTS MISSING*{color} | unit tests | 
CASSANDRA-16192 |
| CQL | {color:#00875A}*COVERED*{color}| unit tests | |
| HintService | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16189 |
| Messaging/Internode| {color:#DE350B}*NO TESTS*{color} | in-jvm dtests | 
CASSANDRA-16193 |
| ReadRepair| {color:#DE350B}*TESTS MISSING*{color} | dtests,in-jvm dtests | 
CASSANDRA-16187 | 
| Repair | {color:#DE350B}*NO TESTS*{color} | in-jvm dtests | CASSANDRA-16191 |
| Storage | {color:#00875A}*COVERED*{color}| unit tests | |
| Streaming | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16190 |
| Keyspace | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests | 
CASSANDRA-16188 |
| Table | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests | 
CASSANDRA-16188 |
| ThreadPoolMetrics |{color:#DE350B}*NO TESTS*{color} | unit tests | 
CASSANDRA-16186 |



> 4.0 quality testing: metrics
> 
>
> Key: CASSANDRA-15582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15582
> Project: Cassandra
>  Issue Type: Task
>  Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: Screen Shot 2020-04-07 at 5.47.17 PM.png
>
>
> The goal of this ticket is to have a proper testing of the different metrics 
> exposed via JMX, and to ensure that metrics that are not in used in 4.0 have 
> been properly deprecated.
> The following table show the current status of the metric tests and can be 
> used to track the progress of that ticket:
> || Metrics || Status || test types || JIRA tickets ||
> | Batch | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15718 | 
> | BufferPool | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15773 
> |
> | Cache | {color:#00875A}*COVERED*{color} | unit tests | CAS

[jira] [Updated] (CASSANDRA-16184) ClientRequestSize metric tests should be improved

2020-10-20 Thread Benjamin Lerer (Jira)


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

Benjamin Lerer updated CASSANDRA-16184:
---
  Fix Version/s: (was: 4.0-beta)
 4.0-beta3
Source Control Link: 
https://github.com/apache/cassandra/commit/c87bc233c901d3f81649a0172cbc6b078b287ad0
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed into trunk at c87bc233c901d3f81649a0172cbc6b078b287ad0

> ClientRequestSize metric tests should be improved
> -
>
> Key: CASSANDRA-16184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16184
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> The current test for {{ClientRequestSize}} only test that the metrics are 
> updated on request. It does not test that the returned values are the 
> expected ones. Some test comparisons are done with the wrong values.



--
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-16184) ClientRequestSize metric tests should be improved

2020-10-20 Thread Benjamin Lerer (Jira)


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

Benjamin Lerer updated CASSANDRA-16184:
---
Status: Ready to Commit  (was: Review In Progress)

Thanks for the review [~Bereng]

> ClientRequestSize metric tests should be improved
> -
>
> Key: CASSANDRA-16184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16184
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The current test for {{ClientRequestSize}} only test that the metrics are 
> updated on request. It does not test that the returned values are the 
> expected ones. Some test comparisons are done with the wrong values.



--
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: Improve ClientRequestSizeMetrics test

2020-10-20 Thread blerer
This is an automated email from the ASF dual-hosted git repository.

blerer 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 c87bc23  Improve ClientRequestSizeMetrics test
c87bc23 is described below

commit c87bc233c901d3f81649a0172cbc6b078b287ad0
Author: Benjamin Lerer 
AuthorDate: Wed Oct 7 17:52:37 2020 +0200

Improve ClientRequestSizeMetrics test

patch by Benjamin Lerer; reviewed by Berenguer Blasi for CASSANDRA-16184

The test was only checking that the metrics where updated but was not
testing if the updates were correct.

This patch also fix the ClearableHistogram.clear method (through an ugly
hack) that was not clearing the histogram count.
---
 .../cassandra/metrics/ClearableHistogram.java  |  34 ++
 .../metrics/ClientRequestSizeMetrics.java  |   2 +-
 src/java/org/apache/cassandra/transport/Frame.java |   2 +-
 .../metrics/ClientRequestSizeMetricsTest.java  | 124 +
 .../cassandra/transport/ServerMetricsTest.java |  65 ---
 5 files changed, 160 insertions(+), 67 deletions(-)

diff --git a/src/java/org/apache/cassandra/metrics/ClearableHistogram.java 
b/src/java/org/apache/cassandra/metrics/ClearableHistogram.java
index 4a081d8..f83ef82 100644
--- a/src/java/org/apache/cassandra/metrics/ClearableHistogram.java
+++ b/src/java/org/apache/cassandra/metrics/ClearableHistogram.java
@@ -17,6 +17,10 @@
  */
 package org.apache.cassandra.metrics;
 
+import java.lang.reflect.Field;
+import java.lang.reflect.Method;
+import java.util.concurrent.atomic.LongAdder;
+
 import com.google.common.annotations.VisibleForTesting;
 
 import com.codahale.metrics.Histogram;
@@ -43,6 +47,36 @@ public class ClearableHistogram extends Histogram
 @VisibleForTesting
 public void clear()
 {
+clearCount();
 reservoirRef.clear();
 }
+
+private void clearCount()
+{
+// We have unfortunately no access to the count field so we need to 
use reflection to ensure that it is cleared.
+// I hate that as it is fragile and pretty ugly but we only use that 
method for tests and it should fail pretty
+// clearly if we start using an incompatible version of the metrics.
+try
+{
+Field countField = Histogram.class.getDeclaredField("count");
+countField.setAccessible(true);
+// in 3.1 the counter object is a LongAdderAdapter which is a 
package private interface
+// from com.codahale.metrics. In 4.0, it is a java LongAdder so 
the code will be simpler.
+Object counter = countField.get(this);
+if (counter instanceof LongAdder) // For com.codahale.metrics 
version >= 4.0
+{
+((LongAdder) counter).reset();
+}
+else // 3.1 and 3.2
+{
+Method sumThenReset = 
counter.getClass().getDeclaredMethod("sumThenReset");
+sumThenReset.setAccessible(true);
+sumThenReset.invoke(counter);
+}
+}
+catch (Exception e)
+{
+throw new IllegalStateException("Cannot reset the 
com.codahale.metrics.Histogram count. This might be due to a change of version 
of the metric library", e);
+}
+}
 }
diff --git 
a/src/java/org/apache/cassandra/metrics/ClientRequestSizeMetrics.java 
b/src/java/org/apache/cassandra/metrics/ClientRequestSizeMetrics.java
index 41fb162..d86515e 100644
--- a/src/java/org/apache/cassandra/metrics/ClientRequestSizeMetrics.java
+++ b/src/java/org/apache/cassandra/metrics/ClientRequestSizeMetrics.java
@@ -31,6 +31,6 @@ public class ClientRequestSizeMetrics
 private static final String TYPE = "ClientRequestSize";
 public static final Counter totalBytesRead = 
Metrics.counter(DefaultNameFactory.createMetricName(TYPE, "IncomingBytes", 
null));
 public static final Counter totalBytesWritten = 
Metrics.counter(DefaultNameFactory.createMetricName(TYPE, "OutgoingBytes", 
null));
-public static final Histogram bytesRecievedPerFrame = 
Metrics.histogram(DefaultNameFactory.createMetricName(TYPE, 
"BytesRecievedPerFrame", null), true);
+public static final Histogram bytesReceivedPerFrame = 
Metrics.histogram(DefaultNameFactory.createMetricName(TYPE, 
"BytesRecievedPerFrame", null), true);
 public static final Histogram bytesTransmittedPerFrame = 
Metrics.histogram(DefaultNameFactory.createMetricName(TYPE, 
"BytesTransmittedPerFrame", null), true);
 }
diff --git a/src/java/org/apache/cassandra/transport/Frame.java 
b/src/java/org/apache/cassandra/transport/Frame.java
index b597cc2..ec4317a 100644
--- a/src/java/org/apache/cassandra/transport/Frame.java
+++ b/src/java/org/apache/cassandra/transport/Frame.java
@@ -224,7 +224,7 @@ public class Frame
 return null;
 
 ClientRequestSizeMetri

[jira] [Commented] (CASSANDRA-16186) SEPExecutor does not release blocked threads as it should

2020-10-20 Thread Benjamin Lerer (Jira)


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

Benjamin Lerer commented on CASSANDRA-16186:


Discussed quickly the patch offline with [~benedict]. I will rework the patch 
to avoid some inefficiencies of my initial approach.

> SEPExecutor does not release blocked threads as it should
> -
>
> Key: CASSANDRA-16186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16186
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-beta
>
>
> While adding some tests for the {{ThreadPoolMetrics}}, I discovered that the 
> {{SEPExecutor}} does not release the blocked threads as it should.
> If the number of tasks added to a SEPExecutor exceed the max queue size. The 
> threads adding those task will be block until enough space become available 
> for all the blocked tasks. At this point all the blocked threads will 
> released at once. 



--
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-16186) SEPExecutor does not release blocked threads as it should

2020-10-20 Thread Benjamin Lerer (Jira)


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

Benjamin Lerer updated CASSANDRA-16186:
---
Status: In Progress  (was: Patch Available)

> SEPExecutor does not release blocked threads as it should
> -
>
> Key: CASSANDRA-16186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16186
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-beta
>
>
> While adding some tests for the {{ThreadPoolMetrics}}, I discovered that the 
> {{SEPExecutor}} does not release the blocked threads as it should.
> If the number of tasks added to a SEPExecutor exceed the max queue size. The 
> threads adding those task will be block until enough space become available 
> for all the blocked tasks. At this point all the blocked threads will 
> released at once. 



--
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-15944) ASF CI unit tests on JDK11

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever reassigned CASSANDRA-15944:
--

Assignee: Michael Semb Wever

> ASF CI unit tests on JDK11
> --
>
> Key: CASSANDRA-15944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15944
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> ASF CI tests today only run on JDK1.8
> On the Jenkins cluster JDKs from 1.4 through to 15 are available. See 
> screenshot for naming specifics, attached in  CASSANDRA-15809
>  
> This ticket is to add JDK11 test targets on Cassandra-trunk and 
> Cassandra-devbranch, for parity to CircleCI's workflows.
>  
> The JDK is specified in the groovy DSL:
>  
> [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11]
>  
>  This is a continuation from CASSANDRA-15809 



--
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-15943) Tests fail with a space in the path

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-15943:
---
Resolution: Won't Fix
Status: Resolved  (was: Open)

> Tests fail with a space in the path
> ---
>
> Key: CASSANDRA-15943
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15943
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x
>
>
> Tests fail if there's a space in {{$\{basedir}}}
> For example, when the absolute path is used when specifying {{-javaagent}} 
> arguments.



--
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-15943) Tests fail with a space in the path

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-15943:


This is no longer a blocker to CASSANDRA-15944 as ASF Infra has fixed the JDK 
labels not to contain spaces anymore in INFRA-20858.

Closing this issue out as 'wont fix'.

> Tests fail with a space in the path
> ---
>
> Key: CASSANDRA-15943
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15943
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x
>
>
> Tests fail if there's a space in {{$\{basedir}}}
> For example, when the absolute path is used when specifying {{-javaagent}} 
> arguments.



--
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-16193) Add tests for Messaging/Internode metrics

2020-10-20 Thread Benjamin Lerer (Jira)


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

Benjamin Lerer commented on CASSANDRA-16193:


[~maxwellguo] your help is welcome :-) Feel free to take the ticket.

> Add tests for Messaging/Internode metrics
> -
>
> Key: CASSANDRA-16193
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16193
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java
>Reporter: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-beta
>
>
> We do not seems to have tests for the Messaging/Internode metrics.



--
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-16170) Rename master branch to trunk in cassandra-harry

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-16170:


trunk branch created.
waiting on INFRA-21008

> Rename master branch to trunk in cassandra-harry
> 
>
> Key: CASSANDRA-16170
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16170
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> ref: 
> https://the-asf.slack.com/archives/CK23JSY2K/p1603178258238100?thread_ts=1603177458.237800&cid=CK23JSY2K



--
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-harry] branch trunk created (now 4dbf969)

2020-10-20 Thread mck
This is an automated email from the ASF dual-hosted git repository.

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


  at 4dbf969  Initialize empty repository

No new revisions were added by this update.


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



[jira] [Updated] (CASSANDRA-16170) Rename master branch to trunk in cassandra-harry

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-16170:
---
Description: ref: 
https://the-asf.slack.com/archives/CK23JSY2K/p1603178258238100?thread_ts=1603177458.237800&cid=CK23JSY2K

> Rename master branch to trunk in cassandra-harry
> 
>
> Key: CASSANDRA-16170
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16170
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> ref: 
> https://the-asf.slack.com/archives/CK23JSY2K/p1603178258238100?thread_ts=1603177458.237800&cid=CK23JSY2K



--
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-16210) Synchronize Keyspace instance store/clear

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-16210:
---
  Fix Version/s: (was: 3.11.x)
 3.11.9
  Since Version: 2.0 beta 1
Source Control Link: 
https://github.com/apache/cassandra/commit/bca91ca84b9daf8b9e3d361975a535b90b4f77fa
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed as 
[bca91ca84b9daf8b9e3d361975a535b90b4f77fa|https://github.com/apache/cassandra/commit/bca91ca84b9daf8b9e3d361975a535b90b4f77fa]

> Synchronize Keyspace instance store/clear
> -
>
> Key: CASSANDRA-16210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16210
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.9
>
>
> DTest failure: 
> dtest-large.repair_tests.repair_test.TestRepairDataSystemTable.test_repair_table
>  (vnodes) - one random failure was reported which pointed to a race condition 
> to be spotted. 



--
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-15962) Digest for some queries is different depending whether the data are retrieved from sstable or memtable

2020-10-20 Thread Jacek Lewandowski (Jira)


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

Jacek Lewandowski commented on CASSANDRA-15962:
---

Thanks [~slebresne], sorry for huge delay, I'm about to apply your remarks and 
run tests

> Digest for some queries is different depending whether the data are retrieved 
> from sstable or memtable
> --
>
> Key: CASSANDRA-15962
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15962
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0, 3.11.x
>
> Attachments: DigestTest.java
>
>
> Not sure into which category should I assign this ticket.
>  
> Basically when reading using certain column filters, the digest is different 
> depending whether we read from sstable and memtable. This happens on 
> {{trunk}} and {{cassandra-3.11}} branches. However it works properly on 
> {{cassandra-3.0}} branch.
>  
> I'm attaching a simple test for trunk to demonstrate what I mean. 
>  
> Please verify my test and my conclusions
>  



--
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-16210) Synchronize Keyspace instance store/clear

2020-10-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-16210:
---
Status: Ready to Commit  (was: Review In Progress)

> Synchronize Keyspace instance store/clear
> -
>
> Key: CASSANDRA-16210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16210
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x
>
>
> DTest failure: 
> dtest-large.repair_tests.repair_test.TestRepairDataSystemTable.test_repair_table
>  (vnodes) - one random failure was reported which pointed to a race condition 
> to be spotted. 



--
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 cassandra-3.11 updated: Synchronize Keyspace instance store/clear

2020-10-20 Thread mck
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
 new bca91ca  Synchronize Keyspace instance store/clear
bca91ca is described below

commit bca91ca84b9daf8b9e3d361975a535b90b4f77fa
Author: Ekaterina Dimitrova 
AuthorDate: Wed Oct 14 10:34:39 2020 -0400

Synchronize Keyspace instance store/clear

 patch by Ekaterina Dimitrova; reviewed by Mick Semb Wever for 
CASSANDRA-16210
---
 CHANGES.txt  |  1 +
 src/java/org/apache/cassandra/config/Schema.java | 12 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index df8e6ba..6c41cee 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.11.9
+ * Synchronize Keyspace instance store/clear (CASSANDRA-16210)
  * Fix ColumnFilter to avoid querying cells of unselected complex columns 
(CASSANDRA-15977)
  * Fix memory leak in CompressedChunkReader (CASSANDRA-15880)
  * Don't attempt value skipping with mixed version cluster (CASSANDRA-15833)
diff --git a/src/java/org/apache/cassandra/config/Schema.java 
b/src/java/org/apache/cassandra/config/Schema.java
index 253a66b..7c2028b 100644
--- a/src/java/org/apache/cassandra/config/Schema.java
+++ b/src/java/org/apache/cassandra/config/Schema.java
@@ -205,10 +205,8 @@ public class Schema
  */
 public void storeKeyspaceInstance(Keyspace keyspace)
 {
-if (keyspaceInstances.containsKey(keyspace.getName()))
+if (keyspaceInstances.putIfAbsent(keyspace.getName(), keyspace) != 
null)
 throw new IllegalArgumentException(String.format("Keyspace %s was 
already initialized.", keyspace.getName()));
-
-keyspaceInstances.put(keyspace.getName(), keyspace);
 }
 
 /**
@@ -653,9 +651,11 @@ public class Schema
 droppedCfs.add(cfm.cfId);
 }
 
-// remove the keyspace from the static instances.
-Keyspace.clear(ksm.name);
-clearKeyspaceMetadata(ksm);
+synchronized (Keyspace.class) {
+// Remove the keyspace from the static instances.
+Keyspace.clear(ksm.name);
+clearKeyspaceMetadata(ksm);
+}
 
 Keyspace.writeOrder.awaitNewBarrier();
 


-
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-3.11' into trunk

2020-10-20 Thread mck
This is an automated email from the ASF dual-hosted git repository.

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

commit fec0fbe2915a544bb1660092d934a356cd46c0fa
Merge: 95d60a0 bca91ca
Author: Mick Semb Wever 
AuthorDate: Tue Oct 20 09:24:09 2020 +0200

Merge branch 'cassandra-3.11' into trunk



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



  1   2   >