[jira] [Updated] (CASSANDRA-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16826:
--
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/230c66c9395fb339d08744d832279281928d3b9b
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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-dtest] branch trunk updated: Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 230c66c Fix flaky test
consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
230c66c is described below
commit 230c66c9395fb339d08744d832279281928d3b9b
Author: David Capwell
AuthorDate: Tue Aug 3 19:07:56 2021 -0700
Fix flaky test
consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
patch by David Capwell; reviewed by Abe Ratnofsky, Ekaterina Dimitrova for
CASSANDRA-16826
---
consistent_bootstrap_test.py | 4 ++--
tools/data.py| 5 +++--
tools/flaky.py | 6 --
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/consistent_bootstrap_test.py b/consistent_bootstrap_test.py
index 59a03d1..e995988 100644
--- a/consistent_bootstrap_test.py
+++ b/consistent_bootstrap_test.py
@@ -49,10 +49,10 @@ class TestBootstrapConsistency(Tester):
logger.debug("Checking that no data was lost")
for n in range(10, 20):
-query_c1c2(n2session, n, ConsistencyLevel.ALL)
+query_c1c2(n2session, n, ConsistencyLevel.ALL, max_attempts=3)
for n in range(30, 1000):
-query_c1c2(n2session, n, ConsistencyLevel.ALL)
+query_c1c2(n2session, n, ConsistencyLevel.ALL, max_attempts=3)
def test_consistent_reads_after_bootstrap(self):
logger.debug("Creating a ring")
diff --git a/tools/data.py b/tools/data.py
index d5607e0..7573af3 100644
--- a/tools/data.py
+++ b/tools/data.py
@@ -8,6 +8,7 @@ from cassandra.query import SimpleStatement
from . import assertions
from dtest import create_cf, DtestTimeoutError
from tools.funcutils import get_rate_limited_function
+from tools.flaky import retry
logger = logging.getLogger(__name__)
@@ -29,9 +30,9 @@ def insert_c1c2(session, keys=None, n=None,
consistency=ConsistencyLevel.QUORUM)
execute_concurrent_with_args(session, statement, [['k{}'.format(k)] for k
in keys])
-def query_c1c2(session, key, consistency=ConsistencyLevel.QUORUM,
tolerate_missing=False, must_be_missing=False):
+def query_c1c2(session, key, consistency=ConsistencyLevel.QUORUM,
tolerate_missing=False, must_be_missing=False, max_attempts=1):
query = SimpleStatement('SELECT c1, c2 FROM cf WHERE key=\'k%d\'' % key,
consistency_level=consistency)
-rows = list(session.execute(query))
+rows = list(retry(lambda: session.execute(query),
max_attempts=max_attempts))
if not tolerate_missing:
assertions.assert_length_equal(rows, 1)
res = rows[0]
diff --git a/tools/flaky.py b/tools/flaky.py
index 7baedad..48237f5 100644
--- a/tools/flaky.py
+++ b/tools/flaky.py
@@ -36,9 +36,11 @@ def requires_rerun(err, *args):
# err[0] contains the type of the error that occurred
return err[0] == RerunTestException
-def retry(fn, num_retries=10, allowed_error=None, sleep_seconds=1):
+def retry(fn, max_attempts=10, allowed_error=None, sleep_seconds=1):
+if max_attempts <= 0:
+raise ValueError("max_attempts must be a positive value, but given
{}".format(str(max_attempts)))
last_error = None
-for x in range(0, num_retries):
+for _ in range(0, max_attempts):
try:
return fn()
except Exception as e:
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16666) Make SSLContext creation pluggable/extensible
[ https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392633#comment-17392633 ] Maulin Vasavada edited comment on CASSANDRA-1 at 8/4/21, 1:43 AM: -- Yes Stefan, I'll check that documentation. [~stefan.miklosovic] [~bereng] Can you please check the PR now, I have resolved all the comments except for writing the example. I can start working on that if there are no other code changes suggested on the PR. was (Author: maulin.vasavada): [~stefan.miklosovic] [~bereng] Can you please check the PR now, I have resolved all the comments except for writing the example. I can start working on that if there are no other code changes suggested on the PR. > Make SSLContext creation pluggable/extensible > - > > Key: CASSANDRA-1 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Maulin Vasavada >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.x > > > Currently Cassandra creates the SSLContext via SSLFactory.java. SSLFactory is > a final class with static methods and not overridable. The SSLFactory loads > the keys and certs from the file based artifacts for the same. While this > works for many, in the industry where security is stricter and contextual, > this approach falls short. Many big organizations need flexibility to load > the SSL artifacts from a custom resource (like custom Key Management > Solution, HashiCorp Vault, Amazon KMS etc). While JSSE SecurityProvider > architecture allows us flexibility to build our custom mechanisms to validate > and process security artifacts, many times all we need is to build upon > Java's existing extensibility that Trust/Key Manager interfaces provide to > load keystores from various resources in the absence of any customized > requirements on the Keys/Certificate formats. > My proposal here is to make the SSLContext creation pluggable/extensible and > have the current SSLFactory.java implement an extensible interface. > I contributed a similar change that is live now in Apache Kafka (2.6.0) - > https://issues.apache.org/jira/browse/KAFKA-8890 > I can spare some time writing the pluggable interface and run by the required > reviewers. > > Created [CEP-9: Make SSLContext creation > pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable] > > > cc: [~dcapwell] [~djoshi] -- 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-16666) Make SSLContext creation pluggable/extensible
[ https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392633#comment-17392633 ] Maulin Vasavada commented on CASSANDRA-1: - [~stefan.miklosovic] [~bereng] Can you please check the PR now, I have resolved all the comments except for writing the example. I can start working on that if there are no other code changes suggested on the PR. > Make SSLContext creation pluggable/extensible > - > > Key: CASSANDRA-1 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Maulin Vasavada >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.x > > > Currently Cassandra creates the SSLContext via SSLFactory.java. SSLFactory is > a final class with static methods and not overridable. The SSLFactory loads > the keys and certs from the file based artifacts for the same. While this > works for many, in the industry where security is stricter and contextual, > this approach falls short. Many big organizations need flexibility to load > the SSL artifacts from a custom resource (like custom Key Management > Solution, HashiCorp Vault, Amazon KMS etc). While JSSE SecurityProvider > architecture allows us flexibility to build our custom mechanisms to validate > and process security artifacts, many times all we need is to build upon > Java's existing extensibility that Trust/Key Manager interfaces provide to > load keystores from various resources in the absence of any customized > requirements on the Keys/Certificate formats. > My proposal here is to make the SSLContext creation pluggable/extensible and > have the current SSLFactory.java implement an extensible interface. > I contributed a similar change that is live now in Apache Kafka (2.6.0) - > https://issues.apache.org/jira/browse/KAFKA-8890 > I can spare some time writing the pluggable interface and run by the required > reviewers. > > Created [CEP-9: Make SSLContext creation > pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable] > > > cc: [~dcapwell] [~djoshi] -- 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-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16826:
--
Reviewers: Abe Ratnofsky, Ekaterina Dimitrova (was: Ekaterina Dimitrova)
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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] [Comment Edited] (CASSANDRA-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392605#comment-17392605
]
Ekaterina Dimitrova edited comment on CASSANDRA-16826 at 8/4/21, 12:46 AM:
---
Looks good to me.
Please also Green CI and loop it before commit to ensure there are no
surprises, just in case. Thank you!
was (Author: e.dimitrova):
Looks good to me, only one super nit that you can address on commit.
Please also Green CI and loop it before commit to ensure there are no
surprises, just in case. Thank you!
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392609#comment-17392609
]
David Capwell commented on CASSANDRA-16826:
---
CI
https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=CASSANDRA-16826_ci
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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] [Comment Edited] (CASSANDRA-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392605#comment-17392605
]
Ekaterina Dimitrova edited comment on CASSANDRA-16826 at 8/4/21, 12:33 AM:
---
Looks good to me, only one super nit that you can address on commit.
Please also Green CI and loop it before commit to ensure there are no
surprises, just in case. Thank you!
was (Author: e.dimitrova):
Looks good to me, only one super nit that you can address on commit.
Please also loop it before commit to ensure there are no surprises, just in
case. Thank you!
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16826:
--
Status: Ready to Commit (was: Review In Progress)
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392605#comment-17392605
]
Ekaterina Dimitrova commented on CASSANDRA-16826:
-
Looks good to me, only one super nit that you can address on commit.
Please also loop it before commit to ensure there are no surprises, just in
case. Thank you!
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392603#comment-17392603
]
David Capwell commented on CASSANDRA-16826:
---
pushed feedback changes [~e.dimitrova]
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16826:
--
Status: Review In Progress (was: Changes Suggested)
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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] [Comment Edited] (CASSANDRA-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392567#comment-17392567
]
Ekaterina Dimitrova edited comment on CASSANDRA-16826 at 8/3/21, 10:19 PM:
---
I made a few suggestions in the PR around the _retry_ method as it is a bit
confusing now.
-Also, please, acknowledge the other usages of _query_c1c2_ method, out of
_consistent_bootstrap_test_.-
EDIT: [~dcapwell] pointed I was wrong, apparently he did already add the needed
change but I missed it. My bad, I am sorry for overseeing It. The other
suggestion stands :)
Thank you :)
was (Author: e.dimitrova):
I made a few suggestions in the PR around the _retry_ method as it is a bit
confusing now.
Also, please, acknowledge the other usages of _query_c1c2_ method, out of
_consistent_bootstrap_test_. Thank you :)
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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] [Comment Edited] (CASSANDRA-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392567#comment-17392567
]
Ekaterina Dimitrova edited comment on CASSANDRA-16826 at 8/3/21, 10:06 PM:
---
I made a few suggestions in the PR around the _retry_ method as it is a bit
confusing now.
Also, please, acknowledge the other usages of _query_c1c2_ method, out of
_consistent_bootstrap_test_. Thank you :)
was (Author: e.dimitrova):
I made a few suggestions in the PR around the retry method as it is a bit
confusing now.
Also, please, acknowledge the other usages of _query_c1c2_ method, out of
_consistent_bootstrap_test_. Thank you :)
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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] [Comment Edited] (CASSANDRA-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392567#comment-17392567
]
Ekaterina Dimitrova edited comment on CASSANDRA-16826 at 8/3/21, 10:06 PM:
---
I made a few suggestions in the PR around the retry method as it is a bit
confusing now.
Also, please, acknowledge the other usages of _query_c1c2_ method, out of
_consistent_bootstrap_test_. Thank you :)
was (Author: e.dimitrova):
I made a few suggestions in the PR around the retry method as it is a bit
confusing now.
Also, please, acknowledge the other usages of query_c1c2 method, out of
consistent_bootstrap_test. Thank you :)
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16826:
Status: Changes Suggested (was: Review In Progress)
I made a few suggestions in the PR around the retry method as it is a bit
confusing now.
Also, please, acknowledge the other usages of query_c1c2 method, out of
consistent_bootstrap_test. Thank you :)
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
> logger.debug("Writing data to node2")
> insert_c1c2(n2session, keys=list(range(30, 1000)),
> consistency=ConsistencyLevel.ONE)
> node2.flush()
>
> logger.debug("Restart node1")
> node1.start()
>
> logger.debug("Move token on node3")
> node3.move(2)
>
> logger.debug("Checking that no data was lost")
> for n in range(10, 20):
> query_c1c2(n2session, n, ConsistencyLevel.ALL)
>
> for n in range(30, 1000):
> >query_c1c2(n2session, n, ConsistencyLevel.ALL)
> consistent_bootstrap_test.py:55:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:34: in query_c1c2
> rows = list(session.execute(query))
> cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
> ???
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> >???
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
> cassandra/cluster.py:4894: OperationTimedOut
> {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-16528) Update Cassandra dependencies to fix security vulnerabilities
[
https://issues.apache.org/jira/browse/CASSANDRA-16528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16528:
-
Resolution: Not A Problem
Status: Resolved (was: Open)
Nope.
> Update Cassandra dependencies to fix security vulnerabilities
> -
>
> Key: CASSANDRA-16528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16528
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Dependencies
>Reporter: LHX
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> There are a couple of security vulnerabilities that show up in libraries that
> cassandra pulls in.
> # apache commons-collections v 3.2.1
> # apache commons-beanutils v 1.7.0
> For number one, there is a well-known security vulnerability in apache
> commons-collection 3.2.1 (see [https://www.kb.cert.org/vuls/id/576313] and
> https://issues.apache.org/jira/browse/COLLECTIONS-580). This is
> fixed/mitigated in commons-collections 3.2.2.
> All current versions of cassandra (including 4.0beta4) pull in
> commons-collections 3.2.1 via apache-rat 0.10. Is it possible to upgrade
> apache-rat to version 0.12 in order to pull in the latest version of
> commons-collections? See
> [https://github.com/apache/creadur-rat/commit/2380409fbcd02b418eceacfdc1e486bdbbca9632].
> I made the below change in 3.0.24 src and recompiled without errors.
> {code:java}
> // code placeholder
> diff --git a/cassandra/cassandra-3.0-src/build.xml
> b/cassandra/cassandra-3.0-src/build.xml
> index 73c9889d81..ed236443d4 100644
> --- a/cassandra/cassandra-3.0-src/build.xml
> +++ b/cassandra/cassandra-3.0-src/build.xml
> @@ -402,3 +402,3 @@
> version="0.9.12" />
> - version="0.10">
> + version="0.12">
>
> @@ -1605,3 +1605,3 @@
>
> - version="0.6" />
> + version="0.12" />
>
> {code}
>
> For number two, I was able to discern that beanutils is coming from
> hadoop-core which is version 1.0.3. I believe this also is quite out of date
> and could be upgraded.
> Could someone take a look and see if these version upgrades are possible?
> {{}}
--
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-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[
https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16826:
--
Description:
consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
can be flaky from time to time on less powerful environments due to timeouts;
this can be improved by having retries for queries
Here is the error I was seeing
{code}
self =
@pytest.mark.no_vnodes
def test_consistent_reads_after_move(self):
logger.debug("Creating a ring")
cluster = self.cluster
cluster.set_configuration_options(values={'hinted_handoff_enabled':
False,
'write_request_timeout_in_ms': 6,
'read_request_timeout_in_ms':
6,
'dynamic_snitch_badness_threshold': 0.0})
cluster.set_batch_commitlog(enabled=True)
cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
node1, node2, node3 = cluster.nodelist()
logger.debug("Set to talk to node 2")
n2session = self.patient_cql_connection(node2)
create_ks(n2session, 'ks', 2)
create_c1c2_table(self, n2session)
logger.debug("Generating some data for all nodes")
insert_c1c2(n2session, keys=list(range(10, 20)),
consistency=ConsistencyLevel.ALL)
node1.flush()
logger.debug("Taking down node1")
node1.stop(wait_other_notice=True)
logger.debug("Writing data to node2")
insert_c1c2(n2session, keys=list(range(30, 1000)),
consistency=ConsistencyLevel.ONE)
node2.flush()
logger.debug("Restart node1")
node1.start()
logger.debug("Move token on node3")
node3.move(2)
logger.debug("Checking that no data was lost")
for n in range(10, 20):
query_c1c2(n2session, n, ConsistencyLevel.ALL)
for n in range(30, 1000):
>query_c1c2(n2session, n, ConsistencyLevel.ALL)
consistent_bootstrap_test.py:55:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
tools/data.py:34: in query_c1c2
rows = list(session.execute(query))
cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
???
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>???
E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request
timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
cassandra/cluster.py:4894: OperationTimedOut
{code}
was:consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
can be flaky from time to time on less powerful environments due to timeouts;
this can be improved by having retries for queries
> Fix flaky test
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> ---
>
> Key: CASSANDRA-16826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16826
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
>
> consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
> can be flaky from time to time on less powerful environments due to
> timeouts; this can be improved by having retries for queries
> Here is the error I was seeing
> {code}
> self = 0x7fad988790f0>
> @pytest.mark.no_vnodes
> def test_consistent_reads_after_move(self):
> logger.debug("Creating a ring")
> cluster = self.cluster
> cluster.set_configuration_options(values={'hinted_handoff_enabled':
> False,
>
> 'write_request_timeout_in_ms': 6,
>
> 'read_request_timeout_in_ms': 6,
>
> 'dynamic_snitch_badness_threshold': 0.0})
> cluster.set_batch_commitlog(enabled=True)
>
> cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
> node1, node2, node3 = cluster.nodelist()
>
> logger.debug("Set to talk to node 2")
> n2session = self.patient_cql_connection(node2)
> create_ks(n2session, 'ks', 2)
> create_c1c2_table(self, n2session)
>
> logger.debug("Generating some data for all nodes")
> insert_c1c2(n2session, keys=list(range(10, 20)),
> consistency=ConsistencyLevel.ALL)
>
> node1.flush()
> logger.debug("Taking down node1")
> node1.stop(wait_other_notice=True)
>
>
[jira] [Updated] (CASSANDRA-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[ https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16826: Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina Dimitrova) Ekaterina Dimitrova, Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > Fix flaky test > consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move > --- > > Key: CASSANDRA-16826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16826 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move > can be flaky from time to time on less powerful environments due to > timeouts; this can be improved by having retries for queries -- 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-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[ https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16826: -- Test and Documentation Plan: local testing Status: Patch Available (was: Open) > Fix flaky test > consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move > --- > > Key: CASSANDRA-16826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16826 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move > can be flaky from time to time on less powerful environments due to > timeouts; this can be improved by having retries for queries -- 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-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
[ https://issues.apache.org/jira/browse/CASSANDRA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16826: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Low Hanging Fruit Discovered By: Unit Test Fix Version/s: NA Severity: Low Status: Open (was: Triage Needed) > Fix flaky test > consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move > --- > > Key: CASSANDRA-16826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16826 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move > can be flaky from time to time on less powerful environments due to > timeouts; this can be improved by having retries for queries -- 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-16826) Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
David Capwell created CASSANDRA-16826: - Summary: Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move Key: CASSANDRA-16826 URL: https://issues.apache.org/jira/browse/CASSANDRA-16826 Project: Cassandra Issue Type: Bug Components: Test/dtest/python Reporter: David Capwell Assignee: David Capwell consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move can be flaky from time to time on less powerful environments due to timeouts; this can be improved by having retries for queries -- 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-14694) add latency sample for speculative read repair writes
[ https://issues.apache.org/jira/browse/CASSANDRA-14694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392518#comment-17392518 ] Benedict Elliott Smith commented on CASSANDRA-14694: I don’t think so, no. > add latency sample for speculative read repair writes > - > > Key: CASSANDRA-14694 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14694 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination, Observability/Metrics >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0.x > > > Speculative read repair mutations shouldn't use read latencies to determine > when to send a speculative mutation. It should have it's own value based on > mutation latencies. -- 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-16026) Nodetool unit test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-16026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392514#comment-17392514 ] Ekaterina Dimitrova commented on CASSANDRA-16026: - This was opened by mistake, I was trying to change another ticket from bug to improvement but it seems Jira opens a new ticket. Closing this one in favor of the original one. > Nodetool unit test coverage > --- > > Key: CASSANDRA-16026 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16026 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x > > > Nowadays the majority of nodetool testing happens outside the main java unit > testing effort. A lot is done as separate dtests under python, some commands > don't have dedicated tests, some only get tested as a side effect of some > other test, etc. > The purpose of this ticket is to improve unit test coverage as much as > possible now that CASSANDRA-15583 allows us to perform java unit tests for > the tool. -- 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-15887) Document how to run Cassandra on Windows
[ https://issues.apache.org/jira/browse/CASSANDRA-15887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392511#comment-17392511 ] Paulo Motta commented on CASSANDRA-15887: - I think we dropped native Windows support but it would be nice to have WSL2 instructions for development purposes. > Document how to run Cassandra on Windows > > > Key: CASSANDRA-15887 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15887 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: João Reis >Priority: Low > Fix For: 4.0.x > > > The "Getting Started" section on the website only has instructions about > installing Cassandra on Linux. > It would help us drive Cassandra adoption if we had instructions for > developers that want to run Cassandra on their Windows development > environment. > We should include instructions on how to use the existing powershell scripts > to run Cassandra on native Windows but the docs should recommend users to > prefer using WSL2/Docker before attempting to run it natively in my opinion. -- 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-16592) The token function in where clause return incorrect data when using token equal condition and Specified a non-exist token value
[
https://issues.apache.org/jira/browse/CASSANDRA-16592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392505#comment-17392505
]
Ekaterina Dimitrova commented on CASSANDRA-16592:
-
Hi [~cimon], do you still plan to work on this ticket?
> The token function in where clause return incorrect data when using token
> equal condition and Specified a non-exist token value
> ---
>
> Key: CASSANDRA-16592
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16592
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: cimon
>Assignee: cimon
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> I get incorrect value when use query like 'select Token(pk1,pk2),pk1,pk2 from
> ks.table1 where token(pk1,pk2) = tokenValue'. The returned token value
> mismatch the where condition.
> This problem is reproduced in 3.11.3 and 4.0.
> Here is my schema and select statement
> {code:java}
> // schema
> cqlsh> desc testprefix.cprefix_03 ;CREATE TABLE testprefix.cprefix_03 (
> pk1 int,
> pk2 int,
> ck1 text,
> ck2 text,
> t1 int,
> PRIMARY KEY ((pk1, pk2), ck1, ck2)
> ) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 ASC)
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> {code}
> execute cql query
> {code:java}
> // code placeholder
> cqlsh> SELECT Token(pk1,pk2), pk1,pk2 from testprefix.cprefix_03 WHERE
> token(pk1, pk2) =-9223372036854775808 LIMIT 2;
> system.token(pk1, pk2) | pk1| pk2
> ++-
>-9222849988925915479 | 394560 | 3394560
>-9222849988925915479 | 394560 | 3394560
> (2 rows)
> cqlsh> SELECT Token(pk1,pk2) from testprefix.cprefix_03 where pk1 = 394560
> and pk2 = 3394560 LIMIT 2;
> system.token(pk1, pk2)
>
>-9222849988925915479
>-9222849988925915479
> (2 rows)
> cqlsh> SELECT Token(pk1,pk2), pk1,pk2 from testprefix.cprefix_03 WHERE
> token(pk1, pk2) =-9222849988925915479 LIMIT 2;
> system.token(pk1, pk2) | pk1| pk2
> ++-
>-9222849988925915479 | 394560 | 3394560
>-9222849988925915479 | 394560 | 3394560
> (2 rows){code}
> we can find that token value in the condition are inconsistent with the
> values in the result.
>
> Then review the source code, to seek the anwser.
> {code:java}
> // code placeholder
> private static void addRange(SSTableReader sstable,
> AbstractBounds requested,
> List> boundsList)
> {
> if (requested instanceof Range && ((Range)requested).isWrapAround())
> // first condition
> {
> if (requested.right.compareTo(sstable.first) >= 0)
> {
> // since we wrap, we must contain the whole sstable prior to
> stopKey()
> Boundary left = new
> Boundary(sstable.first, true);
> Boundary right;
> right = requested.rightBoundary();
> right = minRight(right, sstable.last, true);
> if (!isEmpty(left, right))
> boundsList.add(AbstractBounds.bounds(left, right));
> }
> if (requested.left.compareTo(sstable.last) <= 0)
> {
> // since we wrap, we must contain the whole sstable after
> dataRange.startKey()
> Boundary right = new
> Boundary(sstable.last, true);
> Boundary left;
> left = requested.leftBoundary();
> left = maxLeft(left, sstable.first, true); // second condition
> if (!isEmpty(left, right))
> boundsList.add(AbstractBounds.bounds(left, right));
> }
> }
> else
> {
> assert requested.left.compareTo(requested.right) <= 0 ||
> requested.right.isMinimum();
> Boundary left, right;
> left = requested.leftBoundary();
> right = requested.rightBoundary();
> left = maxLeft(left, sstable.first, true);
> //
[jira] [Commented] (CASSANDRA-16528) Update Cassandra dependencies to fix security vulnerabilities
[
https://issues.apache.org/jira/browse/CASSANDRA-16528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392504#comment-17392504
]
Ekaterina Dimitrova commented on CASSANDRA-16528:
-
[~brandon.williams] Is this ticket still needed?
> Update Cassandra dependencies to fix security vulnerabilities
> -
>
> Key: CASSANDRA-16528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16528
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Dependencies
>Reporter: LHX
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> There are a couple of security vulnerabilities that show up in libraries that
> cassandra pulls in.
> # apache commons-collections v 3.2.1
> # apache commons-beanutils v 1.7.0
> For number one, there is a well-known security vulnerability in apache
> commons-collection 3.2.1 (see [https://www.kb.cert.org/vuls/id/576313] and
> https://issues.apache.org/jira/browse/COLLECTIONS-580). This is
> fixed/mitigated in commons-collections 3.2.2.
> All current versions of cassandra (including 4.0beta4) pull in
> commons-collections 3.2.1 via apache-rat 0.10. Is it possible to upgrade
> apache-rat to version 0.12 in order to pull in the latest version of
> commons-collections? See
> [https://github.com/apache/creadur-rat/commit/2380409fbcd02b418eceacfdc1e486bdbbca9632].
> I made the below change in 3.0.24 src and recompiled without errors.
> {code:java}
> // code placeholder
> diff --git a/cassandra/cassandra-3.0-src/build.xml
> b/cassandra/cassandra-3.0-src/build.xml
> index 73c9889d81..ed236443d4 100644
> --- a/cassandra/cassandra-3.0-src/build.xml
> +++ b/cassandra/cassandra-3.0-src/build.xml
> @@ -402,3 +402,3 @@
> version="0.9.12" />
> - version="0.10">
> + version="0.12">
>
> @@ -1605,3 +1605,3 @@
>
> - version="0.6" />
> + version="0.12" />
>
> {code}
>
> For number two, I was able to discern that beanutils is coming from
> hadoop-core which is version 1.0.3. I believe this also is quite out of date
> and could be upgraded.
> Could someone take a look and see if these version upgrades are possible?
> {{}}
--
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-15887) Document how to run Cassandra on Windows
[ https://issues.apache.org/jira/browse/CASSANDRA-15887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392501#comment-17392501 ] Ekaterina Dimitrova commented on CASSANDRA-15887: - We dropped the Windows support but I guess this is still open to add the recommendation for WSL2? > Document how to run Cassandra on Windows > > > Key: CASSANDRA-15887 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15887 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: João Reis >Priority: Low > Fix For: 4.0.x > > > The "Getting Started" section on the website only has instructions about > installing Cassandra on Linux. > It would help us drive Cassandra adoption if we had instructions for > developers that want to run Cassandra on their Windows development > environment. > We should include instructions on how to use the existing powershell scripts > to run Cassandra on native Windows but the docs should recommend users to > prefer using WSL2/Docker before attempting to run it natively in my opinion. -- 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-15624) Avoid lazy initializing shut down instances when trying to send them messages
[
https://issues.apache.org/jira/browse/CASSANDRA-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392498#comment-17392498
]
Ekaterina Dimitrova commented on CASSANDRA-15624:
-
Hey [~gianluca], is this still in the pipeline?
> Avoid lazy initializing shut down instances when trying to send them messages
> -
>
> Key: CASSANDRA-15624
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15624
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Marcus Eriksson
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0.x
>
>
> We currently use {{to.broadcastAddressAndPort()}} when figuring out if we
> should send a message to an instance, if that instance has been shut down it
> will get re-initialized but not startup:ed which makes the tests fail.
--
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-14694) add latency sample for speculative read repair writes
[ https://issues.apache.org/jira/browse/CASSANDRA-14694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392493#comment-17392493 ] Ekaterina Dimitrova commented on CASSANDRA-14694: - Hi [~bdeggleston], [~benedict], [~cnlwsu], I was wondering whether this one is still in the TO DO pipeline? Any thoughts? > add latency sample for speculative read repair writes > - > > Key: CASSANDRA-14694 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14694 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination, Observability/Metrics >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0.x > > > Speculative read repair mutations shouldn't use read latencies to determine > when to send a speculative mutation. It should have it's own value based on > mutation latencies. -- 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-13649) Uncaught exceptions in Netty pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392492#comment-17392492
]
Ekaterina Dimitrova commented on CASSANDRA-13649:
-
Hey [~norman],
Any advice about the status of this ticket?
> Uncaught exceptions in Netty pipeline
> -
>
> Key: CASSANDRA-13649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13649
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Norman Maurer
>Priority: Normal
> Labels: patch
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x
>
> Attachments:
> 0001-CASSANDRA-13649-Ensure-all-exceptions-are-correctly-.patch,
> test_stdout.txt
>
>
> I've noticed some netty related errors in trunk in [some of the dtest
> results|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/106/#showFailuresLink].
> Just want to make sure that we don't have to change anything related to the
> exception handling in our pipeline and that this isn't a netty issue.
> Actually if this causes flakiness but is otherwise harmless, we should do
> something about it, even if it's just on the dtest side.
> {noformat}
> WARN [epollEventLoopGroup-2-9] 2017-06-28 17:23:49,699 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> And again in another test:
> {noformat}
> WARN [epollEventLoopGroup-2-8] 2017-06-29 02:27:31,300 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> Edit:
> The {{io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)()
> failed}} error also causes tests to fail for 3.0 and 3.11.
--
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&focusedCommentId=17392489#comment-17392489 ] Ekaterina Dimitrova commented on CASSANDRA-14606: - CC [~mck] > 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.x > > > 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] [Updated] (CASSANDRA-16026) Nodetool unit test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-16026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16026: Resolution: Fixed Status: Resolved (was: Open) > Nodetool unit test coverage > --- > > Key: CASSANDRA-16026 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16026 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x > > > Nowadays the majority of nodetool testing happens outside the main java unit > testing effort. A lot is done as separate dtests under python, some commands > don't have dedicated tests, some only get tested as a side effect of some > other test, etc. > The purpose of this ticket is to improve unit test coverage as much as > possible now that CASSANDRA-15583 allows us to perform java unit tests for > the tool. -- 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-16026) Nodetool unit test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-16026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16026: Workflow: Copy of Cassandra Default Workflow (was: Copy of Cassandra Bug Workflow) Issue Type: Improvement (was: Bug) > Nodetool unit test coverage > --- > > Key: CASSANDRA-16026 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16026 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x > > > Nowadays the majority of nodetool testing happens outside the main java unit > testing effort. A lot is done as separate dtests under python, some commands > don't have dedicated tests, some only get tested as a side effect of some > other test, etc. > The purpose of this ticket is to improve unit test coverage as much as > possible now that CASSANDRA-15583 allows us to perform java unit tests for > the tool. -- 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-13843) Debian init shadows CASSANDRA_HEAPDUMP_DIR
[ https://issues.apache.org/jira/browse/CASSANDRA-13843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-13843: Status: Needs Reviewer (was: Patch Available) > Debian init shadows CASSANDRA_HEAPDUMP_DIR > -- > > Key: CASSANDRA-13843 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13843 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Observability >Reporter: Andrew Jorgensen >Assignee: Brandon Williams >Priority: Low > Labels: newbie, patch > Fix For: 3.0.x, 3.11.x, 4.0.x > > Attachments: 0001-Remove-debian-init-setting-heap-dump-file.patch > > > The debian init script sets the heap dump file directly using the cassandra > users home directory and the -H flag to the cassandra > process[1|https://github.com/apache/cassandra/blob/8b3a60b9a7dbefeecc06bace617279612ec7092d/debian/init#L76]. > The cassandra heap dump location can also be set in the cassandra-env.sh > file using CASSANDRA_HEAPDUMP_DIR. Unfortunately the debian init heap dump > location is based off the home directory of the cassandra user and cannot > easily be changed. Also unfortunately if you do `ps aux | grep casandra` you > can clearly see that the -H flag takes precedent over the value found in > cassandra-env.sh. This makes it difficult to change the heap dump location > for cassandra and is non-intuitive when the value is set in cassandra-env.sh > why the heap dump does not actually end up in the correct place. -- 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-website] branch asf-staging updated (b073248 -> dd47589)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard b073248 Redirect old in-tree docs to include the /cassandra/ section in the URL This update removed existing revisions from the reference, leaving the reference pointing at a previous point in the repository history. * -- * -- N refs/heads/asf-staging (dd47589) \ O -- O -- O (b073248) Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. No new revisions were added by this update. Summary of changes: content/.htaccess | 25 + 1 file changed, 9 insertions(+), 16 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (5b24d11 -> b073248)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 5b24d11 Redirect old in-tree docs to include the /cassandra/ section in the URL new b073248 Redirect old in-tree docs to include the /cassandra/ section in the URL This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (5b24d11) \ N -- N -- N refs/heads/asf-staging (b073248) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/.htaccess | 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
[cassandra-website] 01/01: Redirect old in-tree docs to include the /cassandra/ section in the URL
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
commit b0732486de8054d91b2672447da52cda013bb0d5
Author: mck
AuthorDate: Tue Aug 3 21:23:42 2021 +0200
Redirect old in-tree docs to include the /cassandra/ section in the URL
---
content/.htaccess | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/content/.htaccess b/content/.htaccess
index c87afe0..07a1b05 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -1,17 +1,19 @@
-RewriteEngine On
+
+RewriteEngine On
-RewriteCond %{HTTPS} !=on
-RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
+# always https
+RewriteCond %{HTTPS} !=on
+RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
-RedirectMatch 301 "^/$" "/_/index.html"
+# frontpage
+RedirectMatch 301 "^/$" "/_/index.html"
-RewriteCond %{REQUEST_URI} !^/doc/.*
-RewriteCond %{REQUEST_URI} ^(.*)/$
-RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# redirect old style top-level URLs
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^(.*)/$
+RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
-
-RewriteEngine on
Redirect 301 /blog.html /_/blog.html
Redirect 301 /blog/2021/04/19/cass-world-party-speakers.html
/blog/Speakers-Announced-for-April-28-Cassandra-4.0-World-Party.html
Redirect 301 /blog/2021/04/12/cass-changelog_6.html
/blog/Apache-Cassandra-Changelog-6-April-2021.html
@@ -32,4 +34,9 @@ RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
Redirect 301
/blog/2018/10/17/finding_bugs_with_property_based_testing.html
/blog/Finding-Bugs-in-Cassandra's-Internals-with-Property-based-Testing.html
Redirect 301 /blog/2018/08/21/testing_apache_cassandra.html
/blog/Testing-Apache-Cassandra-4.html
Redirect 301 /blog/2018/08/07/faster_streaming_in_cassandra.html
/blog/Hardware-bound-Zero-Copy-Streaming-in-Apache-Cassandra-4.html
+
+# redirect old style in-tree docs URLs
+RewriteCond %{REQUEST_URI} !^/doc/latest/cassandra/.*
+RewriteCond %{REQUEST_URI} ^/doc/latest/(.*)$
+RewriteRule ^/doc/latest/(.*)$ /doc/latest/cassandra/$1 [R=301,L]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] 01/01: Redirect old in-tree docs to include the /cassandra/ section in the URL
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
commit 5b24d119f25484f8fe46575d753e96eba0937f4b
Author: mck
AuthorDate: Tue Aug 3 21:23:42 2021 +0200
Redirect old in-tree docs to include the /cassandra/ section in the URL
---
content/.htaccess | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/content/.htaccess b/content/.htaccess
index c87afe0..42cd3c9 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -1,17 +1,19 @@
-RewriteEngine On
+
+RewriteEngine On
-RewriteCond %{HTTPS} !=on
-RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
+# always https
+RewriteCond %{HTTPS} !=on
+RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
-RedirectMatch 301 "^/$" "/_/index.html"
+# frontpage
+RedirectMatch 301 "^/$" "/_/index.html"
-RewriteCond %{REQUEST_URI} !^/doc/.*
-RewriteCond %{REQUEST_URI} ^(.*)/$
-RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# redirect old style top-level URLs
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^(.*)/$
+RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
-
-RewriteEngine on
Redirect 301 /blog.html /_/blog.html
Redirect 301 /blog/2021/04/19/cass-world-party-speakers.html
/blog/Speakers-Announced-for-April-28-Cassandra-4.0-World-Party.html
Redirect 301 /blog/2021/04/12/cass-changelog_6.html
/blog/Apache-Cassandra-Changelog-6-April-2021.html
@@ -32,4 +34,9 @@ RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
Redirect 301
/blog/2018/10/17/finding_bugs_with_property_based_testing.html
/blog/Finding-Bugs-in-Cassandra's-Internals-with-Property-based-Testing.html
Redirect 301 /blog/2018/08/21/testing_apache_cassandra.html
/blog/Testing-Apache-Cassandra-4.html
Redirect 301 /blog/2018/08/07/faster_streaming_in_cassandra.html
/blog/Hardware-bound-Zero-Copy-Streaming-in-Apache-Cassandra-4.html
+
+# redirect old style in-tree docs URLs
+RewriteCond %{REQUEST_URI} !^/doc/latest/cassandra/.*
+RewriteCond %{REQUEST_URI} ^/doc/latest/(.*)$
+RewriteRule ^/doc/latest/(.*)$ ^/doc/latest/cassandra/$1 [R=301,L]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (e42ad5e -> 5b24d11)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard e42ad5e Redirect old in-tree docs to include the /cassandra/ section in the URL new 5b24d11 Redirect old in-tree docs to include the /cassandra/ section in the URL This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (e42ad5e) \ N -- N -- N refs/heads/asf-staging (5b24d11) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/.htaccess | 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
[cassandra-website] branch asf-staging updated (58533ee -> e42ad5e)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 58533ee Redirect old in-tree docs to include the /cassandra/ section in the URL new e42ad5e Redirect old in-tree docs to include the /cassandra/ section in the URL This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (58533ee) \ N -- N -- N refs/heads/asf-staging (e42ad5e) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/.htaccess | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] 01/01: Redirect old in-tree docs to include the /cassandra/ section in the URL
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
commit e42ad5e4fb3352c1837ef64d36dff231fb65b792
Author: mck
AuthorDate: Tue Aug 3 21:23:42 2021 +0200
Redirect old in-tree docs to include the /cassandra/ section in the URL
---
content/.htaccess | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/content/.htaccess b/content/.htaccess
index c87afe0..1aef472 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -1,17 +1,19 @@
-RewriteEngine On
+
+RewriteEngine On
-RewriteCond %{HTTPS} !=on
-RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
+# always https
+RewriteCond %{HTTPS} !=on
+RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
-RedirectMatch 301 "^/$" "/_/index.html"
+# frontpage
+RedirectMatch 301 "^/$" "/_/index.html"
-RewriteCond %{REQUEST_URI} !^/doc/.*
-RewriteCond %{REQUEST_URI} ^(.*)/$
-RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# redirect old style top-level URLs
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^(.*)/$
+RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
-
-RewriteEngine on
Redirect 301 /blog.html /_/blog.html
Redirect 301 /blog/2021/04/19/cass-world-party-speakers.html
/blog/Speakers-Announced-for-April-28-Cassandra-4.0-World-Party.html
Redirect 301 /blog/2021/04/12/cass-changelog_6.html
/blog/Apache-Cassandra-Changelog-6-April-2021.html
@@ -32,4 +34,9 @@ RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
Redirect 301
/blog/2018/10/17/finding_bugs_with_property_based_testing.html
/blog/Finding-Bugs-in-Cassandra's-Internals-with-Property-based-Testing.html
Redirect 301 /blog/2018/08/21/testing_apache_cassandra.html
/blog/Testing-Apache-Cassandra-4.html
Redirect 301 /blog/2018/08/07/faster_streaming_in_cassandra.html
/blog/Hardware-bound-Zero-Copy-Streaming-in-Apache-Cassandra-4.html
+
+# redirect old style in-tree docs URLs
+RewriteCond %{REQUEST_URI} !^/doc/latest/cassandra/.*
+RewriteCond %{REQUEST_URI} ^/doc/latest/(.*)$
+RewriteRule ^/doc/latest/cassandra/$1 [R=301,L]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (55a435b -> 58533ee)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 55a435b Redirect old in-tree docs to include the /cassandra/ section in the URL new 58533ee Redirect old in-tree docs to include the /cassandra/ section in the URL This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (55a435b) \ N -- N -- N refs/heads/asf-staging (58533ee) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/.htaccess | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] 01/01: Redirect old in-tree docs to include the /cassandra/ section in the URL
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
commit 58533ee0475e4300a904869392ec86f8878f52cd
Author: mck
AuthorDate: Tue Aug 3 21:23:42 2021 +0200
Redirect old in-tree docs to include the /cassandra/ section in the URL
---
content/.htaccess | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/content/.htaccess b/content/.htaccess
index c87afe0..8004f14 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -1,17 +1,19 @@
-RewriteEngine On
+
+RewriteEngine On
-RewriteCond %{HTTPS} !=on
-RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
+# always https
+RewriteCond %{HTTPS} !=on
+RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
-RedirectMatch 301 "^/$" "/_/index.html"
+# frontpage
+RedirectMatch 301 "^/$" "/_/index.html"
-RewriteCond %{REQUEST_URI} !^/doc/.*
-RewriteCond %{REQUEST_URI} ^(.*)/$
-RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# redirect old style top-level URLs
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^(.*)/$
+RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
-
-RewriteEngine on
Redirect 301 /blog.html /_/blog.html
Redirect 301 /blog/2021/04/19/cass-world-party-speakers.html
/blog/Speakers-Announced-for-April-28-Cassandra-4.0-World-Party.html
Redirect 301 /blog/2021/04/12/cass-changelog_6.html
/blog/Apache-Cassandra-Changelog-6-April-2021.html
@@ -32,4 +34,9 @@ RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
Redirect 301
/blog/2018/10/17/finding_bugs_with_property_based_testing.html
/blog/Finding-Bugs-in-Cassandra's-Internals-with-Property-based-Testing.html
Redirect 301 /blog/2018/08/21/testing_apache_cassandra.html
/blog/Testing-Apache-Cassandra-4.html
Redirect 301 /blog/2018/08/07/faster_streaming_in_cassandra.html
/blog/Hardware-bound-Zero-Copy-Streaming-in-Apache-Cassandra-4.html
+
+# redirect old style in-tree docs URLs
+RewriteCond %{REQUEST_URI} !^/doc/(latest)/cassandra/.*
+RewriteCond %{REQUEST_URI} ^/doc/(latest)/(.*)$
+RewriteRule ^/doc/$1/cassandra/$2 [R=301,L]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] 01/01: Redirect old in-tree docs to include the /cassandra/ section in the URL
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
commit 55a435b31594f6ea741b184da757c5f76018692c
Author: mck
AuthorDate: Tue Aug 3 21:23:42 2021 +0200
Redirect old in-tree docs to include the /cassandra/ section in the URL
---
content/.htaccess | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/content/.htaccess b/content/.htaccess
index c87afe0..05d29c1 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -1,17 +1,19 @@
-RewriteEngine On
+
+RewriteEngine On
-RewriteCond %{HTTPS} !=on
-RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
+# always https
+RewriteCond %{HTTPS} !=on
+RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
-RedirectMatch 301 "^/$" "/_/index.html"
+# frontpage
+RedirectMatch 301 "^/$" "/_/index.html"
-RewriteCond %{REQUEST_URI} !^/doc/.*
-RewriteCond %{REQUEST_URI} ^(.*)/$
-RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# redirect old style top-level URLs
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^(.*)/$
+RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
-
-RewriteEngine on
Redirect 301 /blog.html /_/blog.html
Redirect 301 /blog/2021/04/19/cass-world-party-speakers.html
/blog/Speakers-Announced-for-April-28-Cassandra-4.0-World-Party.html
Redirect 301 /blog/2021/04/12/cass-changelog_6.html
/blog/Apache-Cassandra-Changelog-6-April-2021.html
@@ -32,4 +34,9 @@ RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
Redirect 301
/blog/2018/10/17/finding_bugs_with_property_based_testing.html
/blog/Finding-Bugs-in-Cassandra's-Internals-with-Property-based-Testing.html
Redirect 301 /blog/2018/08/21/testing_apache_cassandra.html
/blog/Testing-Apache-Cassandra-4.html
Redirect 301 /blog/2018/08/07/faster_streaming_in_cassandra.html
/blog/Hardware-bound-Zero-Copy-Streaming-in-Apache-Cassandra-4.html
+
+# redirect old style in-tree docs URLs
+RewriteCond %{REQUEST_URI} !^/doc/(3.11|4.0|stable|latest)/cassandra/.*
+RewriteCond %{REQUEST_URI} ^/doc/(3.11|4.0|stable|latest)/(.*)$
+RewriteRule ^/doc/$1/cassandra/$2 [R=301,L]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (15202bb -> 55a435b)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 15202bb Redirect old in-tree docs to include the /cassandra/ section in the URL new 55a435b Redirect old in-tree docs to include the /cassandra/ section in the URL This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (15202bb) \ N -- N -- N refs/heads/asf-staging (55a435b) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/.htaccess | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated: Redirect old in-tree docs to include the /cassandra/ section in the URL
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new 15202bb Redirect old in-tree docs to include the /cassandra/ section
in the URL
15202bb is described below
commit 15202bb59d20cd838668c55dc4f8d24f3f4bd436
Author: mck
AuthorDate: Tue Aug 3 21:23:42 2021 +0200
Redirect old in-tree docs to include the /cassandra/ section in the URL
---
content/.htaccess | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/content/.htaccess b/content/.htaccess
index c87afe0..75cdd2c 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -1,17 +1,19 @@
-RewriteEngine On
+
+RewriteEngine On
-RewriteCond %{HTTPS} !=on
-RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
+# always https
+RewriteCond %{HTTPS} !=on
+RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
-RedirectMatch 301 "^/$" "/_/index.html"
+# frontpage
+RedirectMatch 301 "^/$" "/_/index.html"
-RewriteCond %{REQUEST_URI} !^/doc/.*
-RewriteCond %{REQUEST_URI} ^(.*)/$
-RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# redirect old style top-level URLs
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^(.*)/$
+RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
-
-RewriteEngine on
Redirect 301 /blog.html /_/blog.html
Redirect 301 /blog/2021/04/19/cass-world-party-speakers.html
/blog/Speakers-Announced-for-April-28-Cassandra-4.0-World-Party.html
Redirect 301 /blog/2021/04/12/cass-changelog_6.html
/blog/Apache-Cassandra-Changelog-6-April-2021.html
@@ -32,4 +34,9 @@ RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
Redirect 301
/blog/2018/10/17/finding_bugs_with_property_based_testing.html
/blog/Finding-Bugs-in-Cassandra's-Internals-with-Property-based-Testing.html
Redirect 301 /blog/2018/08/21/testing_apache_cassandra.html
/blog/Testing-Apache-Cassandra-4.html
Redirect 301 /blog/2018/08/07/faster_streaming_in_cassandra.html
/blog/Hardware-bound-Zero-Copy-Streaming-in-Apache-Cassandra-4.html
+
+# redirect old style in-tree docs URLs
+RewriteCond %{REQUEST_URI} !^/doc/(3.11|4.0)/cassandra/.*
+RewriteCond %{REQUEST_URI} ^/doc/(3.11|4.0)/(.*)$
+RewriteRule ^/doc/$1/cassandra/$2 [R=301,L]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (bd8b036 -> dd47589)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard bd8b036 Add a redirect for 404 pages, to onee level up This update removed existing revisions from the reference, leaving the reference pointing at a previous point in the repository history. * -- * -- N refs/heads/asf-staging (dd47589) \ O -- O -- O (bd8b036) Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. No new revisions were added by this update. Summary of changes: content/.htaccess | 26 +- 1 file changed, 9 insertions(+), 17 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] 01/01: Add a redirect for 404 pages, to onee level up
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
commit bd8b036ba08d5d95e3a4d597afdc83bf48a03fa5
Author: mck
AuthorDate: Tue Aug 3 21:03:06 2021 +0200
Add a redirect for 404 pages, to onee level up
---
content/.htaccess | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/content/.htaccess b/content/.htaccess
index c87afe0..73e3b56 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -1,17 +1,19 @@
-RewriteEngine On
+
+RewriteEngine On
-RewriteCond %{HTTPS} !=on
-RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
+# always https
+RewriteCond %{HTTPS} !=on
+RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
-RedirectMatch 301 "^/$" "/_/index.html"
+# frontpage
+RedirectMatch 301 "^/$" "/_/index.html"
-RewriteCond %{REQUEST_URI} !^/doc/.*
-RewriteCond %{REQUEST_URI} ^(.*)/$
-RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# redirect old style URLs into .html new format
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^(.*)/$
+RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
-
-RewriteEngine on
Redirect 301 /blog.html /_/blog.html
Redirect 301 /blog/2021/04/19/cass-world-party-speakers.html
/blog/Speakers-Announced-for-April-28-Cassandra-4.0-World-Party.html
Redirect 301 /blog/2021/04/12/cass-changelog_6.html
/blog/Apache-Cassandra-Changelog-6-April-2021.html
@@ -32,4 +34,10 @@ RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
Redirect 301
/blog/2018/10/17/finding_bugs_with_property_based_testing.html
/blog/Finding-Bugs-in-Cassandra's-Internals-with-Property-based-Testing.html
Redirect 301 /blog/2018/08/21/testing_apache_cassandra.html
/blog/Testing-Apache-Cassandra-4.html
Redirect 301 /blog/2018/08/07/faster_streaming_in_cassandra.html
/blog/Hardware-bound-Zero-Copy-Streaming-in-Apache-Cassandra-4.html
+
+## if current file/directory doesn't exist then
+## forward to the parent directory of the current REQUEST_URI
+RewriteCond %{REQUEST_FILENAME}/$0 !-f
+RewriteCond %{REQUEST_FILENAME}/$0 !-d
+RewriteRule ^(?:(.+?)/)?[^/]+/?$ /$1 [L,NE,R=302]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (de3465f -> bd8b036)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard de3465f Add a redirect for 404 pages, to onee level up new bd8b036 Add a redirect for 404 pages, to onee level up This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (de3465f) \ N -- N -- N refs/heads/asf-staging (bd8b036) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/.htaccess | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated: Add a redirect for 404 pages, to onee level up
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new de3465f Add a redirect for 404 pages, to onee level up
de3465f is described below
commit de3465f98d683a3ec040187b17ab20300915bfcc
Author: mck
AuthorDate: Tue Aug 3 21:03:06 2021 +0200
Add a redirect for 404 pages, to onee level up
---
content/.htaccess | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/content/.htaccess b/content/.htaccess
index c87afe0..dee187e 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -1,17 +1,19 @@
-RewriteEngine On
+
+RewriteEngine On
-RewriteCond %{HTTPS} !=on
-RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
+# always https
+RewriteCond %{HTTPS} !=on
+RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
-RedirectMatch 301 "^/$" "/_/index.html"
+# frontpage
+RedirectMatch 301 "^/$" "/_/index.html"
-RewriteCond %{REQUEST_URI} !^/doc/.*
-RewriteCond %{REQUEST_URI} ^(.*)/$
-RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# redirect old style URLs into .html new format
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^(.*)/$
+RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
-
-RewriteEngine on
Redirect 301 /blog.html /_/blog.html
Redirect 301 /blog/2021/04/19/cass-world-party-speakers.html
/blog/Speakers-Announced-for-April-28-Cassandra-4.0-World-Party.html
Redirect 301 /blog/2021/04/12/cass-changelog_6.html
/blog/Apache-Cassandra-Changelog-6-April-2021.html
@@ -32,4 +34,10 @@ RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
Redirect 301
/blog/2018/10/17/finding_bugs_with_property_based_testing.html
/blog/Finding-Bugs-in-Cassandra's-Internals-with-Property-based-Testing.html
Redirect 301 /blog/2018/08/21/testing_apache_cassandra.html
/blog/Testing-Apache-Cassandra-4.html
Redirect 301 /blog/2018/08/07/faster_streaming_in_cassandra.html
/blog/Hardware-bound-Zero-Copy-Streaming-in-Apache-Cassandra-4.html
+
+## if current file/directory doesn't exist then
+## forward to the parent directory of the current REQUEST_URI
+RewriteCond %{DOCUMENT_ROOT}/$0 !-f
+RewriteCond %{DOCUMENT_ROOT}/$0 !-d
+RewriteRule ^(?:(.+?)/)?[^/]+/?$ /$1 [L,NE,R=302]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16663) Request-Based Native Transport Rate-Limiting
[ https://issues.apache.org/jira/browse/CASSANDRA-16663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-16663: -- Reviewers: Benedict Elliott Smith, Josh McKenzie (was: Benedict Elliott Smith, Sam Tunnicliffe) > Request-Based Native Transport Rate-Limiting > > > Key: CASSANDRA-16663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16663 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.x > > Time Spent: 6h 10m > Remaining Estimate: 0h > > Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support > for a runtime-configurable, per-coordinator limit on the number of bytes > allocated for concurrent requests over the native protocol. It supports > channel back-pressure by default, and optionally supports throwing > OverloadedException if that is requested in the relevant connection’s STARTUP > message. > This can be an effective tool to prevent the coordinator from running out of > memory, but it may not correspond to how expensive a queries are or provide a > direct conceptual mapping to how users think about request capacity. I > propose adding the option of request-based (or perhaps more correctly > message-based) back-pressure, coexisting with (and reusing the logic that > supports) the current bytes-based back-pressure. > _We can roll this forward in phases_, where the server’s cost accounting > becomes more accurate, we segment limits by operation type/keyspace/etc., and > the client/driver reacts more intelligently to (especially non-back-pressure) > overload, _but something minimally viable could look like this_: > 1.) Reuse most of the existing logic in Limits, et al. to support a simple > per-coordinator limit only on native transport requests per second. Under > this limit will be CQL reads and writes, but also auth requests, prepare > requests, and batches. This is obviously simplistic, and it does not account > for the variation in cost between individual queries, but even a fixed cost > model should be useful in aggregate. > * If the client specifies THROW_ON_OVERLOAD in its STARTUP message at > connection time, a breach of the per-node limit will result in an > OverloadedException being propagated to the client, and the server will > discard the request. > * If THROW_ON_OVERLOAD is not specified, the server will stop consuming > messages from the channel/socket, which should back-pressure the client, > while the message continues to be processed. > 2.) This limit is infinite by default (or simply disabled), and can be > enabled via the YAML config or JMX at runtime. (It might be cleaner to have a > no-op rate limiter that's used when the feature is disabled entirely.) > 3.) The current value of the limit is available via JMX, and metrics around > coordinator operations/second are already available to compare against it. > 4.) Any interaction with existing byte-based limits will intersect. (i.e. A > breach of any limit, bytes or request-based, will actuate back-pressure or > OverloadedExceptions.) > In this first pass, explicitly out of scope would be any work on the > client/driver side. > In terms of validation/testing, our biggest concern with anything that adds > overhead on a very hot path is performance. In particular, we want to fully > understand how the client and server perform along two axes constituting 4 > scenarios. Those are a.) whether or not we are breaching the request limit > and b.) whether the server is throwing on overload at the behest of the > client. Having said that, query execution should dwarf the cost of limit > accounting. -- 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-16822) Wrong cqlsh python library location in cassandra-3.11.11-1 rhel packages
[
https://issues.apache.org/jira/browse/CASSANDRA-16822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391591#comment-17391591
]
Michael Semb Wever edited comment on CASSANDRA-16822 at 8/3/21, 5:24 PM:
-
Patches
-
[2.2|https://github.com/apache/cassandra/compare/cassandra-2.2...thelastpickle:mck/16822/2.2]
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/991/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/991/]
-
[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/16822/3.0]
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/985/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/985/]
-
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/16822/3.11]
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/986/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/986/]
I am not sure if this is the way we want to go though. That is, building on
python3, and installing that cqlshlib into site-packages for both python2 and
python3. (This approach leaves arm64 as-is, and keeps the door open for cqlsh
working on python3.)
RPMs built with these patches, for testing, can be found in
https://nightlies.apache.org/cassandra/devbranch/misc/CASSANDRA-16822/
was (Author: michaelsembwever):
Patches
-
[2.2|https://github.com/apache/cassandra/compare/cassandra-2.2...thelastpickle:mck/16822/2.2]
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/984/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/984/]
-
[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/16822/3.0]
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/985/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/985/]
-
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/16822/3.11]
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/986/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch/986/]
I am not sure if this is the way we want to go though. That is, building on
python3, and installing that cqlshlib into site-packages for both python2 and
python3. (This approach leaves arm64 as-is, and keeps the door open for cqlsh
working on python3.)
RPMs built with these patches, for testing, can be found in
https://nightlies.apache.org/cassandra/devbranch/misc/CASSANDRA-16822/
> Wrong cqlsh python library location in cassandra-3.11.11-1 rhel packages
> -
>
> Key: CASSANDRA-16822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16822
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Ville Savolainen
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> cqlsh does not work because cqlshlib is in wrong location while I think it
> should be in python2.7 for cassandra-3.11
> cassandra.spec seems to define python interpreter to /usr/bin/python so I
> think build environment has been changed after 3.11.10 so /usr/bin/python
> points to python3 instead of python2.
> cassandra-3.11.10 did have chqlshlib in python2.7 site-packages
> {noformat}
> $ rpm -qpl cassandra-3.11.11-1.noarch.rpm |grep cql
> warning: cassandra-3.11.11-1.noarch.rpm: Header V4 RSA/SHA512 Signature, key
> ID 0b84c041: NOKEY
> /etc/cassandra/default.conf/cqlshrc.sample
> /usr/bin/cqlsh
> /usr/bin/cqlsh.py
> /usr/bin/debug-cql
> /usr/lib/python3.6/site-packages/cqlshlib
> /usr/lib/python3.6/site-packages/cqlshlib/__init__.py
> /usr/lib/python3.6/site-packages/cqlshlib/copyutil.py
> /usr/lib/python3.6/site-packages/cqlshlib/cql3handling.py
> /usr/lib/python3.6/site-packages/cqlshlib/cqlhandling.py
> /usr/lib/python3.6/site-packages/cqlshlib/cqlshhandling.py
> /usr/lib/python3.6/site-packages/cqlshlib/displaying.py
> /usr/lib/python3.6/site-packages/cqlshlib/formatting.py
> /usr/lib/python3.6/site-packages/cqlshlib/helptopics.py
> /usr/lib/python3.6/site-packages/cqlshlib/pylexotron.py
> /usr/lib/python3.6/site-packages/cqlshlib/saferscanner.py
> /usr/lib/python3.6/site-packages/cqlshlib/sslhandling.py
> /usr/lib/python3.6/site-packages/cqlshlib/tracing.py
> /usr/lib/python3.6/site-packages/cqlshlib/util.py
> /usr/lib/python3.6/site-packages/cqlshlib/wcwidth.py
> {noformat}
>
> Pull request to cassandra-3.11: https://github.com/apache/cassandra/pull/1124
--
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...@cass
[jira] [Updated] (CASSANDRA-16825) Make client warnings thread safe and sent only once
[ https://issues.apache.org/jira/browse/CASSANDRA-16825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16825: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: Legacy/Observability Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Make client warnings thread safe and sent only once > --- > > Key: CASSANDRA-16825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16825 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Observability >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16825) Make client warnings thread safe and sent only once
[ https://issues.apache.org/jira/browse/CASSANDRA-16825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16825: Fix Version/s: 4.x 4.0.x 3.11.x > Make client warnings thread safe and sent only once > --- > > Key: CASSANDRA-16825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16825 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Observability >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > -- 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-16825) Make client warnings thread safe and sent only once
Ekaterina Dimitrova created CASSANDRA-16825: --- Summary: Make client warnings thread safe and sent only once Key: CASSANDRA-16825 URL: https://issues.apache.org/jira/browse/CASSANDRA-16825 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova Assignee: Ekaterina Dimitrova -- 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-16782) Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window
[
https://issues.apache.org/jira/browse/CASSANDRA-16782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392350#comment-17392350
]
Branimir Lambov commented on CASSANDRA-16782:
-
I have some general questions about the improvement. It looks like it is a
combination of two things:
* A drastic increase of STCS's limit for max sstables in a compaction, and
* A preference of the STCS level to compact based on the number of sstables,
which only apply to uses of STCS in LCS and TWCS.
I can see a lot of value in the latter, but why not apply it always, including
plain STCS? STCS's selection of bucket to compact does result in accumulation
of sstables on the smallest-sstables bucket and at DataStax we were recently
discussing selecting the most populous bucket as a possible solution to this
problem, which might be good enough even without raising the max limit. I
personally could not find any downsides to it, and I wonder why you would
prefer to restrict its usage?
The former we can achieve by configuration, can't we? (Perhaps also adding a
max size limit.) Speaking of which, is there a reason to place the new settings
in {{cassandra.yaml}} instead of compaction parameters?
> Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window
>
>
> Key: CASSANDRA-16782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16782
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction/LCS, Local/Compaction/TWCS
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> The goal when being behind in L0 should always be to get the number of
> sstables down to a reasonable level as soon as possible. Currently it is
> common that we run compactions on the large sstables but leave thousands of
> tiny sstables behind.
--
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-16782) Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window
[ https://issues.apache.org/jira/browse/CASSANDRA-16782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Branimir Lambov updated CASSANDRA-16782: Status: Review In Progress (was: Patch Available) > Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window > > > Key: CASSANDRA-16782 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16782 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction/LCS, Local/Compaction/TWCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > The goal when being behind in L0 should always be to get the number of > sstables down to a reasonable level as soon as possible. Currently it is > common that we run compactions on the large sstables but leave thousands of > tiny sstables behind. -- 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-16782) Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window
[ https://issues.apache.org/jira/browse/CASSANDRA-16782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Branimir Lambov updated CASSANDRA-16782: Reviewers: Aleksei Zotov, Branimir Lambov > Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window > > > Key: CASSANDRA-16782 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16782 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction/LCS, Local/Compaction/TWCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > The goal when being behind in L0 should always be to get the number of > sstables down to a reasonable level as soon as possible. Currently it is > common that we run compactions on the large sstables but leave thousands of > tiny sstables behind. -- 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-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-10023: - Test and Documentation Plan: included Status: Patch Available (was: Open) > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Sankalp Kohli >Assignee: Damien Stevenson >Priority: Low > Labels: 4.0-feature-freeze-review-requested, lhf > Fix For: 4.x > > Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, > CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the 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-11181) Add broadcast_rpc_address to system.local
[ https://issues.apache.org/jira/browse/CASSANDRA-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392238#comment-17392238 ] Stefan Miklosovic commented on CASSANDRA-11181: --- I am waiting for the second reviewer to take a look. > Add broadcast_rpc_address to system.local > - > > Key: CASSANDRA-11181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11181 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Nick Bailey >Assignee: Chang Liu >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Right now it's impossible to get the broadcast_rpc_address of the node you > are connected to via the drivers. -- 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-11181) Add broadcast_rpc_address to system.local
[ https://issues.apache.org/jira/browse/CASSANDRA-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-11181: -- Status: Needs Reviewer (was: Patch Available) > Add broadcast_rpc_address to system.local > - > > Key: CASSANDRA-11181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11181 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Nick Bailey >Assignee: Chang Liu >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Right now it's impossible to get the broadcast_rpc_address of the node you > are connected to via the drivers. -- 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-11181) Add broadcast_rpc_address to system.local
[ https://issues.apache.org/jira/browse/CASSANDRA-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392237#comment-17392237 ] Stefan Miklosovic commented on CASSANDRA-11181: --- build [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/990/] PR [https://github.com/apache/cassandra/pull/1127] > Add broadcast_rpc_address to system.local > - > > Key: CASSANDRA-11181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11181 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Nick Bailey >Assignee: Chang Liu >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Right now it's impossible to get the broadcast_rpc_address of the node you > are connected to via the drivers. -- 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-16718) Changing listen_address with prefer_local may lead to issues
[ https://issues.apache.org/jira/browse/CASSANDRA-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392196#comment-17392196 ] Jan Karlsson commented on CASSANDRA-16718: -- Took a look at the code base. It seems to be quite a difficult thing to change as it is intertwined with the message pools per node. Maybe someone with more experience with the networking can shed some light on the issue. > Changing listen_address with prefer_local may lead to issues > > > Key: CASSANDRA-16718 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16718 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Jan Karlsson >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > Many container based solution function by assigning new listen_addresses when > nodes are stopped. Changing the listen_address is usually as simple as > turning off the node and changing the yaml file. > However, if prefer_local is enabled, I observed that nodes were unable to > join the cluster and fail with 'Unable to gossip with any seeds'. > Trace shows that the changing node will try to communicate with the existing > node but the response is never received. I assume it is because the existing > node attempts to communicate with the local address during the shadow round. > -- 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-16718) Changing listen_address with prefer_local may lead to issues
[ https://issues.apache.org/jira/browse/CASSANDRA-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Karlsson reassigned CASSANDRA-16718: Assignee: (was: Jan Karlsson) > Changing listen_address with prefer_local may lead to issues > > > Key: CASSANDRA-16718 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16718 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Jan Karlsson >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > Many container based solution function by assigning new listen_addresses when > nodes are stopped. Changing the listen_address is usually as simple as > turning off the node and changing the yaml file. > However, if prefer_local is enabled, I observed that nodes were unable to > join the cluster and fail with 'Unable to gossip with any seeds'. > Trace shows that the changing node will try to communicate with the existing > node but the response is never received. I assume it is because the existing > node attempts to communicate with the local address during the shadow round. > -- 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-16718) Changing listen_address with prefer_local may lead to issues
[ https://issues.apache.org/jira/browse/CASSANDRA-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Karlsson reassigned CASSANDRA-16718: Assignee: Jan Karlsson > Changing listen_address with prefer_local may lead to issues > > > Key: CASSANDRA-16718 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16718 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Jan Karlsson >Assignee: Jan Karlsson >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > Many container based solution function by assigning new listen_addresses when > nodes are stopped. Changing the listen_address is usually as simple as > turning off the node and changing the yaml file. > However, if prefer_local is enabled, I observed that nodes were unable to > join the cluster and fail with 'Unable to gossip with any seeds'. > Trace shows that the changing node will try to communicate with the existing > node but the response is never received. I assume it is because the existing > node attempts to communicate with the local address during the shadow round. > -- 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-12774) Expose dc in Unavailable exception errors
[
https://issues.apache.org/jira/browse/CASSANDRA-12774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392065#comment-17392065
]
Stefan Miklosovic commented on CASSANDRA-12774:
---
[~andrew.tolbert] what version of Cassandra have you seen this problem in?
> Expose dc in Unavailable exception errors
> -
>
> Key: CASSANDRA-12774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12774
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Andy Tolbert
>Priority: Low
>
> For protocol v5 or later, it could be useful if Unavailable optionally
> included the DC that could not meet the CL.
> For example. if a user has a keyspace with RF of { dc1: 3, dc2: 3 } and they
> make a query at {{EACH_QUORUM}} and not enough replicas are available in dc2,
> an {{UnavailableException}} will be sent to the client with X available and 2
> required, but we don't know which DC failed. It looks like
> {{UnavailableException}} already has a constructor that takes in the DC (see
> [here|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/exceptions/UnavailableException.java#L33])
> so this could be feasible.
--
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-16666) Make SSLContext creation pluggable/extensible
[ https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-1: -- Reviewers: Berenguer Blasi, Stefan Miklosovic (was: Berenguer Blasi) > Make SSLContext creation pluggable/extensible > - > > Key: CASSANDRA-1 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Maulin Vasavada >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.x > > > Currently Cassandra creates the SSLContext via SSLFactory.java. SSLFactory is > a final class with static methods and not overridable. The SSLFactory loads > the keys and certs from the file based artifacts for the same. While this > works for many, in the industry where security is stricter and contextual, > this approach falls short. Many big organizations need flexibility to load > the SSL artifacts from a custom resource (like custom Key Management > Solution, HashiCorp Vault, Amazon KMS etc). While JSSE SecurityProvider > architecture allows us flexibility to build our custom mechanisms to validate > and process security artifacts, many times all we need is to build upon > Java's existing extensibility that Trust/Key Manager interfaces provide to > load keystores from various resources in the absence of any customized > requirements on the Keys/Certificate formats. > My proposal here is to make the SSLContext creation pluggable/extensible and > have the current SSLFactory.java implement an extensible interface. > I contributed a similar change that is live now in Apache Kafka (2.6.0) - > https://issues.apache.org/jira/browse/KAFKA-8890 > I can spare some time writing the pluggable interface and run by the required > reviewers. > > Created [CEP-9: Make SSLContext creation > pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable] > > > cc: [~dcapwell] [~djoshi] -- 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-16666) Make SSLContext creation pluggable/extensible
[ https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392038#comment-17392038 ] Stefan Miklosovic commented on CASSANDRA-1: --- Hi [~maulin.vasavada], would you mind to also update the relevant documentation which ships with Cassandra in the repository to explain what you did and how it is meant to be used? > Make SSLContext creation pluggable/extensible > - > > Key: CASSANDRA-1 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Maulin Vasavada >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.x > > > Currently Cassandra creates the SSLContext via SSLFactory.java. SSLFactory is > a final class with static methods and not overridable. The SSLFactory loads > the keys and certs from the file based artifacts for the same. While this > works for many, in the industry where security is stricter and contextual, > this approach falls short. Many big organizations need flexibility to load > the SSL artifacts from a custom resource (like custom Key Management > Solution, HashiCorp Vault, Amazon KMS etc). While JSSE SecurityProvider > architecture allows us flexibility to build our custom mechanisms to validate > and process security artifacts, many times all we need is to build upon > Java's existing extensibility that Trust/Key Manager interfaces provide to > load keystores from various resources in the absence of any customized > requirements on the Keys/Certificate formats. > My proposal here is to make the SSLContext creation pluggable/extensible and > have the current SSLFactory.java implement an extensible interface. > I contributed a similar change that is live now in Apache Kafka (2.6.0) - > https://issues.apache.org/jira/browse/KAFKA-8890 > I can spare some time writing the pluggable interface and run by the required > reviewers. > > Created [CEP-9: Make SSLContext creation > pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable] > > > cc: [~dcapwell] [~djoshi] -- 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
