[jira] [Commented] (CASSANDRA-14754) Add verification of state machine in StreamSession
[
https://issues.apache.org/jira/browse/CASSANDRA-14754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068273#comment-17068273
]
ZhaoYang commented on CASSANDRA-14754:
--
bq. for example, moving from INITIALIZED to COMPLETE is valid, but only if
there's nothing to actually stream, which is not expressed in the current
validation (IIUIC, correct me if I'm wrong). In other words, I think it would
be best to implement a proper state machine, but is it really necessary for 4.0?
Indeed, there isn't much value on validating the state transition alone without
checking other prerequisites. Moved to 4.x
I will port some simplifications from this patch into CASSANDRA-15665,
CASSANDRA-15666.
> Add verification of state machine in StreamSession
> --
>
> Key: CASSANDRA-14754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14754
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Streaming and Messaging
>Reporter: Jason Brown
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.x
>
>
> {{StreamSession}} contains an implicit state machine, but we have no
> verification of the safety of the transitions between states. For example, we
> have no checks to ensure we cannot leave the final states (COMPLETED, FAILED).
> I propose we add some program logic in {{StreamSession}}, tests, and
> documentation to ensure the correctness of the state transitions.
--
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-14754) Add verification of state machine in StreamSession
[
https://issues.apache.org/jira/browse/CASSANDRA-14754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-14754:
-
Fix Version/s: (was: 4.0)
4.x
> Add verification of state machine in StreamSession
> --
>
> Key: CASSANDRA-14754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14754
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Streaming and Messaging
>Reporter: Jason Brown
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.x
>
>
> {{StreamSession}} contains an implicit state machine, but we have no
> verification of the safety of the transitions between states. For example, we
> have no checks to ensure we cannot leave the final states (COMPLETED, FAILED).
> I propose we add some program logic in {{StreamSession}}, tests, and
> documentation to ensure the correctness of the state transitions.
--
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-14754) Add verification of state machine in StreamSession
[
https://issues.apache.org/jira/browse/CASSANDRA-14754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-14754:
-
Status: Patch Available (was: Review In Progress)
> Add verification of state machine in StreamSession
> --
>
> Key: CASSANDRA-14754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14754
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Streaming and Messaging
>Reporter: Jason Brown
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamSession}} contains an implicit state machine, but we have no
> verification of the safety of the transitions between states. For example, we
> have no checks to ensure we cannot leave the final states (COMPLETED, FAILED).
> I propose we add some program logic in {{StreamSession}}, tests, and
> documentation to ensure the correctness of the state transitions.
--
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-14754) Add verification of state machine in StreamSession
[
https://issues.apache.org/jira/browse/CASSANDRA-14754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-14754:
-
Status: Open (was: Patch Available)
> Add verification of state machine in StreamSession
> --
>
> Key: CASSANDRA-14754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14754
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Streaming and Messaging
>Reporter: Jason Brown
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamSession}} contains an implicit state machine, but we have no
> verification of the safety of the transitions between states. For example, we
> have no checks to ensure we cannot leave the final states (COMPLETED, FAILED).
> I propose we add some program logic in {{StreamSession}}, tests, and
> documentation to ensure the correctness of the state transitions.
--
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-15650) Fix flaky test org.apache.cassandra.distributed.test.*RepairCoordinatorFastTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068244#comment-17068244
]
David Capwell edited comment on CASSANDRA-15650 at 3/27/20, 3:42 AM:
-
Throw as unchecked means I don't need to wrap, that's basically it; take a
checked exception and throw without needing to check
was (Author: dcapwell):
Throw as unchecked means I don't need to wrap, that's basically it
> Fix flaky test
> org.apache.cassandra.distributed.test.*RepairCoordinatorFastTest
> ---
>
> Key: CASSANDRA-15650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15650
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test failure:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/177/workflows/3dff37a5-9bf4-40e2-8d5b-f127b416dc79/jobs/862
> {code}
> [junit-timeout] Testcase:
> onlyCoordinator[SEQUENTIAL/true](org.apache.cassandra.distributed.test.FullRepairCoordinatorFastTest):
> FAILED
> [junit-timeout] nodetool command repair was successful but not expected to
> be. Actual: 0
> [junit-timeout] junit.framework.AssertionFailedError: nodetool command repair
> was successful but not expected to be. Actual: 0
> [junit-timeout] at
> org.apache.cassandra.distributed.api.NodeToolResult$Asserts.failure(NodeToolResult.java:76)
> [junit-timeout] at
> org.apache.cassandra.distributed.test.RepairCoordinatorFast.onlyCoordinator(RepairCoordinatorFast.java:255)
> [junit-timeout] at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [junit-timeout] at java.lang.Thread.run(Thread.java:748)
> {code}
> [Circle CI
> LOWER|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorTestFlaky]
--
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-15650) Fix flaky test org.apache.cassandra.distributed.test.*RepairCoordinatorFastTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068244#comment-17068244
]
David Capwell commented on CASSANDRA-15650:
---
Throw as unchecked means I don't need to wrap, that's basically it
> Fix flaky test
> org.apache.cassandra.distributed.test.*RepairCoordinatorFastTest
> ---
>
> Key: CASSANDRA-15650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15650
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test failure:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/177/workflows/3dff37a5-9bf4-40e2-8d5b-f127b416dc79/jobs/862
> {code}
> [junit-timeout] Testcase:
> onlyCoordinator[SEQUENTIAL/true](org.apache.cassandra.distributed.test.FullRepairCoordinatorFastTest):
> FAILED
> [junit-timeout] nodetool command repair was successful but not expected to
> be. Actual: 0
> [junit-timeout] junit.framework.AssertionFailedError: nodetool command repair
> was successful but not expected to be. Actual: 0
> [junit-timeout] at
> org.apache.cassandra.distributed.api.NodeToolResult$Asserts.failure(NodeToolResult.java:76)
> [junit-timeout] at
> org.apache.cassandra.distributed.test.RepairCoordinatorFast.onlyCoordinator(RepairCoordinatorFast.java:255)
> [junit-timeout] at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [junit-timeout] at java.lang.Thread.run(Thread.java:748)
> {code}
> [Circle CI
> LOWER|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorTestFlaky]
--
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-15650) Fix flaky test org.apache.cassandra.distributed.test.*RepairCoordinatorFastTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068243#comment-17068243
]
Ekaterina Dimitrova commented on CASSANDRA-15650:
-
LGTM
Thanks
I have only one question, why did you decide to do the
throwAsUncheckedException? Not sure I understand correctly.
[~blerer] can you, please, check and commit if you don't have anything in
addition? Thanks!
> Fix flaky test
> org.apache.cassandra.distributed.test.*RepairCoordinatorFastTest
> ---
>
> Key: CASSANDRA-15650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15650
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test failure:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/177/workflows/3dff37a5-9bf4-40e2-8d5b-f127b416dc79/jobs/862
> {code}
> [junit-timeout] Testcase:
> onlyCoordinator[SEQUENTIAL/true](org.apache.cassandra.distributed.test.FullRepairCoordinatorFastTest):
> FAILED
> [junit-timeout] nodetool command repair was successful but not expected to
> be. Actual: 0
> [junit-timeout] junit.framework.AssertionFailedError: nodetool command repair
> was successful but not expected to be. Actual: 0
> [junit-timeout] at
> org.apache.cassandra.distributed.api.NodeToolResult$Asserts.failure(NodeToolResult.java:76)
> [junit-timeout] at
> org.apache.cassandra.distributed.test.RepairCoordinatorFast.onlyCoordinator(RepairCoordinatorFast.java:255)
> [junit-timeout] at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [junit-timeout] at java.lang.Thread.run(Thread.java:748)
> {code}
> [Circle CI
> LOWER|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorTestFlaky]
--
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-15650) Fix flaky test org.apache.cassandra.distributed.test.*RepairCoordinatorFastTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15650:
Reviewers: Benjamin Lerer, Ekaterina Dimitrova (was: Ekaterina Dimitrova)
> Fix flaky test
> org.apache.cassandra.distributed.test.*RepairCoordinatorFastTest
> ---
>
> Key: CASSANDRA-15650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15650
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test failure:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/177/workflows/3dff37a5-9bf4-40e2-8d5b-f127b416dc79/jobs/862
> {code}
> [junit-timeout] Testcase:
> onlyCoordinator[SEQUENTIAL/true](org.apache.cassandra.distributed.test.FullRepairCoordinatorFastTest):
> FAILED
> [junit-timeout] nodetool command repair was successful but not expected to
> be. Actual: 0
> [junit-timeout] junit.framework.AssertionFailedError: nodetool command repair
> was successful but not expected to be. Actual: 0
> [junit-timeout] at
> org.apache.cassandra.distributed.api.NodeToolResult$Asserts.failure(NodeToolResult.java:76)
> [junit-timeout] at
> org.apache.cassandra.distributed.test.RepairCoordinatorFast.onlyCoordinator(RepairCoordinatorFast.java:255)
> [junit-timeout] at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [junit-timeout] at java.lang.Thread.run(Thread.java:748)
> {code}
> [Circle CI
> LOWER|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorTestFlaky]
--
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-15656) Expose repair streaming metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068160#comment-17068160 ] Ekaterina Dimitrova commented on CASSANDRA-15656: - Hi, If you don't hear soon from CircleCI support, attaching screenshots of the results might also work. Whatever works for you. Thanks > Expose repair streaming metric > -- > > Key: CASSANDRA-15656 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15656 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair, Consistency/Streaming >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-alpha > > > We should expose a metric for how much data is streamed during repair -- 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-15654) Track preview repair failures
[ https://issues.apache.org/jira/browse/CASSANDRA-15654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15654: Status: Requires Testing (was: Review In Progress) > Track preview repair failures > - > > Key: CASSANDRA-15654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15654 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair, Observability/Metrics >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > Fix For: 4.0-alpha > > > We should expose a metric for when preview repair fails -- 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-15655) Optionally set nowInSec in the future for validation repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-15655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15655: Status: Requires Testing (was: Review In Progress) > Optionally set nowInSec in the future for validation repairs > > > Key: CASSANDRA-15655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15655 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-alpha > > > There is a race when running validation repairs where we might build merkle > trees on one node, have gcgs expire, tombstones get compacted out and then > build merkle trees on other nodes, causing false positive preview repair > mismatch -- 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-12) Fix yaml vulnerability
[ https://issues.apache.org/jira/browse/CASSANDRASC-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRASC-12: -- Fix Version/s: 1.0 Source Control Link: https://github.com/apache/cassandra-sidecar/commit/c2d684d7423bbf02a6fc231345eb1c2335cbc0b3 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Fix yaml vulnerability > -- > > Key: CASSANDRASC-12 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-12 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Configuration >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Fix For: 1.0 > > > There’s a minor bug in the way we process yaml configuration. We should bump > our commons-configuration2 dependency to the latest release and fix how we > load the 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
[cassandra-sidecar] branch master updated: Security patch for snake yaml
This is an automated email from the ASF dual-hosted git repository.
rustyrazorblade pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-sidecar.git
The following commit(s) were added to refs/heads/master by this push:
new c2d684d Security patch for snake yaml
c2d684d is described below
commit c2d684d7423bbf02a6fc231345eb1c2335cbc0b3
Author: Jon Haddad
AuthorDate: Mon Mar 9 12:45:10 2020 -0700
Security patch for snake yaml
Bumped commons-configuration2 to latest version and correctly use
YAMLConfiguration.
Patch by Jon Haddad; Reviewed by Dinesh Joshi for CASSANDRASC-12
---
CHANGES.txt| 1 +
build.gradle | 4 ++--
src/main/java/org/apache/cassandra/sidecar/MainModule.java | 12
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 00defa6..7e12540 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
1.0.0
-
+ * Security patch to fix incorrect usage of yaml configuration (CASSANDRASC-12)
* Build and Test with both Java 8 & 11 in Circle CI (CASSANDRA-15611)
* Upgraded Gradle and replaced FindBugs with SpotBugs (CASSANDRA-15610)
* Improving local HealthCheckTest reliability (CASSANDRA-15615)
diff --git a/build.gradle b/build.gradle
index f080eb6..6aa46d5 100644
--- a/build.gradle
+++ b/build.gradle
@@ -85,10 +85,10 @@ dependencies {
compile 'com.datastax.cassandra:cassandra-driver-core:3.6+'
compile group: 'com.google.inject', name: 'guice', version: '4.2.2'
-compile group: 'org.apache.commons', name: 'commons-configuration2',
version: '2.4'
+compile group: 'org.apache.commons', name: 'commons-configuration2',
version: '2.7'
runtime group: 'commons-beanutils', name: 'commons-beanutils', version:
'1.9.3'
-runtime group: 'org.yaml', name: 'snakeyaml', version: '1.23'
+runtime group: 'org.yaml', name: 'snakeyaml', version: '1.26'
jolokia 'org.jolokia:jolokia-jvm:1.6.0:agent'
swaggerUI 'org.webjars:swagger-ui:3.10.0'
diff --git a/src/main/java/org/apache/cassandra/sidecar/MainModule.java
b/src/main/java/org/apache/cassandra/sidecar/MainModule.java
index 38a53f8..82c9c69 100644
--- a/src/main/java/org/apache/cassandra/sidecar/MainModule.java
+++ b/src/main/java/org/apache/cassandra/sidecar/MainModule.java
@@ -18,11 +18,12 @@
package org.apache.cassandra.sidecar;
+import java.io.IOException;
+import java.io.InputStream;
import java.net.MalformedURLException;
import java.net.URL;
import org.apache.commons.configuration2.YAMLConfiguration;
-import org.apache.commons.configuration2.builder.fluent.Configurations;
import org.apache.commons.configuration2.ex.ConfigurationException;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -106,15 +107,18 @@ public class MainModule extends AbstractModule
@Provides
@Singleton
-public Configuration configuration() throws ConfigurationException
+public Configuration configuration() throws ConfigurationException,
IOException
{
final String confPath = System.getProperty("sidecar.config",
"file://./conf/config.yaml");
logger.info("Reading configuration from {}", confPath);
try
{
-Configurations confs = new Configurations();
URL url = new URL(confPath);
-YAMLConfiguration yamlConf =
confs.fileBased(YAMLConfiguration.class, url);
+
+YAMLConfiguration yamlConf = new YAMLConfiguration();
+InputStream stream = url.openStream();
+yamlConf.read(stream);
+
return new Configuration.Builder()
.setCassandraHost(yamlConf.get(String.class,
"cassandra.host"))
.setCassandraPort(yamlConf.get(Integer.class,
"cassandra.port"))
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15649) test.distributed.timeout no longer respected in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-15649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15649: -- Attachment: Screen Shot 2020-03-26 at 1.32.31 PM.png Screen Shot 2020-03-26 at 1.33.20 PM.png Screen Shot 2020-03-26 at 1.33.28 PM.png Screen Shot 2020-03-26 at 1.33.44 PM.png > test.distributed.timeout no longer respected in CircleCI > > > Key: CASSANDRA-15649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15649 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Attachments: Screen Shot 2020-03-26 at 1.21.34 PM.png, Screen Shot > 2020-03-26 at 1.26.30 PM.png, Screen Shot 2020-03-26 at 1.27.02 PM.png, > Screen Shot 2020-03-26 at 1.29.21 PM.png, Screen Shot 2020-03-26 at 1.29.35 > PM.png, Screen Shot 2020-03-26 at 1.29.57 PM.png, Screen Shot 2020-03-26 at > 1.31.22 PM.png, Screen Shot 2020-03-26 at 1.31.37 PM.png, Screen Shot > 2020-03-26 at 1.31.56 PM.png, Screen Shot 2020-03-26 at 1.32.31 PM.png, > Screen Shot 2020-03-26 at 1.33.20 PM.png, Screen Shot 2020-03-26 at 1.33.28 > PM.png, Screen Shot 2020-03-26 at 1.33.44 PM.png > > Time Spent: 1h > Remaining Estimate: 0h > > After switching jvm dtest over testclasslist (CASSANDRA-15508) we no longer > respect the dtest timeout and instead use the unit test timeout (4m vs 6m). > This does not impact Jenkins as I made sure to check that before calling > testclasslist; though this does impact 2.2, 3.0, and 3.11 as well. > ||Config||Trunk||3.11||3.0||2.2|| > |LOWER||[Circle > CI|https://circleci.com/workflow-run/04f7fbe2-1919-4da0-bf72-ba41b41c3072]| > [Circle > CI|https://circleci.com/workflow-run/69c64062-80f5-4d08-8ab0-dbe88ce7b236] | > [Circle > CI|https://circleci.com/workflow-run/499d2fbe-a8c1-4a27-9430-a9ebb40aad53] | > [Circle > CI|https://circleci.com/workflow-run/fedbd5b8-683d-4c59-a9f6-3aad5a6ba41d] | > |HIGHER| [Circle > CI|https://circleci.com/workflow-run/036bbad1-541a-49dc-a567-cef2300fa847] | > TBD | TBD | TBD | > CI Failures were flaky tests, below are their links > * CASSANDRA-15630 -- 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-15649) test.distributed.timeout no longer respected in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-15649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068018#comment-17068018 ] David Capwell commented on CASSANDRA-15649: --- the 2.2 builds spam stdout so the UI doesn't show the ant command, so print out the script. > test.distributed.timeout no longer respected in CircleCI > > > Key: CASSANDRA-15649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15649 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Attachments: Screen Shot 2020-03-26 at 1.21.34 PM.png, Screen Shot > 2020-03-26 at 1.26.30 PM.png, Screen Shot 2020-03-26 at 1.27.02 PM.png, > Screen Shot 2020-03-26 at 1.29.21 PM.png, Screen Shot 2020-03-26 at 1.29.35 > PM.png, Screen Shot 2020-03-26 at 1.29.57 PM.png, Screen Shot 2020-03-26 at > 1.31.22 PM.png, Screen Shot 2020-03-26 at 1.31.37 PM.png, Screen Shot > 2020-03-26 at 1.31.56 PM.png, Screen Shot 2020-03-26 at 1.32.31 PM.png, > Screen Shot 2020-03-26 at 1.33.20 PM.png, Screen Shot 2020-03-26 at 1.33.28 > PM.png, Screen Shot 2020-03-26 at 1.33.44 PM.png > > Time Spent: 1h > Remaining Estimate: 0h > > After switching jvm dtest over testclasslist (CASSANDRA-15508) we no longer > respect the dtest timeout and instead use the unit test timeout (4m vs 6m). > This does not impact Jenkins as I made sure to check that before calling > testclasslist; though this does impact 2.2, 3.0, and 3.11 as well. > ||Config||Trunk||3.11||3.0||2.2|| > |LOWER||[Circle > CI|https://circleci.com/workflow-run/04f7fbe2-1919-4da0-bf72-ba41b41c3072]| > [Circle > CI|https://circleci.com/workflow-run/69c64062-80f5-4d08-8ab0-dbe88ce7b236] | > [Circle > CI|https://circleci.com/workflow-run/499d2fbe-a8c1-4a27-9430-a9ebb40aad53] | > [Circle > CI|https://circleci.com/workflow-run/fedbd5b8-683d-4c59-a9f6-3aad5a6ba41d] | > |HIGHER| [Circle > CI|https://circleci.com/workflow-run/036bbad1-541a-49dc-a567-cef2300fa847] | > TBD | TBD | TBD | > CI Failures were flaky tests, below are their links > * CASSANDRA-15630 -- 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-15649) test.distributed.timeout no longer respected in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-15649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15649: -- Attachment: Screen Shot 2020-03-26 at 1.31.22 PM.png Screen Shot 2020-03-26 at 1.31.37 PM.png Screen Shot 2020-03-26 at 1.31.56 PM.png > test.distributed.timeout no longer respected in CircleCI > > > Key: CASSANDRA-15649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15649 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Attachments: Screen Shot 2020-03-26 at 1.21.34 PM.png, Screen Shot > 2020-03-26 at 1.26.30 PM.png, Screen Shot 2020-03-26 at 1.27.02 PM.png, > Screen Shot 2020-03-26 at 1.29.21 PM.png, Screen Shot 2020-03-26 at 1.29.35 > PM.png, Screen Shot 2020-03-26 at 1.29.57 PM.png, Screen Shot 2020-03-26 at > 1.31.22 PM.png, Screen Shot 2020-03-26 at 1.31.37 PM.png, Screen Shot > 2020-03-26 at 1.31.56 PM.png > > Time Spent: 1h > Remaining Estimate: 0h > > After switching jvm dtest over testclasslist (CASSANDRA-15508) we no longer > respect the dtest timeout and instead use the unit test timeout (4m vs 6m). > This does not impact Jenkins as I made sure to check that before calling > testclasslist; though this does impact 2.2, 3.0, and 3.11 as well. > ||Config||Trunk||3.11||3.0||2.2|| > |LOWER||[Circle > CI|https://circleci.com/workflow-run/04f7fbe2-1919-4da0-bf72-ba41b41c3072]| > [Circle > CI|https://circleci.com/workflow-run/69c64062-80f5-4d08-8ab0-dbe88ce7b236] | > [Circle > CI|https://circleci.com/workflow-run/499d2fbe-a8c1-4a27-9430-a9ebb40aad53] | > [Circle > CI|https://circleci.com/workflow-run/fedbd5b8-683d-4c59-a9f6-3aad5a6ba41d] | > |HIGHER| [Circle > CI|https://circleci.com/workflow-run/036bbad1-541a-49dc-a567-cef2300fa847] | > TBD | TBD | TBD | > CI Failures were flaky tests, below are their links > * CASSANDRA-15630 -- 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-15649) test.distributed.timeout no longer respected in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-15649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15649: -- Attachment: Screen Shot 2020-03-26 at 1.29.35 PM.png Screen Shot 2020-03-26 at 1.29.57 PM.png Screen Shot 2020-03-26 at 1.29.21 PM.png > test.distributed.timeout no longer respected in CircleCI > > > Key: CASSANDRA-15649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15649 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Attachments: Screen Shot 2020-03-26 at 1.21.34 PM.png, Screen Shot > 2020-03-26 at 1.26.30 PM.png, Screen Shot 2020-03-26 at 1.27.02 PM.png, > Screen Shot 2020-03-26 at 1.29.21 PM.png, Screen Shot 2020-03-26 at 1.29.35 > PM.png, Screen Shot 2020-03-26 at 1.29.57 PM.png > > Time Spent: 1h > Remaining Estimate: 0h > > After switching jvm dtest over testclasslist (CASSANDRA-15508) we no longer > respect the dtest timeout and instead use the unit test timeout (4m vs 6m). > This does not impact Jenkins as I made sure to check that before calling > testclasslist; though this does impact 2.2, 3.0, and 3.11 as well. > ||Config||Trunk||3.11||3.0||2.2|| > |LOWER||[Circle > CI|https://circleci.com/workflow-run/04f7fbe2-1919-4da0-bf72-ba41b41c3072]| > [Circle > CI|https://circleci.com/workflow-run/69c64062-80f5-4d08-8ab0-dbe88ce7b236] | > [Circle > CI|https://circleci.com/workflow-run/499d2fbe-a8c1-4a27-9430-a9ebb40aad53] | > [Circle > CI|https://circleci.com/workflow-run/fedbd5b8-683d-4c59-a9f6-3aad5a6ba41d] | > |HIGHER| [Circle > CI|https://circleci.com/workflow-run/036bbad1-541a-49dc-a567-cef2300fa847] | > TBD | TBD | TBD | > CI Failures were flaky tests, below are their links > * CASSANDRA-15630 -- 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-15649) test.distributed.timeout no longer respected in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-15649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15649: -- Attachment: Screen Shot 2020-03-26 at 1.21.34 PM.png Screen Shot 2020-03-26 at 1.26.30 PM.png Screen Shot 2020-03-26 at 1.27.02 PM.png > test.distributed.timeout no longer respected in CircleCI > > > Key: CASSANDRA-15649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15649 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Attachments: Screen Shot 2020-03-26 at 1.21.34 PM.png, Screen Shot > 2020-03-26 at 1.26.30 PM.png, Screen Shot 2020-03-26 at 1.27.02 PM.png > > Time Spent: 1h > Remaining Estimate: 0h > > After switching jvm dtest over testclasslist (CASSANDRA-15508) we no longer > respect the dtest timeout and instead use the unit test timeout (4m vs 6m). > This does not impact Jenkins as I made sure to check that before calling > testclasslist; though this does impact 2.2, 3.0, and 3.11 as well. > ||Config||Trunk||3.11||3.0||2.2|| > |LOWER||[Circle > CI|https://circleci.com/workflow-run/04f7fbe2-1919-4da0-bf72-ba41b41c3072]| > [Circle > CI|https://circleci.com/workflow-run/69c64062-80f5-4d08-8ab0-dbe88ce7b236] | > [Circle > CI|https://circleci.com/workflow-run/499d2fbe-a8c1-4a27-9430-a9ebb40aad53] | > [Circle > CI|https://circleci.com/workflow-run/fedbd5b8-683d-4c59-a9f6-3aad5a6ba41d] | > |HIGHER| [Circle > CI|https://circleci.com/workflow-run/036bbad1-541a-49dc-a567-cef2300fa847] | > TBD | TBD | TBD | > CI Failures were flaky tests, below are their links > * CASSANDRA-15630 -- 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-15649) test.distributed.timeout no longer respected in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-15649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067981#comment-17067981 ] David Capwell commented on CASSANDRA-15649: --- since Circle CI is locking down workflows for some reason, ill take a screen shot of the DAG + the params and attach to JIRA. There are test failures, for trunk I linked to the flaky test JIRA, for other builds I don't have history so don't know what's flaky. > test.distributed.timeout no longer respected in CircleCI > > > Key: CASSANDRA-15649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15649 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Time Spent: 1h > Remaining Estimate: 0h > > After switching jvm dtest over testclasslist (CASSANDRA-15508) we no longer > respect the dtest timeout and instead use the unit test timeout (4m vs 6m). > This does not impact Jenkins as I made sure to check that before calling > testclasslist; though this does impact 2.2, 3.0, and 3.11 as well. > ||Config||Trunk||3.11||3.0||2.2|| > |LOWER||[Circle > CI|https://circleci.com/workflow-run/04f7fbe2-1919-4da0-bf72-ba41b41c3072]| > [Circle > CI|https://circleci.com/workflow-run/69c64062-80f5-4d08-8ab0-dbe88ce7b236] | > [Circle > CI|https://circleci.com/workflow-run/499d2fbe-a8c1-4a27-9430-a9ebb40aad53] | > [Circle > CI|https://circleci.com/workflow-run/fedbd5b8-683d-4c59-a9f6-3aad5a6ba41d] | > |HIGHER| [Circle > CI|https://circleci.com/workflow-run/036bbad1-541a-49dc-a567-cef2300fa847] | > TBD | TBD | TBD | > CI Failures were flaky tests, below are their links > * CASSANDRA-15630 -- 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-12) Fix yaml vulnerability
[ https://issues.apache.org/jira/browse/CASSANDRASC-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-12: Reviewers: Dinesh Joshi Status: Review In Progress (was: Patch Available) > Fix yaml vulnerability > -- > > Key: CASSANDRASC-12 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-12 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Configuration >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > > There’s a minor bug in the way we process yaml configuration. We should bump > our commons-configuration2 dependency to the latest release and fix how we > load the 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] (CASSANDRASC-12) Fix yaml vulnerability
[ https://issues.apache.org/jira/browse/CASSANDRASC-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-12: Status: Ready to Commit (was: Review In Progress) +1 > Fix yaml vulnerability > -- > > Key: CASSANDRASC-12 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-12 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Configuration >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > > There’s a minor bug in the way we process yaml configuration. We should bump > our commons-configuration2 dependency to the latest release and fix how we > load the 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-15337) Document usage of Ec2Snitch for multiple regions cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-15337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Haddad updated CASSANDRA-15337:
---
Test and Documentation Plan: CI
Status: Patch Available (was: Open)
> Document usage of Ec2Snitch for multiple regions cluster
>
>
> Key: CASSANDRA-15337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15337
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ec2MultiRegionSnitch was (probably) done because it was not possible in AWS
> to have intra-region VPC peering. This changed pin 2017, see [AWS
> announcement|https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/]
> (and extended with 9 more regions in 2018, see
> [link|https://aws.amazon.com/about-aws/whats-new/2018/02/inter-region-vpc-peering-is-now-available-in-nine-additional-aws-regions/]):
> {quote}Inter-Region VPC Peering allows VPC resources like EC2 instances[...]
> running in different AWS regions to communicate with each other using private
> IP addresses, without requiring gateways, VPN connections or separate network
> appliances.
> {quote}
> Since the datacenter/rack names are loaded in Ec2Snitch using AWS API there
> is no reason why this snitch would not work in a multi-datacenter setup. I
> tested and used this in a production environment. So the documentation should
> be changed to include this usage.
> Proposed change:
> [https://github.com/apache/cassandra/compare/trunk...serban21:15337-trunk]
--
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-12) Fix yaml vulnerability
[ https://issues.apache.org/jira/browse/CASSANDRASC-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRASC-12: -- Authors: Jon Haddad Test and Documentation Plan: [CircleCI results|https://app.circleci.com/pipelines/github/rustyrazorblade/cassandra-sidecar/37/workflows/dbb70de7-2f8e-4058-9a6e-5d5977dbe8f0/jobs/49] Status: Patch Available (was: Open) https://github.com/apache/cassandra-sidecar/pull/9 > Fix yaml vulnerability > -- > > Key: CASSANDRASC-12 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-12 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Configuration >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > > There’s a minor bug in the way we process yaml configuration. We should bump > our commons-configuration2 dependency to the latest release and fix how we > load the 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] (CASSANDRASC-12) Fix yaml vulnerability
[ https://issues.apache.org/jira/browse/CASSANDRASC-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRASC-12: -- Bug Category: Parent values: Security(12985)Level 1 values: Privilege Escalation(13000) Complexity: Low Hanging Fruit Component/s: Configuration Discovered By: User Report Severity: Low Status: Open (was: Triage Needed) > Fix yaml vulnerability > -- > > Key: CASSANDRASC-12 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-12 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Configuration >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > > There’s a minor bug in the way we process yaml configuration. We should bump > our commons-configuration2 dependency to the latest release and fix how we > load the 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-15337) Document usage of Ec2Snitch for multiple regions cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-15337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067948#comment-17067948
]
Serban Teodorescu commented on CASSANDRA-15337:
---
[~stefan.genov] I think I encountered the same problem, and it has nothing to
do with the snitch. It's probably due to how you connect to the cluster. In the
3.x version of the Java driver the example for DCAwareRoundRobinPolicy uses
withUsedHostsPerRemoteDc(2) at
[https://github.com/datastax/java-driver/blob/3.2.x/manual/load_balancing/README.md#dcawareroundrobinpolicy.|https://github.com/datastax/java-driver/blob/3.2.x/manual/load_balancing/README.md#dcawareroundrobinpolicy]
If you use something like that, try ".withUsedHostsPerRemoteDc(0)". With a
larger than zero argument some requests (not many) will slip through to the
remote DC, even with LOCAL_. I think the intention was to use this as an
automatic recovery mechanism in case of a datacenter failure. In the latest
version of the Java driver this was dropped. See
[https://github.com/datastax/java-driver/blob/4.x/manual/core/load_balancing/README.md]
> Document usage of Ec2Snitch for multiple regions cluster
>
>
> Key: CASSANDRA-15337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15337
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ec2MultiRegionSnitch was (probably) done because it was not possible in AWS
> to have intra-region VPC peering. This changed pin 2017, see [AWS
> announcement|https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/]
> (and extended with 9 more regions in 2018, see
> [link|https://aws.amazon.com/about-aws/whats-new/2018/02/inter-region-vpc-peering-is-now-available-in-nine-additional-aws-regions/]):
> {quote}Inter-Region VPC Peering allows VPC resources like EC2 instances[...]
> running in different AWS regions to communicate with each other using private
> IP addresses, without requiring gateways, VPN connections or separate network
> appliances.
> {quote}
> Since the datacenter/rack names are loaded in Ec2Snitch using AWS API there
> is no reason why this snitch would not work in a multi-datacenter setup. I
> tested and used this in a production environment. So the documentation should
> be changed to include this usage.
> Proposed change:
> [https://github.com/apache/cassandra/compare/trunk...serban21:15337-trunk]
--
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-15337) Document usage of Ec2Snitch for multiple regions cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-15337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067932#comment-17067932
]
Serban Teodorescu commented on CASSANDRA-15337:
---
[~rustyrazorblade] I created a PR
([https://github.com/apache/cassandra/pull/494]). Thanks.
> Document usage of Ec2Snitch for multiple regions cluster
>
>
> Key: CASSANDRA-15337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15337
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ec2MultiRegionSnitch was (probably) done because it was not possible in AWS
> to have intra-region VPC peering. This changed pin 2017, see [AWS
> announcement|https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/]
> (and extended with 9 more regions in 2018, see
> [link|https://aws.amazon.com/about-aws/whats-new/2018/02/inter-region-vpc-peering-is-now-available-in-nine-additional-aws-regions/]):
> {quote}Inter-Region VPC Peering allows VPC resources like EC2 instances[...]
> running in different AWS regions to communicate with each other using private
> IP addresses, without requiring gateways, VPN connections or separate network
> appliances.
> {quote}
> Since the datacenter/rack names are loaded in Ec2Snitch using AWS API there
> is no reason why this snitch would not work in a multi-datacenter setup. I
> tested and used this in a production environment. So the documentation should
> be changed to include this usage.
> Proposed change:
> [https://github.com/apache/cassandra/compare/trunk...serban21:15337-trunk]
--
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-15337) Document usage of Ec2Snitch for multiple regions cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-15337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CASSANDRA-15337:
---
Labels: pull-request-available (was: )
> Document usage of Ec2Snitch for multiple regions cluster
>
>
> Key: CASSANDRA-15337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15337
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
> Labels: pull-request-available
>
> Ec2MultiRegionSnitch was (probably) done because it was not possible in AWS
> to have intra-region VPC peering. This changed pin 2017, see [AWS
> announcement|https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/]
> (and extended with 9 more regions in 2018, see
> [link|https://aws.amazon.com/about-aws/whats-new/2018/02/inter-region-vpc-peering-is-now-available-in-nine-additional-aws-regions/]):
> {quote}Inter-Region VPC Peering allows VPC resources like EC2 instances[...]
> running in different AWS regions to communicate with each other using private
> IP addresses, without requiring gateways, VPN connections or separate network
> appliances.
> {quote}
> Since the datacenter/rack names are loaded in Ec2Snitch using AWS API there
> is no reason why this snitch would not work in a multi-datacenter setup. I
> tested and used this in a production environment. So the documentation should
> be changed to include this usage.
> Proposed change:
> [https://github.com/apache/cassandra/compare/trunk...serban21:15337-trunk]
--
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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15652: Fix Version/s: 4.x Source Control Link: https://dist.apache.org/repos/dist/release/cassandra/KEYS Resolution: Fixed Status: Resolved (was: Ready to Commit) > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Alex Petrov >Assignee: Michael Shuler >Priority: Normal > Fix For: 4.x > > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.html -- 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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067925#comment-17067925 ] Alex Petrov commented on CASSANDRA-15652: - Committed revision 38635. Thank you for review! > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Alex Petrov >Assignee: Michael Shuler >Priority: Normal > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.html -- 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
svn commit: r38635 - /release/cassandra/KEYS
Author: ifesdjeen Date: Thu Mar 26 18:13:43 2020 New Revision: 38635 Log: Add Alex Petrov's key for releases Modified: release/cassandra/KEYS Modified: release/cassandra/KEYS == --- release/cassandra/KEYS (original) +++ release/cassandra/KEYS Thu Mar 26 18:13:43 2020 @@ -3945,3 +3945,62 @@ YWNH0Fh8w55RpcYw+YdtByxkNHdP6HJtiO1Uh+v8 E6p3itpaZgB9hVn3uDs= =NPWM -END PGP PUBLIC KEY BLOCK- +pub rsa4096 2020-03-21 [SC] + 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C +uid [ultimate] Alex Petrov +sig 3F1000962B7F6840C 2020-03-21 Alex Petrov +sub rsa4096 2020-03-21 [E] +sig F1000962B7F6840C 2020-03-21 Alex Petrov + +-BEGIN PGP PUBLIC KEY BLOCK- + +mQINBF5196gBEAC+1mRiTEoslCzdVX52B5Zf4YEagljCQ6eeDf6RJaqqyzQH3oIh +R5548mdX4v1NY9d6fw963BfgIezL13holmvIhEDDOr+gvFc9vibxr6x7RtSCSqey +VvKfEWzj9T3YDlR4kY41k9EPHwrtlTCXRDyKLv9a8tQoL1lEyXduWyeKAIcar+HC ++FXR/wf/Zp0Wl+BMEWBCDKSCQL2DRViDwb6H+pTBMhjK1qP6wdCzWrdFVul9tqnA +bM24BgchsegUPpet2zwu+NkWUMXJP+upLhoQMPDYwo1GRrqe6hOX53X19NPe3y3f +sq/Z3fmrvYWZK068RKRVOnGXn/NMcQ9j1xUjHcv2oVi7Atdgq6lE4wFcG68DsJff +ATK0TGJCGayPMEPzK/qboDhxWZ1EqX9hBaXasld07ybEg6s+0ounok6yV5zY5U9s +PEKeYGmdy31ib7KzBC3laua6L++M2O78GVqNVrGhbkUvR5lxZYWSsAAAH2m/XA+a +td/LK1MTcdgs3K844GbVh0KXhEIg7Q14RwfUCJO8LRg7R4ltEHsemCpWuUEhzlTg +wd4+MnZKdkFSMeePtJuVm7SmRWHjJ8n81ZUTd64cwIdP4ZQEkAa45pVpJ9Tx++Zv +L7wHuhDXWBvYgwta2aOrItO0re5W6UGFk+5Wxi6c6wxg80bwW7DhRAlRSQARAQAB +tChBbGV4IFBldHJvdiA8b2xla3NhbmRyLnBldHJvdkBnbWFpbC5jb20+iQJOBBMB +CAA4FiEEnmbOxhBtV40LHrm/8QAJYrf2hAwFAl5196gCGwMFCwkIBwIGFQoJCAsC +BBYCAwECHgECF4AACgkQ8QAJYrf2hAzR9w//WTXz+9kLi707OO36DAb5oeej9SVG +8Kg/947nYaPmDtLyghIkB6n0/ADsksQZbyX9Oy/XRJ+0Rns6k455+BABMbPuTg1v +EY2vEEGn6D+pyO7Q7RDNAjmDXF0vVo3ubimyRJ02fr4jDow27DBnzGJU+nGT5/x5 +gp8TJ3UAz6AVpBVsu141LZZpc5EB/jlW25MU/l0TF/nP4NqtIpno/GZTj+Isn+yd +EKuUcLjWBXDBh9ryTr5lLp7FjX9iDA45WDKODt2BbwS2d3vEosEjrNkDHDSFZX0+ +AvF17HI4+AIMaBmD4uEmimqr7VxZQwPpmK6OzIOF9Tp2AnNEqqh/egkWwXMJ3ASp +kDhglEfy5IgWa7IdLRluNZOcij5wCLLJlFAlhHPAI/ubojSoq7oSx//mGCV5W8jo +WG234g9Ee43fv/2FAMZ1uA/XRo3mQLhg1Qawma1BobtMNDeQMXOfPrQ38wJ2QKcL +IHpnL7cTU+2j1rTmspo43G39dVwGyl6e/ETRrClF40Pqa9lXCJiynUuOb8gBh4MJ +87raCKv8CPn983oB+dWU/P+Tar48Us6QrRKqFTJULu9SYddXM2MVcNlCsM3BYFik +KIFkhyoUwAfZSJ4lTVldBRHty0XACaTzXVuHgAa5FtaGfYk4r09qLI1utjipZhqj +4WUSoyIRwydbYWO5Ag0EXnX3qAEQAN2aCoM2idDJFxjm5aDXDkBgjVvgTLKIxQSY +OFhSUiUtuQ4RdjvSbzQIBFSnRfFpA4XCjd9IfvIgOedHJp5yem8wm1Z8vDrnQSta +K83+xfITazMpzKotH7I62O8qAqk1NNjdmDHQCsYusY31+F0qyz9XcjOWsMMBgQso +amcEX1uHqHp3zDkBrEUDreHaOTBO8iB1OpSwAvVKQyrdvdYIUiFyqRxj/tX0e4QB +jTL5dl2zwR9HxCJdqaAE7hHIdCRlm0vGBRIEc5r3jrtCpm9oxt3XLfFKgHY7AxJx +CdR9BE/BmxGdxJksImwVqg6DWlzs4HmU7QvTGdBklSbkOQ3RTM71q46Y0w0815kz +DEPi9fZiBjyeeu/gBdgS/IY1177q+wgd2Uoip/4PN04IoPTIKvzLNxvnWh5YJ2Hw +xqaQmHQtMOm5nZksNBziedwXyzP5LaUOrvj4T/e8tHosRLUYH32RwoHUR6Isx1Rs +FEuiqCix1R1YmXCvfpAz0OUwpdDHIbOisvin68QVlZ10EVa7GeYGEaNSiSlIRk53 +CyQbcgACSdT4LP/zvFM9oHoXSlzonFdsHs0euZy5mf/WA0rJPtfB7gqY4ZK52M4I +EPTcQb11gWzVKB5Z0PPNmx2WgR1fEgax0I713KKpyPrhVz4FK1MXTDLDTzRC6ObF +hEBOvtWJABEBAAGJAjYEGAEIACAWIQSeZs7GEG1XjQseub/xAAlit/aEDAUCXnX3 +qAIbDAAKCRDxAAlit/aEDMuxD/9TbpXdVSQpDi4SeDaP2gP7tywOlujuWpPKVy2d +pQXf4XbQwifkgU8Io0FIXFAZSityqFc8lhWlnX4v95mB/xKMktlpkfSuPDcTBaLj +CX5ztUcASnrPGgJJUP429yAWrbMZo/MkbdCn6F7vwvsLeDq7+aJFEx+GsQdH7blm +qelsAyvKJyonk9X5jXMXOjTNsfHhRNTgrAqJ5NRUuWV1MNlDOFljGqBIx9MAd2kh +UlkhUaftQlf9WQdjI6CUFbr/TWOOO3FofV3gxNZFSy5RH6y0DftrDqhKOyw5S76T +DFzPRf7UYhSXrtcFQ/Gm1gHF2jgz9niCStKC3t2aGK5HR32NX+XOdU3icvtYRQlM +R0l3MeTg+X9RtBEBsLfo4P6Q/WKwZcNfeXxYc1yI3jrjzt/XUUfyeS1nAsL+tXEv +Ehrolbs/vzHANro8uKFHEf+WfO3Aa7DK1diOgxeBmSegsgwF3OUUP5swByQrRf7c +EKIocWWQK4Xnm9SbS4vziCL7FO+HdUSFAmwipvp+2MtEKGf84tQo1hTY0/Piz4TW +LTgCCnChxrzLJekFyRNH+0+Gf71m2+FhVazpiIl7qTHq9LrTJMERiQupvD1pyzB5 +aF4Pcs75aALTXIamt62MKRbd4Uxh6gRiAOZF3muNYt7xnDvNtIoQl7WHVq8Y+db3 +lSILgQ== +=Hk6U +-END PGP PUBLIC KEY BLOCK- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15652: --- Status: Ready to Commit (was: Review In Progress) > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Alex Petrov >Assignee: Michael Shuler >Priority: Normal > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.html -- 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-15652) add ifesdjeen's gpg key to project's KEYS file
[
https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-15652:
---
Reviewers: Michael Shuler, Michael Shuler (was: Michael Shuler)
Michael Shuler, Michael Shuler
Status: Review In Progress (was: Patch Available)
Alex sent his key to the SKS pool and we verified on slack.
Before:
{{$ gpg --verbose --search-keys --keyserver
hkps://hkps.pool.sks-keyservers.net 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C}}
{{ gpg: data source: [https://192.146.137.140:443|https://192.146.137.140/]}}
{{ gpg: key "9E66CEC6106D578D0B1EB9BFF1000962B7F6840C" not found on keyserver}}
{{ gpg: keyserver search failed: Not found}}
Now:
{{$ gpg --verbose --search-keys --keyserver
hkps://hkps.pool.sks-keyservers.net 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C}}
{{ gpg: data source: [https://192.146.137.140:443|https://192.146.137.140/]}}
{{ (1) Alex Petrov }}
{{ 4096 bit RSA key F1000962B7F6840C, created: 2020-03-21}}
{{ Keys 1-1 of 1 for "9E66CEC6106D578D0B1EB9BFF1000962B7F6840C". Enter
number(s), N)ext, or Q)uit > 1}}
{{ gpg: data source: [https://192.146.137.140:443|https://192.146.137.140/]}}
{{ gpg: armor header: Version: SKS 1.1.6}}
{{ gpg: armor header: Comment: Hostname: pgpkeys.uk}}
{{ gpg: pub rsa4096/F1000962B7F6840C 2020-03-21 Alex Petrov
}}
{{ gpg: key F1000962B7F6840C: "Alex Petrov " not
changed}}
{{ gpg: Total number processed: 1}}
{{ gpg: unchanged: 1}}
> add ifesdjeen's gpg key to project's KEYS file
> --
>
> Key: CASSANDRA-15652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15652
> Project: Cassandra
> Issue Type: Task
> Components: Packaging
>Reporter: Alex Petrov
>Assignee: Michael Shuler
>Priority: Normal
> Attachments: keys.patch
>
>
> The patch adds my gpg public key to the project's KEYS file found at
> https://dist.apache.org/repos/dist/release/cassandra/KEYS
> My gpg public key here has the fingerprint
> 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> References:
> - https://www.apache.org/dev/release-signing#keys-policy
> - http://www.apache.org/legal/release-policy.html
--
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-15337) Document usage of Ec2Snitch for multiple regions cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-15337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067910#comment-17067910
]
Jon Haddad commented on CASSANDRA-15337:
I didn't realize there was a patch available for this. [~serban] in the future
please use the "submit patch" button or create a PR that includes the JIRA
ticket in the title and it'll auto link to it.
> Document usage of Ec2Snitch for multiple regions cluster
>
>
> Key: CASSANDRA-15337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15337
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
>
> Ec2MultiRegionSnitch was (probably) done because it was not possible in AWS
> to have intra-region VPC peering. This changed pin 2017, see [AWS
> announcement|https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/]
> (and extended with 9 more regions in 2018, see
> [link|https://aws.amazon.com/about-aws/whats-new/2018/02/inter-region-vpc-peering-is-now-available-in-nine-additional-aws-regions/]):
> {quote}Inter-Region VPC Peering allows VPC resources like EC2 instances[...]
> running in different AWS regions to communicate with each other using private
> IP addresses, without requiring gateways, VPN connections or separate network
> appliances.
> {quote}
> Since the datacenter/rack names are loaded in Ec2Snitch using AWS API there
> is no reason why this snitch would not work in a multi-datacenter setup. I
> tested and used this in a production environment. So the documentation should
> be changed to include this usage.
> Proposed change:
> [https://github.com/apache/cassandra/compare/trunk...serban21:15337-trunk]
--
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] (CASSANDRASC-12) Fix yaml vulnerability
Jon Haddad created CASSANDRASC-12: - Summary: Fix yaml vulnerability Key: CASSANDRASC-12 URL: https://issues.apache.org/jira/browse/CASSANDRASC-12 Project: Sidecar for Apache Cassandra Issue Type: Bug Reporter: Jon Haddad Assignee: Jon Haddad There’s a minor bug in the way we process yaml configuration. We should bump our commons-configuration2 dependency to the latest release and fix how we load the 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] [Assigned] (CASSANDRA-15666) Race condition when completing stream sessions
[
https://issues.apache.org/jira/browse/CASSANDRA-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-15666:
--
Reviewers: Benjamin Lerer, Sergio Bossa
Assignee: ZhaoYang
> Race condition when completing stream sessions
> --
>
> Key: CASSANDRA-15666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15666
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: ZhaoYang
>Priority: Normal
>
> {{StreamSession#prepareAsync()}} executes, as the name implies,
> asynchronously from the IO thread: this opens up for race conditions between
> the sending of the {{PrepareSynAckMessage}} and the call to
> {{StreamSession#maybeCompleted()}}. I.e., the following could happen:
> 1) Node A sends {{PrepareSynAckMessage}} from the {{prepareAsync()}} thread.
> 2) Node B receives it and starts streaming.
> 3) Node A receives the streamed file and sends {{ReceivedMessage}}.
> 4) At this point, if this was the only file to stream, both nodes are ready
> to close the session via {{maybeCompleted()}}, but:
> a) Node A will call it twice from both the IO thread and the thread at #1,
> closing the session and its channels.
> b) Node B will attempt to send a {{CompleteMessage}}, but will fail because
> the session has been closed in the meantime.
> There are other subtle variations of the pattern above, depending on the
> order of concurrently sent/received messages.
> I believe the best fix would be to modify the message exchange so that:
> 1) Only the "follower" is allowed to send the {{CompleteMessage}}.
> 2) Only the "initiator" is allowed to close the session and its channels
> after receiving the {{CompleteMessage}}.
> By doing so, the message exchange logic would be easier to reason about,
> which is overall a win anyway.
--
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-15661) Improve logging by using more appropriate levels
[ https://issues.apache.org/jira/browse/CASSANDRA-15661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067835#comment-17067835 ] Jon Haddad commented on CASSANDRA-15661: I'll have Jenkins test results here as soon as I'm able to run unit + dtests. ATM the new jenkins setup is failing my builds and CircleCI bombs out when running dtests on medium instances. I can't think of a reason why unit tests would break, but dtests might be relying on logs at a specific level. Hopefully I can get the CI results posted today. > Improve logging by using more appropriate levels > - > > Key: CASSANDRA-15661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15661 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > There are a number of log statements using logging levels that are a bit too > conservative. For example: > * Flushing memtables is currently at debug. This is a relatively rare event > that is important enough to be INFO > * When compaction finishes we log the progress at debug > * Different steps in incremental repair are logged as debug, should be INFO > * when reaching connection limits in ConnectionLimitHandler.java we log at > warn rather than error. Since this is a client disconnect it’s more than a > warning, we’re taking action and disconnecting. -- 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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15652: --- Authors: Alex Petrov (was: Michael Shuler) Test and Documentation Plan: Merge, import KEYS file, check sig. Status: Patch Available (was: Open) > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Alex Petrov >Assignee: Michael Shuler >Priority: Normal > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.html -- 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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15652: --- Change Category: Operability Complexity: Normal Component/s: Packaging Status: Open (was: Triage Needed) > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Alex Petrov >Assignee: Michael Shuler >Priority: Normal > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.html -- 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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler reassigned CASSANDRA-15652: -- Assignee: Michael Shuler > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task >Reporter: Alex Petrov >Assignee: Michael Shuler >Priority: Normal > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.html -- 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-15652) add ifesdjeen's gpg key to project's KEYS file
[
https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067823#comment-17067823
]
Michael Shuler edited comment on CASSANDRA-15652 at 3/26/20, 4:41 PM:
--
Yep! A couple of us cross-signed keys a few years back at a Cassandra Summit,
this is a good idea and I'd be happy to sign.
[~ifesdjeen], I've never used a web thing to upload keys. I can search your key
on the Ubuntu keyserver, but from a little reading, it appears that sync of
that keyserver to other keyservers is super latent. I still cannot search your
key on SKS, MIT, or Surfnet. If you could do the following in a shell, it
should be be searchable from the main SKS keyserver pool, which is the usual
default for any gpg install:
{{gpg --verbose --send-keys --keyserver hkps://hkps.pool.sks-keyservers.net
9E66CEC6106D578D0B1EB9BFF1000962B7F6840C}}
That should hit 98% of gpg users and all the plugins like Enigmail.
+1 to merge when the public key can be found :)
To test (example is my key fingerprint):
{{mshuler@hana:~$ gpg --verbose --search-keys --keyserver
hkps://hkps.pool.sks-keyservers.net A26E528B271F19B9E5D8E19EA278B781FE4B2BDA}}
{{gpg: data source: https://162.213.33.9:443}}
{{(1) Michael Shuler }}
{{ Michael Shuler }}
{{ 4096 bit RSA key A278B781FE4B2BDA, created: 2009-07-15}}
{{Keys 1-1 of 1 for "A26E528B271F19B9E5D8E19EA278B781FE4B2BDA". Enter
number(s), N)ext, or Q)uit > 1}}
{{gpg: data source: https://162.213.33.9:443}}
{{gpg: key A278B781FE4B2BDA: number of dropped non-self-signatures: 33}}
{{gpg: pub rsa4096/A278B781FE4B2BDA 2009-07-15 Michael Shuler
}}
{{gpg: key A278B781FE4B2BDA: "Michael Shuler " not
changed}}
{{gpg: Total number processed: 1}}
{{gpg: unchanged: 1}}
was (Author: mshuler):
Yep! A couple of us cross-signed keys a few years back at a Cassandra Summit,
this is a good idea and I'd be happy to sign.
[~ifesdjeen], I've never used a web thing to upload keys. I can search your key
on the Ubuntu keyserver, but from a little reading, it appears that sync of
that keyserver to other keyservers is super latent. I still cannot search your
key on SKS, MIT, or Surfnet. If you could do the following in a shell, it
should be be searchable from the main SKS keyserver pool, which is the usual
default for any gpg install:
{{gpg --verbose --send-keys --keyserver hkps://hkps.pool.sks-keyservers.net
9E66CEC6106D578D0B1EB9BFF1000962B7F6840C}}
That should hit 98% of gpg users and all the plugins like Enigmail.
+1 to merge when the public key can be found :)
To test (example is my key fingerprint):
{{mshuler@hana:~$ gpg --verbose --search-keys --keyserver --keyserver
hkps://hkps.pool.sks-keyservers.net A26E528B271F19B9E5D8E19EA278B781FE4B2BDA}}
{{gpg: data source: https://162.213.33.9:443}}
{{(1) Michael Shuler }}
{{ Michael Shuler }}
{{ 4096 bit RSA key A278B781FE4B2BDA, created: 2009-07-15}}
{{Keys 1-1 of 1 for "A26E528B271F19B9E5D8E19EA278B781FE4B2BDA". Enter
number(s), N)ext, or Q)uit > 1}}
{{gpg: data source: https://162.213.33.9:443}}
{{gpg: key A278B781FE4B2BDA: number of dropped non-self-signatures: 33}}
{{gpg: pub rsa4096/A278B781FE4B2BDA 2009-07-15 Michael Shuler
}}
{{gpg: key A278B781FE4B2BDA: "Michael Shuler " not
changed}}
{{gpg: Total number processed: 1}}
{{gpg: unchanged: 1}}
> add ifesdjeen's gpg key to project's KEYS file
> --
>
> Key: CASSANDRA-15652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15652
> Project: Cassandra
> Issue Type: Task
>Reporter: Alex Petrov
>Priority: Normal
> Attachments: keys.patch
>
>
> The patch adds my gpg public key to the project's KEYS file found at
> https://dist.apache.org/repos/dist/release/cassandra/KEYS
> My gpg public key here has the fingerprint
> 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> References:
> - https://www.apache.org/dev/release-signing#keys-policy
> - http://www.apache.org/legal/release-policy.html
--
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-14754) Add verification of state machine in StreamSession
[
https://issues.apache.org/jira/browse/CASSANDRA-14754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067826#comment-17067826
]
Sergio Bossa commented on CASSANDRA-14754:
--
I think just validating state transitions doesn't really add much: for example,
moving from {{INITIALIZED}} to {{COMPLETE}} is
[valid|https://github.com/apache/cassandra/pull/480/files#diff-b397cc5438b1a4be20f026c9ec9ecd6eR215],
but only if there's nothing to actually stream, which is not expressed in the
current validation (IIUIC, correct me if I'm wrong). In other words, I think it
would be best to implement a proper state machine, but is it really necessary
for 4.0? OTOH, I think we should focus on other {{StreamSession}} bugs such as
CASSANDRA-15665 and CASSANDRA-15666. Thoughts?
> Add verification of state machine in StreamSession
> --
>
> Key: CASSANDRA-14754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14754
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Streaming and Messaging
>Reporter: Jason Brown
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamSession}} contains an implicit state machine, but we have no
> verification of the safety of the transitions between states. For example, we
> have no checks to ensure we cannot leave the final states (COMPLETED, FAILED).
> I propose we add some program logic in {{StreamSession}}, tests, and
> documentation to ensure the correctness of the state transitions.
--
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-15652) add ifesdjeen's gpg key to project's KEYS file
[
https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067823#comment-17067823
]
Michael Shuler commented on CASSANDRA-15652:
Yep! A couple of us cross-signed keys a few years back at a Cassandra Summit,
this is a good idea and I'd be happy to sign.
[~ifesdjeen], I've never used a web thing to upload keys. I can search your key
on the Ubuntu keyserver, but from a little reading, it appears that sync of
that keyserver to other keyservers is super latent. I still cannot search your
key on SKS, MIT, or Surfnet. If you could do the following in a shell, it
should be be searchable from the main SKS keyserver pool, which is the usual
default for any gpg install:
{{gpg --verbose --send-keys --keyserver hkps://hkps.pool.sks-keyservers.net
9E66CEC6106D578D0B1EB9BFF1000962B7F6840C}}
That should hit 98% of gpg users and all the plugins like Enigmail.
+1 to merge when the public key can be found :)
To test (example is my key fingerprint):
{{mshuler@hana:~$ gpg --verbose --search-keys --keyserver --keyserver
hkps://hkps.pool.sks-keyservers.net A26E528B271F19B9E5D8E19EA278B781FE4B2BDA}}
{{gpg: data source: https://162.213.33.9:443}}
{{(1) Michael Shuler }}
{{ Michael Shuler }}
{{ 4096 bit RSA key A278B781FE4B2BDA, created: 2009-07-15}}
{{Keys 1-1 of 1 for "A26E528B271F19B9E5D8E19EA278B781FE4B2BDA". Enter
number(s), N)ext, or Q)uit > 1}}
{{gpg: data source: https://162.213.33.9:443}}
{{gpg: key A278B781FE4B2BDA: number of dropped non-self-signatures: 33}}
{{gpg: pub rsa4096/A278B781FE4B2BDA 2009-07-15 Michael Shuler
}}
{{gpg: key A278B781FE4B2BDA: "Michael Shuler " not
changed}}
{{gpg: Total number processed: 1}}
{{gpg: unchanged: 1}}
> add ifesdjeen's gpg key to project's KEYS file
> --
>
> Key: CASSANDRA-15652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15652
> Project: Cassandra
> Issue Type: Task
>Reporter: Alex Petrov
>Priority: Normal
> Attachments: keys.patch
>
>
> The patch adds my gpg public key to the project's KEYS file found at
> https://dist.apache.org/repos/dist/release/cassandra/KEYS
> My gpg public key here has the fingerprint
> 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> References:
> - https://www.apache.org/dev/release-signing#keys-policy
> - http://www.apache.org/legal/release-policy.html
--
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-15666) Race condition when completing stream sessions
Sergio Bossa created CASSANDRA-15666:
Summary: Race condition when completing stream sessions
Key: CASSANDRA-15666
URL: https://issues.apache.org/jira/browse/CASSANDRA-15666
Project: Cassandra
Issue Type: Bug
Components: Legacy/Streaming and Messaging
Reporter: Sergio Bossa
{{StreamSession#prepareAsync()}} executes, as the name implies, asynchronously
from the IO thread: this opens up for race conditions between the sending of
the {{PrepareSynAckMessage}} and the call to
{{StreamSession#maybeCompleted()}}. I.e., the following could happen:
1) Node A sends {{PrepareSynAckMessage}} from the {{prepareAsync()}} thread.
2) Node B receives it and starts streaming.
3) Node A receives the streamed file and sends {{ReceivedMessage}}.
4) At this point, if this was the only file to stream, both nodes are ready to
close the session via {{maybeCompleted()}}, but:
a) Node A will call it twice from both the IO thread and the thread at #1,
closing the session and its channels.
b) Node B will attempt to send a {{CompleteMessage}}, but will fail because the
session has been closed in the meantime.
There are other subtle variations of the pattern above, depending on the order
of concurrently sent/received messages.
I believe the best fix would be to modify the message exchange so that:
1) Only the "follower" is allowed to send the {{CompleteMessage}}.
2) Only the "initiator" is allowed to close the session and its channels after
receiving the {{CompleteMessage}}.
By doing so, the message exchange logic would be easier to reason about, which
is overall a win anyway.
--
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-15631) Add AssertJ test dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067816#comment-17067816
]
Kevin Gallardo commented on CASSANDRA-15631:
Hey [~dcapwell] thank you very much for looking into it. For some reason I did
not get a notification of your comment and have done some more work on the
branch since then. Notably: I put the AssertJ dependency to 3.15.
bq. at line is there a reason you added the round? It slightly changes the
original test behavior; I don't mind, but it is a semantic difference.
Right, I had rounded because {{measureDeep()}} returns a long and the signature
of {{isLessThan()}} doesn't allow for a double, but instead I should change the
compared value to a double so I don't have to round.
bq. at line you dropped this assert
Not sure which assert you were referring to since the code has changed since
your comment, but tracing back to the line number you linked on trunk points to
the assert on {{session.getSyncingTasks().size()}}. In my branch it was changed
to {{assertThat(session.getSyncingTasks()).isEmpty()}}, so the functionality
should be equivalent. Please let me know if you were referring to another
assert.
bq. at line should we change the assert message to be more clear? This will
only print out the numbers, may be nice to comment that they are object sizes.
Makes sense, will change that.
For CI, you can see the runs at
https://app.circleci.com/pipelines/github/newkek/cassandra?branch=15631-trunk .
Latest run (#17) had a failure that didn't seem related to these changes, and
the test passed when I ran it locally.
> Add AssertJ test dependency
> ---
>
> Key: CASSANDRA-15631
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15631
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest, Test/unit
>Reporter: Kevin Gallardo
>Assignee: Kevin Gallardo
>Priority: Normal
> Fix For: 4.0-beta
>
>
> See
> [proposal|https://lists.apache.org/thread.html/rc562ec47578d0ae6f346ba9e3d7469c1cd3f8b521a72ddcb2accc47b%40%3Cdev.cassandra.apache.org%3E].
> The goal is to add [AssertJ|https://assertj.github.io/doc/] to the test
> framework to allow for more comprehensible and easier to write tests.
--
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-15649) test.distributed.timeout no longer respected in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-15649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15649: --- Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever) Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever) Status: Review In Progress (was: Patch Available) > test.distributed.timeout no longer respected in CircleCI > > > Key: CASSANDRA-15649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15649 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Time Spent: 1h > Remaining Estimate: 0h > > After switching jvm dtest over testclasslist (CASSANDRA-15508) we no longer > respect the dtest timeout and instead use the unit test timeout (4m vs 6m). > This does not impact Jenkins as I made sure to check that before calling > testclasslist; though this does impact 2.2, 3.0, and 3.11 as well. > ||Config||Trunk||3.11||3.0||2.2|| > |LOWER||[Circle > CI|https://circleci.com/workflow-run/04f7fbe2-1919-4da0-bf72-ba41b41c3072]| > [Circle > CI|https://circleci.com/workflow-run/69c64062-80f5-4d08-8ab0-dbe88ce7b236] | > [Circle > CI|https://circleci.com/workflow-run/499d2fbe-a8c1-4a27-9430-a9ebb40aad53] | > [Circle > CI|https://circleci.com/workflow-run/fedbd5b8-683d-4c59-a9f6-3aad5a6ba41d] | > |HIGHER| [Circle > CI|https://circleci.com/workflow-run/036bbad1-541a-49dc-a567-cef2300fa847] | > TBD | TBD | TBD | > CI Failures were flaky tests, below are their links > * CASSANDRA-15630 -- 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-15649) test.distributed.timeout no longer respected in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-15649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15649: --- Status: Ready to Commit (was: Review In Progress) > test.distributed.timeout no longer respected in CircleCI > > > Key: CASSANDRA-15649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15649 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Time Spent: 1h > Remaining Estimate: 0h > > After switching jvm dtest over testclasslist (CASSANDRA-15508) we no longer > respect the dtest timeout and instead use the unit test timeout (4m vs 6m). > This does not impact Jenkins as I made sure to check that before calling > testclasslist; though this does impact 2.2, 3.0, and 3.11 as well. > ||Config||Trunk||3.11||3.0||2.2|| > |LOWER||[Circle > CI|https://circleci.com/workflow-run/04f7fbe2-1919-4da0-bf72-ba41b41c3072]| > [Circle > CI|https://circleci.com/workflow-run/69c64062-80f5-4d08-8ab0-dbe88ce7b236] | > [Circle > CI|https://circleci.com/workflow-run/499d2fbe-a8c1-4a27-9430-a9ebb40aad53] | > [Circle > CI|https://circleci.com/workflow-run/fedbd5b8-683d-4c59-a9f6-3aad5a6ba41d] | > |HIGHER| [Circle > CI|https://circleci.com/workflow-run/036bbad1-541a-49dc-a567-cef2300fa847] | > TBD | TBD | TBD | > CI Failures were flaky tests, below are their links > * CASSANDRA-15630 -- 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-15618) add docs for production recommendations
[ https://issues.apache.org/jira/browse/CASSANDRA-15618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15618: --- Reviewers: Jordan West > add docs for production recommendations > --- > > Key: CASSANDRA-15618 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15618 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We have some inline comments in our yaml, but I think it would be helpful if > we had a more lengthy section in the docs detailing the settings people > should be using in production. Some of these are unrelated to the yaml > itself (like reducing read ahead), and putting them in the YAML doesn’t make > much sense. There are also other settings (like compression chunk length) > that don’t fit there. Let’s add a page under getting started called > Production Recommendations. -- 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-15153) Caffeine cache return stale entries
[ https://issues.apache.org/jira/browse/CASSANDRA-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Per Otterström updated CASSANDRA-15153: --- Bug Category: Parent values: Security(12985)Level 1 values: Privilege Escalation(13000) Component/s: Feature/Authorization Discovered By: Unit Test Impacts: Security (was: None) Since Version: 4.0-alpha > Caffeine cache return stale entries > --- > > Key: CASSANDRA-15153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15153 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Per Otterström >Priority: Normal > Labels: security > > Version 2.3.5 of the Caffeine cache that we're using in various places can > hand out stale entries in some cases. This seem to happen when an update > fails repeatedly, in which case Caffeine may return a previously loaded > value. For instance, the AuthCache may hand out permissions even though the > reload operation is failing, see CASSANDRA-15041. -- 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-15630) Fix flakey testSerializeError - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067789#comment-17067789
]
Yifan Cai commented on CASSANDRA-15630:
---
CI passed. Link:
https://app.circleci.com/pipelines/github/yifan-c/cassandra/59/workflows/9b1dee87-f930-4729-a577-71da5fc9660c/jobs/282
However, I do not think it is very representative. (There are other flaky tests
in the code base, a green run is more because of luck).
In addition, I made a docker container that caps CPUs to 2 to run the
{{ConnectionTest}} repeatedly until failure. [^CASS-15630-TEST-DOCKER.zip]
It applies another flaky test fixing patch that has not been merged yet before
running the repeating test. On my local, the test passes for dozen times.
Regarding the comment, it is probably better to use {{spinAssertEquals}}
explicitly. If you strongly prefer to use testAndFailCheck, I am cool with it.
Thanks all for reviewing!
> Fix flakey testSerializeError - org.apache.cassandra.net.ConnectionTest
> ---
>
> Key: CASSANDRA-15630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15630
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-beta
>
> Attachments: CASS-15630-TEST-DOCKER.zip
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The test fails sometimes with the following error message and trace.
> {code:java}
> processed count values don't match expected:<90> but was:<89>
> junit.framework.AssertionFailedError: processed count values don't match
> expected:<90> but was:<89>
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:217)
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testSerializeError$24(ConnectionTest.java:494)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:240)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:260)
> at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:238)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:227)
> at
> org.apache.cassandra.net.ConnectionTest.testSerializeError(ConnectionTest.java:435){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15630) Fix flakey testSerializeError - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-15630:
--
Attachment: CASS-15630-TEST-DOCKER.zip
> Fix flakey testSerializeError - org.apache.cassandra.net.ConnectionTest
> ---
>
> Key: CASSANDRA-15630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15630
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-beta
>
> Attachments: CASS-15630-TEST-DOCKER.zip
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The test fails sometimes with the following error message and trace.
> {code:java}
> processed count values don't match expected:<90> but was:<89>
> junit.framework.AssertionFailedError: processed count values don't match
> expected:<90> but was:<89>
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:217)
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testSerializeError$24(ConnectionTest.java:494)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:240)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:260)
> at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:238)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:227)
> at
> org.apache.cassandra.net.ConnectionTest.testSerializeError(ConnectionTest.java:435){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15664) Handle wrapping ranges in token range compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-15664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15664: --- Status: Ready to Commit (was: Review In Progress) > Handle wrapping ranges in token range compaction > > > Key: CASSANDRA-15664 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15664 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-alpha > > > We currently don't handle wrapping ranges in token range compaction -- 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-15664) Handle wrapping ranges in token range compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-15664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15664: --- Reviewers: Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer) Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer) Status: Review In Progress (was: Patch Available) +1 > Handle wrapping ranges in token range compaction > > > Key: CASSANDRA-15664 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15664 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-alpha > > > We currently don't handle wrapping ranges in token range compaction -- 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-15153) Caffeine cache return stale entries
[ https://issues.apache.org/jira/browse/CASSANDRA-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Per Otterström updated CASSANDRA-15153: --- Labels: security (was: ) > Caffeine cache return stale entries > --- > > Key: CASSANDRA-15153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15153 > Project: Cassandra > Issue Type: Bug >Reporter: Per Otterström >Priority: Normal > Labels: security > > Version 2.3.5 of the Caffeine cache that we're using in various places can > hand out stale entries in some cases. This seem to happen when an update > fails repeatedly, in which case Caffeine may return a previously loaded > value. For instance, the AuthCache may hand out permissions even though the > reload operation is failing, see CASSANDRA-15041. -- 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-15153) Caffeine cache return stale entries
[
https://issues.apache.org/jira/browse/CASSANDRA-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067783#comment-17067783
]
Per Otterström commented on CASSANDRA-15153:
I've created a [unit
test|https://github.com/apache/cassandra/compare/trunk...eperott:15153-trunk]
to reproduce this
[issue|https://circleci.com/gh/eperott/cassandra/215#tests/containers/1].
In short, a {{LoadingCache}} may return a stale entry if its load function at
some point start to throw exceptions for a key.
The bug seem to be fixed in Caffeine version 2.5.0 and later.
I guess there are a couple of questions that we need to take a stance on here.
# Should we risk upgrading the Caffeine version because of this? Caffeine is
used in 12 different classes in trunk.
# And if so, should we make the minimal change and move to 2.5.0, or something
later?
FWIW, I'm not able to create a scenario where I can exploit this. A potential
one would've been to login as a user after it was deleted in the database
(causing the load function to throw {{AuthenticationException}}). However,
other permission checks prevent the login attempt from completing. Then again,
this doesn't prove there isn't a way to exploit this!
> Caffeine cache return stale entries
> ---
>
> Key: CASSANDRA-15153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15153
> Project: Cassandra
> Issue Type: Bug
>Reporter: Per Otterström
>Priority: Normal
>
> Version 2.3.5 of the Caffeine cache that we're using in various places can
> hand out stale entries in some cases. This seem to happen when an update
> fails repeatedly, in which case Caffeine may return a previously loaded
> value. For instance, the AuthCache may hand out permissions even though the
> reload operation is failing, see CASSANDRA-15041.
--
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-15543) flaky test org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067780#comment-17067780
]
Kevin Gallardo commented on CASSANDRA-15543:
Thanks [~blerer]!
> flaky test
> org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
> ---
>
> Key: CASSANDRA-15543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: Kevin Gallardo
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> This fails infrequently, last seen failure was on java 8
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
> {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-14606) Add documentation for java 11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-14606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067775#comment-17067775 ] Stefan Miklosovic commented on CASSANDRA-14606: --- This was likely already covered? I see Java 11 related documentation and build steps here [https://cassandra.apache.org/doc/latest/new/java11.html] > Add documentation for java 11 support > - > > Key: CASSANDRA-14606 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14606 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jason Brown >Priority: Low > Labels: Java11 > Fix For: 4.0 > > > Let's add some documentation for operators around the java 11 support that > was introduced in CASSANDRA-9608. Also, we should point out changes in the > scripts that might affect automation that operators have in place. > Parking on [~snazy] just 'cuz ;) -- 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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067761#comment-17067761 ] Michael Semb Wever commented on CASSANDRA-15652: +1. it looks good to me. (it would be better if keys were in a web of trust, but mine isn't either. i'm guessing we can update the KEYS after the next Accelerate/NGCC/ApacheCon/etc) > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task >Reporter: Alex Petrov >Priority: Normal > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.html -- 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-15649) test.distributed.timeout no longer respected in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-15649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067742#comment-17067742 ] Michael Semb Wever commented on CASSANDRA-15649: bq. in case the CI runs are not visible (reached out to circle ci team about this), all LOWERs passed and confirmed the change took affect (2.2 had a test failure, I don't monitor 2.2 so not familiar with its flaky tests, but I did see the change was picked up). Thanks. (The circleci links are still not visible) > test.distributed.timeout no longer respected in CircleCI > > > Key: CASSANDRA-15649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15649 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Time Spent: 1h > Remaining Estimate: 0h > > After switching jvm dtest over testclasslist (CASSANDRA-15508) we no longer > respect the dtest timeout and instead use the unit test timeout (4m vs 6m). > This does not impact Jenkins as I made sure to check that before calling > testclasslist; though this does impact 2.2, 3.0, and 3.11 as well. > ||Config||Trunk||3.11||3.0||2.2|| > |LOWER||[Circle > CI|https://circleci.com/workflow-run/04f7fbe2-1919-4da0-bf72-ba41b41c3072]| > [Circle > CI|https://circleci.com/workflow-run/69c64062-80f5-4d08-8ab0-dbe88ce7b236] | > [Circle > CI|https://circleci.com/workflow-run/499d2fbe-a8c1-4a27-9430-a9ebb40aad53] | > [Circle > CI|https://circleci.com/workflow-run/fedbd5b8-683d-4c59-a9f6-3aad5a6ba41d] | > |HIGHER| [Circle > CI|https://circleci.com/workflow-run/036bbad1-541a-49dc-a567-cef2300fa847] | > TBD | TBD | TBD | > CI Failures were flaky tests, below are their links > * CASSANDRA-15630 -- 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-15665) StreamManager should clearly differentiate between "initiator" and "receiver" sessions
[
https://issues.apache.org/jira/browse/CASSANDRA-15665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-15665:
--
Reviewers: Benjamin Lerer, Sergio Bossa
Assignee: ZhaoYang
> StreamManager should clearly differentiate between "initiator" and "receiver"
> sessions
> --
>
> Key: CASSANDRA-15665
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15665
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamManager}} does currently a suboptimal job in differentiating between
> stream sessions (in form of {{StreamResultFuture}}) which have been either
> initiated or "received", for the following reasons:
> 1) Naming is IMO confusing: a "receiver" session could actually both send and
> receive files, so technically an initiator is also a receiver.
> 2) {{StreamManager#findSession()}} assumes we should first looking into
> "initiator" sessions, then into "receiver" ones: this is a dangerous
> assumptions, in particular for test environments where the same process could
> work as both an initiator and a receiver.
> I would recommend the following changes:
> 1) Rename "receiver" with "follower" everywhere the former is used.
> 2) Introduce a new flag into {{StreamMessageHeader}} to signal if the message
> comes from an initiator or follower session, in order to correctly
> differentiate and look for sessions in {{StreamManager}}.
> While my arguments above might seem trivial, I believe they will improve
> clarity and save from potential bugs/headaches at testing time, and doing
> such changes now that we're revamping streaming for 4.0 seems the right time.
--
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-14773) Overflow of 32-bit integer during compaction.
[
https://issues.apache.org/jira/browse/CASSANDRA-14773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067731#comment-17067731
]
Francisco Fernandez commented on CASSANDRA-14773:
-
I've pushed a patch following the same ideas proposed originally and I've
simplified the code as well. I think we're covering all overflows now.
[https://github.com/apache/cassandra/pull/491]
[~blerer] [~snazy] can you take a look?
> Overflow of 32-bit integer during compaction.
> -
>
> Key: CASSANDRA-14773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14773
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Vladimir Bukhtoyarov
>Assignee: Francisco Fernandez
>Priority: Urgent
> Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In scope of CASSANDRA-13444 the compaction was significantly improved from
> CPU and memory perspective. Hovewer this improvement introduces the bug in
> rounding. When rounding the expriration time which is close to
> *Cell.MAX_DELETION_TIME*(it is just *Integer.MAX_VALUE*) the math overflow
> happens(because in scope of -CASSANDRA-13444-) data type for point was
> changed from Long to Integer in order to reduce memory footprint), as result
> point became negative and acts as silent poison for internal structures of
> StreamingTombstoneHistogramBuilder like *DistanceHolder* and *DataHolder*.
> Then depending of point intervals:
> * The TombstoneHistogram produces wrong values when interval of points is
> less then binSize, it is not critical.
> * Compaction crashes with ArrayIndexOutOfBoundsException if amount of point
> intervals is great then binSize, this case is very critical.
>
> This is pull request [https://github.com/apache/cassandra/pull/273] that
> reproduces the issue and provides the fix.
>
> The stacktrace when running(on codebase without fix)
> *testMathOverflowDuringRoundingOfLargeTimestamp* without -ea JVM flag
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$DistanceHolder.add(StreamingTombstoneHistogramBuilder.java:208)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushValue(StreamingTombstoneHistogramBuilder.java:140)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$$Lambda$1/1967205423.consume(Unknown
> Source)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$Spool.forEach(StreamingTombstoneHistogramBuilder.java:574)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushHistogram(StreamingTombstoneHistogramBuilder.java:124)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.build(StreamingTombstoneHistogramBuilder.java:184)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilderTest.testMathOverflowDuringRoundingOfLargeTimestamp(StreamingTombstoneHistogramBuilderTest.java:183)
> 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:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
>
[jira] [Updated] (CASSANDRA-14773) Overflow of 32-bit integer during compaction.
[
https://issues.apache.org/jira/browse/CASSANDRA-14773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CASSANDRA-14773:
---
Labels: pull-request-available (was: )
> Overflow of 32-bit integer during compaction.
> -
>
> Key: CASSANDRA-14773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14773
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Vladimir Bukhtoyarov
>Assignee: Francisco Fernandez
>Priority: Urgent
> Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
>
> In scope of CASSANDRA-13444 the compaction was significantly improved from
> CPU and memory perspective. Hovewer this improvement introduces the bug in
> rounding. When rounding the expriration time which is close to
> *Cell.MAX_DELETION_TIME*(it is just *Integer.MAX_VALUE*) the math overflow
> happens(because in scope of -CASSANDRA-13444-) data type for point was
> changed from Long to Integer in order to reduce memory footprint), as result
> point became negative and acts as silent poison for internal structures of
> StreamingTombstoneHistogramBuilder like *DistanceHolder* and *DataHolder*.
> Then depending of point intervals:
> * The TombstoneHistogram produces wrong values when interval of points is
> less then binSize, it is not critical.
> * Compaction crashes with ArrayIndexOutOfBoundsException if amount of point
> intervals is great then binSize, this case is very critical.
>
> This is pull request [https://github.com/apache/cassandra/pull/273] that
> reproduces the issue and provides the fix.
>
> The stacktrace when running(on codebase without fix)
> *testMathOverflowDuringRoundingOfLargeTimestamp* without -ea JVM flag
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$DistanceHolder.add(StreamingTombstoneHistogramBuilder.java:208)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushValue(StreamingTombstoneHistogramBuilder.java:140)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$$Lambda$1/1967205423.consume(Unknown
> Source)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$Spool.forEach(StreamingTombstoneHistogramBuilder.java:574)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushHistogram(StreamingTombstoneHistogramBuilder.java:124)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.build(StreamingTombstoneHistogramBuilder.java:184)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilderTest.testMathOverflowDuringRoundingOfLargeTimestamp(StreamingTombstoneHistogramBuilderTest.java:183)
> 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:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
>
> The stacktrace when running(on
[jira] [Updated] (CASSANDRA-15664) Handle wrapping ranges in token range compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-15664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15664: --- Reviewers: Benjamin Lerer > Handle wrapping ranges in token range compaction > > > Key: CASSANDRA-15664 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15664 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-alpha > > > We currently don't handle wrapping ranges in token range compaction -- 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-15543) flaky test org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15543:
---
Since Version: 4.0-alpha
Source Control Link:
https://github.com/apache/cassandra/commit/b6176906e71620b37920eaf84fa51516b046bdce
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Patch committed into trunk at b6176906e71620b37920eaf84fa51516b046bdce
> flaky test
> org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
> ---
>
> Key: CASSANDRA-15543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: Kevin Gallardo
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> This fails infrequently, last seen failure was on java 8
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15543) flaky test org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15543:
---
Status: Ready to Commit (was: Review In Progress)
> flaky test
> org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
> ---
>
> Key: CASSANDRA-15543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: Kevin Gallardo
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> This fails infrequently, last seen failure was on java 8
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
> {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
[cassandra] branch trunk updated: Use immutable map for Read/WriteFailure exception and fix flaky test
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 b617690 Use immutable map for Read/WriteFailure exception and fix
flaky test
b617690 is described below
commit b6176906e71620b37920eaf84fa51516b046bdce
Author: Kevin Gallardo
AuthorDate: Thu Mar 12 15:35:05 2020 -0400
Use immutable map for Read/WriteFailure exception and fix flaky test
patch by Kevin Gallardo; reviewed by Benjamin Lerer for CASSANDRA-15543
---
.../cassandra/exceptions/ReadFailureException.java | 4 ++-
.../exceptions/RequestFailureException.java| 21 ++--
.../exceptions/WriteFailureException.java | 4 ++-
.../cassandra/transport/messages/ErrorMessage.java | 13 ++--
.../distributed/test/SimpleReadWriteTest.java | 37 ++
5 files changed, 48 insertions(+), 31 deletions(-)
diff --git a/src/java/org/apache/cassandra/exceptions/ReadFailureException.java
b/src/java/org/apache/cassandra/exceptions/ReadFailureException.java
index 72242fd..744cad4 100644
--- a/src/java/org/apache/cassandra/exceptions/ReadFailureException.java
+++ b/src/java/org/apache/cassandra/exceptions/ReadFailureException.java
@@ -19,6 +19,8 @@ package org.apache.cassandra.exceptions;
import java.util.Map;
+import com.google.common.collect.ImmutableMap;
+
import org.apache.cassandra.db.ConsistencyLevel;
import org.apache.cassandra.locator.InetAddressAndPort;
@@ -28,7 +30,7 @@ public class ReadFailureException extends
RequestFailureException
public ReadFailureException(ConsistencyLevel consistency, int received,
int blockFor, boolean dataPresent, Map failureReasonByEndpoint)
{
-super(ExceptionCode.READ_FAILURE, consistency, received, blockFor,
failureReasonByEndpoint);
+super(ExceptionCode.READ_FAILURE, consistency, received, blockFor,
ImmutableMap.copyOf(failureReasonByEndpoint));
this.dataPresent = dataPresent;
}
}
diff --git
a/src/java/org/apache/cassandra/exceptions/RequestFailureException.java
b/src/java/org/apache/cassandra/exceptions/RequestFailureException.java
index e982b44..56cee1a 100644
--- a/src/java/org/apache/cassandra/exceptions/RequestFailureException.java
+++ b/src/java/org/apache/cassandra/exceptions/RequestFailureException.java
@@ -17,7 +17,6 @@
*/
package org.apache.cassandra.exceptions;
-import java.util.HashMap;
import java.util.Map;
import java.util.stream.Collectors;
@@ -33,21 +32,19 @@ public class RequestFailureException extends
RequestExecutionException
protected RequestFailureException(ExceptionCode code, ConsistencyLevel
consistency, int received, int blockFor, Map failureReasonByEndpoint)
{
-super(code, String.format("Operation failed - received %d responses
and %d failures: %s",
- received,
- failureReasonByEndpoint.size(),
-
buildFailureString(failureReasonByEndpoint)));
+super(code, buildErrorMessage(received, failureReasonByEndpoint));
this.consistency = consistency;
this.received = received;
this.blockFor = blockFor;
+this.failureReasonByEndpoint = failureReasonByEndpoint;
+}
-// It is possible for the passed in failureReasonByEndpoint map
-// to have new entries added after this exception is constructed
-// (e.g. a delayed failure response from a replica). So to be safe
-// we make a copy of the map at this point to ensure it will not be
-// modified any further. Otherwise, there could be implications when
-// we encode this map for transport.
-this.failureReasonByEndpoint = new HashMap<>(failureReasonByEndpoint);
+private static String buildErrorMessage(int received,
Map failures)
+{
+return String.format("Operation failed - received %d responses and %d
failures: %s",
+ received,
+ failures.size(),
+ buildFailureString(failures));
}
private static String buildFailureString(Map failures)
diff --git
a/src/java/org/apache/cassandra/exceptions/WriteFailureException.java
b/src/java/org/apache/cassandra/exceptions/WriteFailureException.java
index a7dc66a..bcda9e6 100644
--- a/src/java/org/apache/cassandra/exceptions/WriteFailureException.java
+++ b/src/java/org/apache/cassandra/exceptions/WriteFailureException.java
@@ -19,6 +19,8 @@ package org.apache.cassandra.exceptions;
import java.util.Map;
+import com.google.common.collect.ImmutableMap;
+
import org.apache.cassandra.db.ConsistencyLevel;
import org.apache.cassandra.db.WriteType;
import org.apache.cassandra.locator.InetAddressAndPort;
@@ -29,7 +31,7 @@ public class WriteFailureException extends
[cassandra-builds] branch master updated (08e94f6 -> 44dee14)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git. from 08e94f6 Revert "Jenkins tests to use testclasslist where possible (like CircleCI) (CASSANDRA-15651)" This reverts commit 399a8a0c87489aea236b240ca0edaf781c1c4966. add 44dee14 Jenkins devbranch pipeline to only run on 'cassandra' labelled agents No new revisions were added by this update. Summary of changes: jenkins-dsl/cassandra_pipeline.groovy | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15651) Jenkins tests to use testclasslist where possible (like CircleCI)
[
https://issues.apache.org/jira/browse/CASSANDRA-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067625#comment-17067625
]
Michael Semb Wever edited comment on CASSANDRA-15651 at 3/26/20, 1:49 PM:
--
This broke all the jenkins jobs, as the test results are no longer available
under build/test/output/TEST-*.xml
{noformat}
Archiving artifacts
java.lang.InterruptedException: no matches found within 1
at hudson.FilePath$ValidateAntFileMask.hasMatch(FilePath.java:2803)
at hudson.FilePath$ValidateAntFileMask.invoke(FilePath.java:2712)
at hudson.FilePath$ValidateAntFileMask.invoke(FilePath.java:2663)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3050)
Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to cassandra8
{noformat}
was (Author: michaelsembwever):
This broke all the jenkins jobs, as the test results are no longer available
under build/test/output/TEST-*.xml
> Jenkins tests to use testclasslist where possible (like CircleCI)
> -
>
> Key: CASSANDRA-15651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15651
> Project: Cassandra
> Issue Type: Task
> Components: Build, Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha
>
>
> Following up on CASSANDRA-15639
> make all the jenkins test jobs run in the same manner.
> This standards the approach across test jobs and to CircleCI, and will make
> it easier to parallelise test runs later on.
--
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-15630) Fix flakey testSerializeError - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067685#comment-17067685
]
Benjamin Lerer commented on CASSANDRA-15630:
[~yifanc] Nice work :-). Thanks a lot. I just added a minor comment that I can
do on commit if you want to.
Do you have a link toward the CI run?
{quote}Since multiple JIRAs were created already, I only applied the fix for
this one. {quote}
In such a case, you can simply clause them and mark them as duplicates. :-)
> Fix flakey testSerializeError - org.apache.cassandra.net.ConnectionTest
> ---
>
> Key: CASSANDRA-15630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15630
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-beta
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The test fails sometimes with the following error message and trace.
> {code:java}
> processed count values don't match expected:<90> but was:<89>
> junit.framework.AssertionFailedError: processed count values don't match
> expected:<90> but was:<89>
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:217)
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testSerializeError$24(ConnectionTest.java:494)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:240)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:260)
> at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:238)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:227)
> at
> org.apache.cassandra.net.ConnectionTest.testSerializeError(ConnectionTest.java:435){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-15656) Expose repair streaming metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067667#comment-17067667 ] Ekaterina Dimitrova commented on CASSANDRA-15656: - Hi [~marcuse], Thanks for checking. Unfortunately, it still says 0 jobs in the workflow. I see the same for the rest of the tickets too so I suspect it is some kind of a permission issue maybe? > Expose repair streaming metric > -- > > Key: CASSANDRA-15656 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15656 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair, Consistency/Streaming >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-alpha > > > We should expose a metric for how much data is streamed during repair -- 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-15651) Jenkins tests to use testclasslist where possible (like CircleCI)
[ https://issues.apache.org/jira/browse/CASSANDRA-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067636#comment-17067636 ] Michael Semb Wever commented on CASSANDRA-15651: Reverted the cassandra-builds, so get ci-cassandra.a.o working again. > Jenkins tests to use testclasslist where possible (like CircleCI) > - > > Key: CASSANDRA-15651 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15651 > Project: Cassandra > Issue Type: Task > Components: Build, Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > > Following up on CASSANDRA-15639 > make all the jenkins test jobs run in the same manner. > This standards the approach across test jobs and to CircleCI, and will make > it easier to parallelise test runs later on. -- 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-15665) StreamManager should clearly differentiate between "initiator" and "receiver" sessions
[
https://issues.apache.org/jira/browse/CASSANDRA-15665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergio Bossa updated CASSANDRA-15665:
-
Fix Version/s: 4.0
> StreamManager should clearly differentiate between "initiator" and "receiver"
> sessions
> --
>
> Key: CASSANDRA-15665
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15665
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamManager}} does currently a suboptimal job in differentiating between
> stream sessions (in form of {{StreamResultFuture}}) which have been either
> initiated or "received", for the following reasons:
> 1) Naming is IMO confusing: a "receiver" session could actually both send and
> receive files, so technically an initiator is also a receiver.
> 2) {{StreamManager#findSession()}} assumes we should first looking into
> "initiator" sessions, then into "receiver" ones: this is a dangerous
> assumptions, in particular for test environments where the same process could
> work as both an initiator and a receiver.
> I would recommend the following changes:
> 1) Rename "receiver" with "follower" everywhere the former is used.
> 2) Introduce a new flag into {{StreamMessageHeader}} to signal if the message
> comes from an initiator or follower session, in order to correctly
> differentiate and look for sessions in {{StreamManager}}.
> While my arguments above might seem trivial, I believe they will improve
> clarity and save from potential bugs/headaches at testing time, and doing
> such changes now that we're revamping streaming for 4.0 seems the right time.
--
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 master updated: Revert "Jenkins tests to use testclasslist where possible (like CircleCI) (CASSANDRA-15651)" This reverts commit 399a8a0c87489aea236b240ca0edaf781c1c4966.
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/master by this push:
new 08e94f6 Revert "Jenkins tests to use testclasslist where possible
(like CircleCI) (CASSANDRA-15651)" This reverts commit
399a8a0c87489aea236b240ca0edaf781c1c4966.
08e94f6 is described below
commit 08e94f6d7dad4b1e24033cb70b31880eda528b63
Author: mck
AuthorDate: Thu Mar 26 13:22:41 2020 +0100
Revert "Jenkins tests to use testclasslist where possible (like CircleCI)
(CASSANDRA-15651)"
This reverts commit 399a8a0c87489aea236b240ca0edaf781c1c4966.
---
build-scripts/cassandra-jvm-dtest.sh | 32 +
build-scripts/cassandra-test.sh | 60 ---
build-scripts/cassandra-unittest.sh | 36 +++
jenkins-dsl/cassandra_job_dsl_seed.groovy | 19 +++---
4 files changed, 83 insertions(+), 64 deletions(-)
diff --git a/build-scripts/cassandra-jvm-dtest.sh
b/build-scripts/cassandra-jvm-dtest.sh
new file mode 100755
index 000..0b41323
--- /dev/null
+++ b/build-scripts/cassandra-jvm-dtest.sh
@@ -0,0 +1,32 @@
+#!/usr/bin/env bash
+
+set -o xtrace
+set -o errexit
+set -o pipefail
+set -o nounset
+
+# lists all tests for the specific test type
+_list_tests() {
+ local readonly classlistprefix="$1"
+
+ find "test/$classlistprefix" -name '*Test.java' | sed
"s;^test/$classlistprefix/;;g"
+}
+
+_list_tests_no_upgrade() {
+ _list_tests "distributed" | grep -v "upgrade"
+}
+
+_main() {
+ local java_version
+ java_version=$(java -version 2>&1 | awk -F '"' '/version/ {print $2}' | awk
-F. '{print $1}')
+ if [ "$java_version" -ge 11 ]; then
+export CASSANDRA_USE_JDK11=true
+ fi
+
+ local test_timeout
+ test_timeout=$(grep 'name="test.distributed.timeout"' build.xml | awk -F'"'
'{print $4}')
+
+ ant testclasslist -Dtest.timeout="$test_timeout" -Dtest.classlistfile=<(
_list_tests_no_upgrade ) -Dtest.classlistprefix=distributed || echo "ant
testclasslist failed"
+}
+
+_main "$@"
diff --git a/build-scripts/cassandra-test.sh b/build-scripts/cassandra-test.sh
deleted file mode 100755
index bdb255f..000
--- a/build-scripts/cassandra-test.sh
+++ /dev/null
@@ -1,60 +0,0 @@
-#!/usr/bin/env bash
-
-set -o xtrace
-set -o errexit
-set -o pipefail
-set -o nounset
-
-# lists all tests for the specific test type
-_list_tests() {
- local readonly classlistprefix="$1"
- find "test/$classlistprefix" -name '*Test.java' | sed
"s;^test/$classlistprefix/;;g"
-}
-
-_list_distributed_tests_no_upgrade() {
- _list_tests "distributed" | grep -v "upgrade"
-}
-
-_timeout_for() {
- grep "name=\"$1\"" build.xml | awk -F'"' '{print $4}'
-}
-
-_main() {
- local target="${1:-}"
- local java_version=$(java -version 2>&1 | awk -F '"' '/version/ {print $2}'
| awk -F. '{print $1}')
- if [ "$java_version" -ge 11 ]; then
-export CASSANDRA_USE_JDK11=true
- fi
-
- ant clean jar
-
- case $target in
-"stress-test" | "fqltool-test")
- ant $target || echo "failed $target"
- ;;
-"test")
- ant testclasslist -Dtest.classlistfile=<( _list_tests "unit" ) || echo
"failed $target"
- ;;
-"test-cdc")
- ant testclasslist-cdc -Dtest.classlistfile=<( _list_tests "unit" ) ||
echo "failed $target"
- ;;
-"test-compression")
- ant testclasslist-compression -Dtest.classlistfile=<( _list_tests "unit"
) || echo "failed $target"
- ;;
-"test-burn")
- ant testclasslist -Dtest.timeout=$(_timeout_for "test.burn.timeout")
-Dtest.classlistfile=<( _list_tests "burn" ) || echo "failed $target"
- ;;
-"long-test")
- ant testclasslist -Dtest.timeout=$(_timeout_for "test.long.timeout")
-Dtest.classlistfile=<( _list_tests "long" ) || echo "failed $target"
- ;;
-"test-jvm-dtest-forking")
- ant testclasslist -Dtest.timeout=$(_timeout_for
"test.distributed.timeout") -Dtest.classlistfile=<(
_list_distributed_tests_no_upgrade ) -Dtest.classlistprefix=distributed || echo
"failed $target"
- ;;
-*)
- echo "unregconised \"$target\""
- exit 1
- ;;
- esac
-}
-
-_main "$@"
diff --git a/build-scripts/cassandra-unittest.sh
b/build-scripts/cassandra-unittest.sh
new file mode 100755
index 000..0c91c26
--- /dev/null
+++ b/build-scripts/cassandra-unittest.sh
@@ -0,0 +1,36 @@
+#!/bin/bash -x
+
+
+#
+# Prep
+#
+
+
+# Pass in target to run, default to `ant test`
+TEST_TARGET="${1:-test}"
+
+
+#
+# Main
+#
+
+
+# Loop to prevent failure due to maven-ant-tasks not downloading a jar..
+for x in $(seq 1 3); do
+ant clean jar
+RETURN="$?"
+if [ "${RETURN}" -eq "0" ]; then
+# Run target and exit cleanly for usable "Unstable" status
+ant "${TEST_TARGET}"
+exit 0
+
[jira] [Created] (CASSANDRA-15665) StreamManager should clearly differentiate between "initiator" and "receiver" sessions
Sergio Bossa created CASSANDRA-15665:
Summary: StreamManager should clearly differentiate between
"initiator" and "receiver" sessions
Key: CASSANDRA-15665
URL: https://issues.apache.org/jira/browse/CASSANDRA-15665
Project: Cassandra
Issue Type: Bug
Components: Legacy/Streaming and Messaging
Reporter: Sergio Bossa
{{StreamManager}} does currently a suboptimal job in differentiating between
stream sessions (in form of {{StreamResultFuture}}) which have been either
initiated or "received", for the following reasons:
1) Naming is IMO confusing: a "receiver" session could actually both send and
receive files, so technically an initiator is also a receiver.
2) {{StreamManager#findSession()}} assumes we should first looking into
"initiator" sessions, then into "receiver" ones: this is a dangerous
assumptions, in particular for test environments where the same process could
work as both an initiator and a receiver.
I would recommend the following changes:
1) Rename "receiver" with "follower" everywhere the former is used.
2) Introduce a new flag into {{StreamMessageHeader}} to signal if the message
comes from an initiator or follower session, in order to correctly
differentiate and look for sessions in {{StreamManager}}.
While my arguments above might seem trivial, I believe they will improve
clarity and save from potential bugs/headaches at testing time, and doing such
changes now that we're revamping streaming for 4.0 seems the right time.
--
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-15639) Jenkins build for jvm test should use testclasslist to support parameterized tests
[
https://issues.apache.org/jira/browse/CASSANDRA-15639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15639:
---
Status: Resolved (was: Open)
> Jenkins build for jvm test should use testclasslist to support parameterized
> tests
> --
>
> Key: CASSANDRA-15639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15639
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> We switched Circle CI to use testclasslist in CASSANDRA-15508 this was to
> solve the following exception
> {code}
> ava.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@551aa95a
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {code}
> The core issue is that the test locating logic in
> org.apache.cassandra.distributed.test.TestLocator does not handle
> parameterized tests so fails to find any tests for those classes.
> I think it is better to switch to testclasslist as it helps make way for
> running tests concurrently.
--
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] [Issue Comment Deleted] (CASSANDRA-15639) Jenkins build for jvm test should use testclasslist to support parameterized tests
[
https://issues.apache.org/jira/browse/CASSANDRA-15639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15639:
---
Comment: was deleted
(was: This broke all the jenkins jobs, as the test results are no longer
available under {{build/test/output/TEST-*.xml}})
> Jenkins build for jvm test should use testclasslist to support parameterized
> tests
> --
>
> Key: CASSANDRA-15639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15639
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> We switched Circle CI to use testclasslist in CASSANDRA-15508 this was to
> solve the following exception
> {code}
> ava.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@551aa95a
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {code}
> The core issue is that the test locating logic in
> org.apache.cassandra.distributed.test.TestLocator does not handle
> parameterized tests so fails to find any tests for those classes.
> I think it is better to switch to testclasslist as it helps make way for
> running tests concurrently.
--
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-15651) Jenkins tests to use testclasslist where possible (like CircleCI)
[ https://issues.apache.org/jira/browse/CASSANDRA-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15651: --- Status: Open (was: Resolved) This broke all the jenkins jobs, as the test results are no longer available under build/test/output/TEST-*.xml > Jenkins tests to use testclasslist where possible (like CircleCI) > - > > Key: CASSANDRA-15651 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15651 > Project: Cassandra > Issue Type: Task > Components: Build, Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha > > > Following up on CASSANDRA-15639 > make all the jenkins test jobs run in the same manner. > This standards the approach across test jobs and to CircleCI, and will make > it easier to parallelise test runs later on. -- 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-15639) Jenkins build for jvm test should use testclasslist to support parameterized tests
[
https://issues.apache.org/jira/browse/CASSANDRA-15639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15639:
---
Status: Open (was: Resolved)
This broke all the jenkins jobs, as the test results are no longer available
under {{build/test/output/TEST-*.xml}}
> Jenkins build for jvm test should use testclasslist to support parameterized
> tests
> --
>
> Key: CASSANDRA-15639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15639
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> We switched Circle CI to use testclasslist in CASSANDRA-15508 this was to
> solve the following exception
> {code}
> ava.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@551aa95a
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {code}
> The core issue is that the test locating logic in
> org.apache.cassandra.distributed.test.TestLocator does not handle
> parameterized tests so fails to find any tests for those classes.
> I think it is better to switch to testclasslist as it helps make way for
> running tests concurrently.
--
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-14754) Add verification of state machine in StreamSession
[
https://issues.apache.org/jira/browse/CASSANDRA-14754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-14754:
-
Test and Documentation Plan:
CI: [https://circleci.com/workflow-run/359562c5-5faf-49c8-aa95-2286b2d37a52],
failure not related:
{code}
j8_jvm_upgrade_dtests: java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.NoSuchMethodError:
org.apache.cassandra.distributed.api.IMessageFilters.permit(IILorg/apache/cassandra/distributed/api/IMessage;)Z
{code}
dtest looks good, failures are not related:
{code}
consistency_test.TestAccuracy.test_simple_strategy_each_quorum_counters
cql_tracing_test.TestCqlTracing.test_tracing_unknown_impl
read_repair_test.TestSpeculativeReadRepair.test_speculative_data_request
cql_tracing_test.TestCqlTracing.test_tracing_does_not_interfere_with_digest_calculation
cql_tracing_test.TestCqlTracing.test_tracing_simple
cql_tracing_test.TestCqlTracing.test_tracing_default_impl
cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_writing_with_token_boundaries
cql_tracing_test.TestCqlTracing.test_tracing_default_impl
cql_tracing_test.TestCqlTracing.test_tracing_simple
{code}
was:CI:
[https://circleci.com/workflow-run/359562c5-5faf-49c8-aa95-2286b2d37a52]
> Add verification of state machine in StreamSession
> --
>
> Key: CASSANDRA-14754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14754
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Streaming and Messaging
>Reporter: Jason Brown
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamSession}} contains an implicit state machine, but we have no
> verification of the safety of the transitions between states. For example, we
> have no checks to ensure we cannot leave the final states (COMPLETED, FAILED).
> I propose we add some program logic in {{StreamSession}}, tests, and
> documentation to ensure the correctness of the state transitions.
--
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-14754) Add verification of state machine in StreamSession
[
https://issues.apache.org/jira/browse/CASSANDRA-14754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14754:
---
Reviewers: Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Status: Review In Progress (was: Patch Available)
> Add verification of state machine in StreamSession
> --
>
> Key: CASSANDRA-14754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14754
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Streaming and Messaging
>Reporter: Jason Brown
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamSession}} contains an implicit state machine, but we have no
> verification of the safety of the transitions between states. For example, we
> have no checks to ensure we cannot leave the final states (COMPLETED, FAILED).
> I propose we add some program logic in {{StreamSession}}, tests, and
> documentation to ensure the correctness of the state transitions.
--
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-15628) Fix flakey testSendLarge - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15628:
---
Resolution: Duplicate (was: Fixed)
Status: Resolved (was: Open)
The flakiness is caused by some race conditions problem in the test framework
that CASSANDRA-15630 is addressing.
> Fix flakey testSendLarge - org.apache.cassandra.net.ConnectionTest
> --
>
> Key: CASSANDRA-15628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15628
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Yifan Cai
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The test fails sometimes with the following error message and trace.
> {code:java}
> received count values don't match expected:<10> but was:<9>
> junit.framework.AssertionFailedError: received count values don't match
> expected:<10> but was:<9>
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:212)
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testSendLarge$15(ConnectionTest.java:359)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:242)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:262)
> at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:240)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:229)
> at
> org.apache.cassandra.net.ConnectionTest.testSendLarge(ConnectionTest.java:312)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15628) Fix flakey testSendLarge - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15628:
---
Status: Open (was: Resolved)
> Fix flakey testSendLarge - org.apache.cassandra.net.ConnectionTest
> --
>
> Key: CASSANDRA-15628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15628
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Yifan Cai
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The test fails sometimes with the following error message and trace.
> {code:java}
> received count values don't match expected:<10> but was:<9>
> junit.framework.AssertionFailedError: received count values don't match
> expected:<10> but was:<9>
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:212)
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testSendLarge$15(ConnectionTest.java:359)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:242)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:262)
> at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:240)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:229)
> at
> org.apache.cassandra.net.ConnectionTest.testSendLarge(ConnectionTest.java:312)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15629) Fix flakey testSendSmall - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15629:
---
Resolution: Duplicate
Status: Resolved (was: Open)
The flakiness is caused by some race conditions problem in the test framework
that CASSANDRA-15630 is addressing.
> Fix flakey testSendSmall - org.apache.cassandra.net.ConnectionTest
> --
>
> Key: CASSANDRA-15629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15629
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Yifan Cai
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The test fails sometimes with the following error message and trace.
> {code:java}
> processed count values don't match expected:<10> but was:<9>
> junit.framework.AssertionFailedError: processed count values don't match
> expected:<10> but was:<9>
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:217)
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testSendSmall$11(ConnectionTest.java:305)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:242)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:262)
> at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:240)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:229)
> at
> org.apache.cassandra.net.ConnectionTest.testSendSmall(ConnectionTest.java:277)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15628) Fix flakey testSendLarge - org.apache.cassandra.net.ConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15628:
---
Resolution: Fixed
Status: Resolved (was: Open)
The flakiness is caused by some race conditions problem in the test framework
that CASSANDRA-15630 is addressing.
> Fix flakey testSendLarge - org.apache.cassandra.net.ConnectionTest
> --
>
> Key: CASSANDRA-15628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15628
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Yifan Cai
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The test fails sometimes with the following error message and trace.
> {code:java}
> received count values don't match expected:<10> but was:<9>
> junit.framework.AssertionFailedError: received count values don't match
> expected:<10> but was:<9>
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:212)
> at
> org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testSendLarge$15(ConnectionTest.java:359)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:242)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:262)
> at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:240)
> at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:229)
> at
> org.apache.cassandra.net.ConnectionTest.testSendLarge(ConnectionTest.java:312)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15663:
Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear
Impact(13164)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 4.0-alpha
3.11.x
3.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15663:
Description:
How to reproduce (3.11.6) - cqlsh:
{code}
CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
'replication_factor': '1'} AND durable_writes = true;
CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
DESCRIBE KEYSPACE test1;
{code}
Output will be:
{code}
CREATE TABLE test1.default (
id text PRIMARY KEY,
data text,
etag text
) WITH [..]
{code}
Output should be:
{code}
CREATE TABLE test1."default" (
id text PRIMARY KEY,
data text,
etag text
) WITH [..]
{code}
If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
TABLE test1.[default]...)
Oskar Liljeblad
was:
How to reproduce (3.11.6) - cqlsh:
CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
'replication_factor': '1'} AND durable_writes = true;
CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
DESCRIBE KEYSPACE test1;
Output will be:
CREATE TABLE test1.default (
id text PRIMARY KEY,
data text,
etag text
) WITH [..]
Output should be:
CREATE TABLE test1."default" (
id text PRIMARY KEY,
data text,
etag text
) WITH [..]
If you try to run CREATE TABLE test1.default [..] you will get an error
SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
TABLE test1.[default]...)
Oskar Liljeblad
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Priority: Normal
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
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-15660) Unable to specify -e/--execute flag in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-15660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15660:
Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear
Impact(13164)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 4.0-alpha
Severity: Normal
Status: Open (was: Triage Needed)
> Unable to specify -e/--execute flag in cqlsh
>
>
> Key: CASSANDRA-15660
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15660
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> From mailing list:
> [https://lists.apache.org/thread.html/r377099b632c62b641e4feef5b738084fc5369b0c7157fae867853597%40%3Cdev.cassandra.apache.org%3E]
> The bug looks like this:
> {code:java}
> $ /usr/bin/cqlsh -e 'describe keyspaces' -u cassandra -p cassandra 127.0.0.1
> Usage: cqlsh.py [options] [host [port]]cqlsh.py: error: '127.0.0.1' is not a
> valid port number.
> {code}
> This is working in 3.x releases just fine but fails on 4.
> The workaround for 4.x code as of today is to put these statements into file
> and use "-f" flag.
>
--
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-15659) Better support of Python 3 for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-15659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15659: Change Category: Operability Complexity: Normal Fix Version/s: 4.0-alpha Status: Open (was: Triage Needed) > Better support of Python 3 for cqlsh > > > Key: CASSANDRA-15659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15659 > Project: Cassandra > Issue Type: Task > Components: Tool/cqlsh >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-alpha > > > From mailing list: > [https://lists.apache.org/thread.html/r377099b632c62b641e4feef5b738084fc5369b0c7157fae867853597%40%3Cdev.cassandra.apache.org%3E] > > As of today (24/3/2020) and current trunk, there is Python 3.6 supported (1) > but there is not any 3.6 version ootb in Debian for example. E.g. Buster has > Python 3.7 and other (recent) releases have version 2.7. This means that if > one wants to use Python 3 in Debian, he has to use 3.6 but it is not in the > repository so he has to download / compile / install it on his own. > There should be some sane Python 3 version supported which is as well present > in Debian repository (or requirement to run with 3.6 should be relaxed) . > (1) > [https://github.com/apache/cassandra/blob/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79/bin/cqlsh#L57-L65] -- 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-14754) Add verification of state machine in StreamSession
[
https://issues.apache.org/jira/browse/CASSANDRA-14754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-14754:
-
Test and Documentation Plan: CI:
[https://circleci.com/workflow-run/359562c5-5faf-49c8-aa95-2286b2d37a52] (was:
CI: [https://circleci.com/workflow-run/52fd4154-03d5-4c92-bc3f-1378bf490fc9])
> Add verification of state machine in StreamSession
> --
>
> Key: CASSANDRA-14754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14754
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Streaming and Messaging
>Reporter: Jason Brown
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamSession}} contains an implicit state machine, but we have no
> verification of the safety of the transitions between states. For example, we
> have no checks to ensure we cannot leave the final states (COMPLETED, FAILED).
> I propose we add some program logic in {{StreamSession}}, tests, and
> documentation to ensure the correctness of the state transitions.
--
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-14754) Add verification of state machine in StreamSession
[
https://issues.apache.org/jira/browse/CASSANDRA-14754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067501#comment-17067501
]
ZhaoYang commented on CASSANDRA-14754:
--
Thanks for the feedback.. Update the patch with the flow diagram.
> Add verification of state machine in StreamSession
> --
>
> Key: CASSANDRA-14754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14754
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Streaming and Messaging
>Reporter: Jason Brown
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamSession}} contains an implicit state machine, but we have no
> verification of the safety of the transitions between states. For example, we
> have no checks to ensure we cannot leave the final states (COMPLETED, FAILED).
> I propose we add some program logic in {{StreamSession}}, tests, and
> documentation to ensure the correctness of the state transitions.
--
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-15664) Handle wrapping ranges in token range compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-15664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15664: Test and Documentation Plan: cci run + updated unit test Status: Patch Available (was: Open) https://github.com/krummas/cassandra/commits/marcuse/15664 https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F15664 > Handle wrapping ranges in token range compaction > > > Key: CASSANDRA-15664 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15664 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-alpha > > > We currently don't handle wrapping ranges in token range compaction -- 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-15664) Handle wrapping ranges in token range compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-15664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15664: Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear Impact(13164) Complexity: Low Hanging Fruit Discovered By: Code Inspection Fix Version/s: 4.0-alpha Severity: Low Status: Open (was: Triage Needed) > Handle wrapping ranges in token range compaction > > > Key: CASSANDRA-15664 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15664 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-alpha > > > We currently don't handle wrapping ranges in token range compaction -- 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-15664) Handle wrapping ranges in token range compaction
Marcus Eriksson created CASSANDRA-15664: --- Summary: Handle wrapping ranges in token range compaction Key: CASSANDRA-15664 URL: https://issues.apache.org/jira/browse/CASSANDRA-15664 Project: Cassandra Issue Type: Bug Components: Local/Compaction Reporter: Marcus Eriksson Assignee: Marcus Eriksson We currently don't handle wrapping ranges in token range compaction -- 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-15656) Expose repair streaming metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067483#comment-17067483 ] Marcus Eriksson commented on CASSANDRA-15656: - It was failing due to eclipse-warnings error, I rebased and the tests are at least running now, let me know if you still can't view them. > Expose repair streaming metric > -- > > Key: CASSANDRA-15656 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15656 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair, Consistency/Streaming >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-alpha > > > We should expose a metric for how much data is streamed during repair -- 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-15663) DESCRIBE KEYSPACE does not properly quote table names
Oskar Liljeblad created CASSANDRA-15663:
---
Summary: DESCRIBE KEYSPACE does not properly quote table names
Key: CASSANDRA-15663
URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
Project: Cassandra
Issue Type: Bug
Components: CQL/Syntax
Reporter: Oskar Liljeblad
How to reproduce (3.11.6) - cqlsh:
CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
'replication_factor': '1'} AND durable_writes = true;
CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
DESCRIBE KEYSPACE test1;
Output will be:
CREATE TABLE test1.default (
id text PRIMARY KEY,
data text,
etag text
) WITH [..]
Output should be:
CREATE TABLE test1."default" (
id text PRIMARY KEY,
data text,
etag text
) WITH [..]
If you try to run CREATE TABLE test1.default [..] you will get an error
SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
TABLE test1.[default]...)
Oskar Liljeblad
--
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
