[jira] [Commented] (CASSANDRA-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229826#comment-17229826
]
Tibor Repasi commented on CASSANDRA-16259:
--
These log messages started after upgrade Apache Cassandra from 3.11.8 to
3.11.9, running Datastax MCAC-Agent 0.1.11 (later upgraded to 0.1.12, without
noticeable change).
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:276)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Sta
[jira] [Updated] (CASSANDRA-16013) sstablescrub unit test hardening an docs improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16013:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 4.0
Severity: Normal
Assignee: Berenguer Blasi
Status: Open (was: Triage Needed)
> sstablescrub unit test hardening an docs improvements
> -
>
> Key: CASSANDRA-16013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16013
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During CASSANDRA-15883 / CASSANDRA-15991 it was detected unit test coverage
> for this tool is minimal. There is a unit test to enhance upon under
> {{test/unit/org/apache/cassandra/tools}}. Also docs need updating to reflect
> the latest options available.
--
This message was sent by Atlassian Jira
(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-16013) sstablescrub unit test hardening an docs improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16013:
Test and Documentation Plan: See PR
Status: Patch Available (was: In Progress)
> sstablescrub unit test hardening an docs improvements
> -
>
> Key: CASSANDRA-16013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16013
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> During CASSANDRA-15883 / CASSANDRA-15991 it was detected unit test coverage
> for this tool is minimal. There is a unit test to enhance upon under
> {{test/unit/org/apache/cassandra/tools}}. Also docs need updating to reflect
> the latest options available.
--
This message was sent by Atlassian Jira
(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-16234) Update NetBeans project file for dependency changes since 11th Feb 2020
[ https://issues.apache.org/jira/browse/CASSANDRA-16234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229909#comment-17229909 ] Michael Semb Wever commented on CASSANDRA-16234: Patch at https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_16234 > Update NetBeans project file for dependency changes since 11th Feb 2020 > --- > > Key: CASSANDRA-16234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16234 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > A number of dependencies have been add/removed/updated to the project. > The netbeans project file needs an update to be in-sync. > Causing tickets: > - CASSANDRA-15677 > - CASSANDRA-16064 > - CASSANDRA-12995 > - CASSANDRA-15867 > - CASSANDRA-12197 > - CASSANDRA-15556 > - CASSANDRA-15868 > - CASSANDRA-16150 > - CASSANDRA-15631 > - CASSANDRA-15851 > - CASSANDRA-16148 > - CASSANDRA-14655 > - CASSANDRA-15867 > - CASSANDRA-15388 > - CASSANDRA-15564 > - CASSANDRA-16127 -- This message was sent by Atlassian Jira (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-16234) Update NetBeans project file for dependency changes since 11th Feb 2020
[ https://issues.apache.org/jira/browse/CASSANDRA-16234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16234: --- Test and Documentation Plan: open project in NetBeans, example instructions at https://cassandra.apache.org/doc/latest/development/ide.html#opening-cassandra-in-apache-netbeans Status: Patch Available (was: In Progress) > Update NetBeans project file for dependency changes since 11th Feb 2020 > --- > > Key: CASSANDRA-16234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16234 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > A number of dependencies have been add/removed/updated to the project. > The netbeans project file needs an update to be in-sync. > Causing tickets: > - CASSANDRA-15677 > - CASSANDRA-16064 > - CASSANDRA-12995 > - CASSANDRA-15867 > - CASSANDRA-12197 > - CASSANDRA-15556 > - CASSANDRA-15868 > - CASSANDRA-16150 > - CASSANDRA-15631 > - CASSANDRA-15851 > - CASSANDRA-16148 > - CASSANDRA-14655 > - CASSANDRA-15867 > - CASSANDRA-15388 > - CASSANDRA-15564 > - CASSANDRA-16127 -- This message was sent by Atlassian Jira (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-16234) Update NetBeans project file for dependency changes since 11th Feb 2020
[ https://issues.apache.org/jira/browse/CASSANDRA-16234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229910#comment-17229910 ] Michael Semb Wever commented on CASSANDRA-16234: [~dotbg], would you be interested in reviewing this? (It's a one-liner.) > Update NetBeans project file for dependency changes since 11th Feb 2020 > --- > > Key: CASSANDRA-16234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16234 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > A number of dependencies have been add/removed/updated to the project. > The netbeans project file needs an update to be in-sync. > Causing tickets: > - CASSANDRA-15677 > - CASSANDRA-16064 > - CASSANDRA-12995 > - CASSANDRA-15867 > - CASSANDRA-12197 > - CASSANDRA-15556 > - CASSANDRA-15868 > - CASSANDRA-16150 > - CASSANDRA-15631 > - CASSANDRA-15851 > - CASSANDRA-16148 > - CASSANDRA-14655 > - CASSANDRA-15867 > - CASSANDRA-15388 > - CASSANDRA-15564 > - CASSANDRA-16127 -- This message was sent by Atlassian Jira (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-16183) Add tests to cover ClientRequest metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16183: -- Status: Ready to Commit (was: Review In Progress) > Add tests to cover ClientRequest metrics > - > > Key: CASSANDRA-16183 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16183 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Benjamin Lerer >Assignee: Adam Holmberg >Priority: Normal > Fix For: 4.0-beta > > > We do not have test that covers the ClientRequest metrics. > * ClientRequestMetrics > * CASClientRequestMetrics > * CASClientWriteRequestMetrics > * ClientWriteRequestMetrics > * ViewWriteMetrics -- This message was sent by Atlassian 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: Add tests to cover ClientRequest metrics
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 9bf0759 Add tests to cover ClientRequest metrics
9bf0759 is described below
commit 9bf07593992c05b537d45254a46cd17cd1ab5316
Author: Adam Holmberg
AuthorDate: Wed Nov 11 11:46:56 2020 +
Add tests to cover ClientRequest metrics
patch by Adam Holmberg; reviewed by Andrés de la Peña for CASSANDRA-16183
---
client_request_metrics_test.py | 787 +
1 file changed, 787 insertions(+)
diff --git a/client_request_metrics_test.py b/client_request_metrics_test.py
new file mode 100644
index 000..6c5ef4d
--- /dev/null
+++ b/client_request_metrics_test.py
@@ -0,0 +1,787 @@
+from abc import ABC, abstractmethod
+from collections import defaultdict
+from functools import partial
+from itertools import repeat
+import pytest
+import time
+
+from dtest import Tester, create_ks
+from tools.jmxutils import (JolokiaAgent, make_mbean)
+
+from cassandra import (ReadFailure, ReadTimeout, Unavailable,
+ WriteFailure, WriteTimeout,
+ ConsistencyLevel as CL)
+from cassandra.concurrent import execute_concurrent_with_args
+from cassandra.marshal import int32_pack
+from cassandra.policies import FallthroughRetryPolicy
+from cassandra.query import SimpleStatement
+
+since = pytest.mark.since
+
+jmx = None
+
+KEYSPACE = 'ks'
+FAIL_WRITE_KEYSPACE = 'fail_keyspace'
+VIEW_KEYSPACE = 'view_keyspace'
+TABLE = 't'
+VIEW = 'mv'
+TOMBSTONE_FAILURE_THRESHOLD = 20
+TOMBSTONE_FAIL_KEY = 1001
+JVM_ARGS = [f"-Dcassandra.test.fail_writes_ks={FAIL_WRITE_KEYSPACE}"]
+
+
+class NoException(BaseException):
+pass
+
+
+@since('4.0')
+class TestClientRequestMetrics(Tester):
+
+@pytest.fixture(autouse=True)
+def fixture_add_additional_log_patterns(self, fixture_dtest_setup):
+fixture_dtest_setup.ignore_log_patterns = (
+'Testing write failures', # The error to simulate a write failure
+'ERROR WRITE_FAILURE', # Logged in DEBUG mode for write failures
+f"Scanned over {TOMBSTONE_FAILURE_THRESHOLD + 1} tombstones during
query" # Caused by the read failure tests
+)
+
+def setup_once(self):
+cluster = self.cluster
+cluster.set_configuration_options({'read_request_timeout_in_ms': 3000,
+ 'write_request_timeout_in_ms': 3000,
+ 'phi_convict_threshold': 12,
+ 'tombstone_failure_threshold':
TOMBSTONE_FAILURE_THRESHOLD,
+ 'enable_materialized_views':
'true'})
+cluster.populate(2, debug=True)
+cluster.start(jvm_args=JVM_ARGS)
+node1 = cluster.nodelist()[0]
+
+global jmx
+jmx = JolokiaAgent(node1)
+jmx.start()
+
+s = self.session = self.patient_exclusive_cql_connection(node1,
retry_policy=FallthroughRetryPolicy(), request_timeout=30)
+for k in [KEYSPACE, FAIL_WRITE_KEYSPACE]:
+create_ks(s, k, 2)
+s.execute(f"CREATE TABLE {k}.{TABLE} (k int, c int, v int, PRIMARY
KEY (k,c))")
+
+create_ks(s, VIEW_KEYSPACE, 1)
+s.execute(f"CREATE TABLE {VIEW_KEYSPACE}.{TABLE} (k int, c int, v int,
PRIMARY KEY (k,c))")
+s.execute(f"CREATE MATERIALIZED VIEW {VIEW_KEYSPACE}.{VIEW} AS SELECT
* FROM {TABLE} WHERE c IS NOT NULL AND k IS NOT NULL PRIMARY KEY (c,k);")
+
+# Here we're doing a series of deletions in order to create enough
tombstones to exceed the configured fail threshold.
+# This partition will be used to test read failures.
+for c in range(TOMBSTONE_FAILURE_THRESHOLD + 1):
+self.session.execute(f"DELETE FROM {KEYSPACE}.{TABLE} WHERE
k={TOMBSTONE_FAIL_KEY} AND c={c}")
+
+node1.watch_log_for("Created default superuser role 'cassandra'") #
don't race with async default role creation, which creates a write
+node1.watch_log_for('Completed submission of build tasks for any
materialized views defined at startup', filename='debug.log') # view builds
cause background reads
+
+def test_client_request_metrics(self):
+# this is written as a single test method in order to reuse the same
cluster for all tests
+# setup_once configures and starts the cluster with all schema and
preconditions required by all tests.
+self.setup_once()
+
+self.write_nominal()
+self.read_nominal()
+
+self.write_failures()
+self.write_unavailables()
+self.write_timeouts()
+
+self.read_failures()
+self.read_unavailables()
+self.read_timeouts()
+
+self.range_slice_failures()
+self.range_slice_unavailables()
+self.ran
[jira] [Commented] (CASSANDRA-16183) Add tests to cover ClientRequest metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229930#comment-17229930
]
Andres de la Peña commented on CASSANDRA-16183:
---
Committed to {{trunk}} as
[9bf07593992c05b537d45254a46cd17cd1ab5316|https://github.com/apache/cassandra-dtest/commit/9bf07593992c05b537d45254a46cd17cd1ab5316].
> Add tests to cover ClientRequest metrics
> -
>
> Key: CASSANDRA-16183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16183
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Benjamin Lerer
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> We do not have test that covers the ClientRequest metrics.
> * ClientRequestMetrics
> * CASClientRequestMetrics
> * CASClientWriteRequestMetrics
> * ClientWriteRequestMetrics
> * ViewWriteMetrics
--
This message was sent by Atlassian Jira
(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-16183) Add tests to cover ClientRequest metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16183: -- Fix Version/s: (was: 4.0-beta) 4.0-beta4 Source Control Link: https://github.com/apache/cassandra-dtest/commit/9bf07593992c05b537d45254a46cd17cd1ab5316 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Add tests to cover ClientRequest metrics > - > > Key: CASSANDRA-16183 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16183 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Benjamin Lerer >Assignee: Adam Holmberg >Priority: Normal > Fix For: 4.0-beta4 > > > We do not have test that covers the ClientRequest metrics. > * ClientRequestMetrics > * CASClientRequestMetrics > * CASClientWriteRequestMetrics > * ClientWriteRequestMetrics > * ViewWriteMetrics -- This message was sent by Atlassian Jira (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-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229937#comment-17229937
]
Tibor Repasi commented on CASSANDRA-16259:
--
Scrubbing the affected table makes histograms work again.
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:276)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardM
[jira] [Commented] (CASSANDRA-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229978#comment-17229978
]
Benjamin Lerer commented on CASSANDRA-16259:
There is effectively a bug in the code
[here|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/metrics/TableMetrics.java#L259]
if an SSTable histogram contains less buckets than the one of a previous
SSTable. The call to {{nextBucket[i];}}
[here|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/metrics/TableMetrics.java#L261]
will trigger an {{ArrayIndexOutOfBoundsException}}.
That code has been wrong since it was introduced in 2014 so the error has been
caused by some change somewhere else in the code base.
I will fix that problem and dug a bit deeper to find out which change made us
hit that issue.
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at s
[jira] [Comment Edited] (CASSANDRA-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229978#comment-17229978
]
Benjamin Lerer edited comment on CASSANDRA-16259 at 11/11/20, 1:20 PM:
---
There is effectively a bug in the code
[here|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/metrics/TableMetrics.java#L259].
If an SSTable histogram contains less buckets than the one of a previous
SSTable, the call to {{nextBucket[i];}}
[here|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/metrics/TableMetrics.java#L261]
will trigger an {{ArrayIndexOutOfBoundsException}}.
That code has been wrong since it was introduced in 2014 so the error has been
caused by some change somewhere else in the code base.
I will fix that problem and dug a bit deeper to find out which change made us
hit that issue.
was (Author: blerer):
There is effectively a bug in the code
[here|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/metrics/TableMetrics.java#L259]
if an SSTable histogram contains less buckets than the one of a previous
SSTable. The call to {{nextBucket[i];}}
[here|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/metrics/TableMetrics.java#L261]
will trigger an {{ArrayIndexOutOfBoundsException}}.
That code has been wrong since it was introduced in 2014 so the error has been
caused by some change somewhere else in the code base.
I will fix that problem and dug a bit deeper to find out which change made us
hit that issue.
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.c
[jira] [Updated] (CASSANDRA-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16259:
---
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Component/s: Observability/Metrics
Discovered By: User Report
Fix Version/s: 4.0-beta
3.11.x
3.0.x
2.2.x
Severity: Normal
Status: Open (was: Triage Needed)
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-beta
>
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.
[jira] [Created] (CASSANDRA-16263) jira-slack bridge test
Drew Foulks created CASSANDRA-16263: --- Summary: jira-slack bridge test Key: CASSANDRA-16263 URL: https://issues.apache.org/jira/browse/CASSANDRA-16263 Project: Cassandra Issue Type: Task Reporter: Drew Foulks Assignee: Drew Foulks -- This message was sent by Atlassian Jira (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-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16237:
--
Reviewers: Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {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-16192) Add more tests to cover compaction metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230014#comment-17230014 ] Mohamed Zafraan commented on CASSANDRA-16192: - That's right. seeing my name added there automatically made me think it was the intended feature. Thanks for clarifying that. > Add more tests to cover compaction metrics > -- > > Key: CASSANDRA-16192 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16192 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Benjamin Lerer >Assignee: Mohamed Zafraan >Priority: Normal > Fix For: 4.0-beta > > Attachments: 0001-added-unit-tests-to-cover-compaction-metrics.patch > > > Some compaction metrics do not seems to be tested. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16263) jira-slack bridge test
[ https://issues.apache.org/jira/browse/CASSANDRA-16263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Drew Foulks updated CASSANDRA-16263: Status: Awaiting Feedback (was: Triage Needed) > jira-slack bridge test > -- > > Key: CASSANDRA-16263 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16263 > Project: Cassandra > Issue Type: Task >Reporter: Drew Foulks >Assignee: Drew Foulks >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-16263) jira-slack bridge test
[ https://issues.apache.org/jira/browse/CASSANDRA-16263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Drew Foulks updated CASSANDRA-16263: Resolution: Fixed Status: Resolved (was: Awaiting Feedback) resolving a test ticket > jira-slack bridge test > -- > > Key: CASSANDRA-16263 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16263 > Project: Cassandra > Issue Type: Task >Reporter: Drew Foulks >Assignee: Drew Foulks >Priority: Normal > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16183) Add tests to cover ClientRequest metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230034#comment-17230034 ] Adam Holmberg commented on CASSANDRA-16183: --- Thanks for the review! > Add tests to cover ClientRequest metrics > - > > Key: CASSANDRA-16183 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16183 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Benjamin Lerer >Assignee: Adam Holmberg >Priority: Normal > Fix For: 4.0-beta4 > > > We do not have test that covers the ClientRequest metrics. > * ClientRequestMetrics > * CASClientRequestMetrics > * CASClientWriteRequestMetrics > * ClientWriteRequestMetrics > * ViewWriteMetrics -- This message was sent by Atlassian Jira (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-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230048#comment-17230048
]
Andres de la Peña commented on CASSANDRA-16237:
---
The patch has survived two runs of in-JVM upgrade tests in ci-cassandra too:
https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-jvm-dtest-upgrade/66/
https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-jvm-dtest-upgrade/67/
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {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-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230066#comment-17230066
]
Caleb Rackliffe commented on CASSANDRA-16237:
-
Second CircleCI run here:
https://app.circleci.com/pipelines/github/maedhroz/cassandra/146/workflows/8e6ad0d8-b432-4874-bf31-a10892be7288
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16097) DigestResolver.getData throws AssertionError since dataResponse is null
[
https://issues.apache.org/jira/browse/CASSANDRA-16097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16097:
-
Assignee: Adam Holmberg (was: Benjamin Lerer)
> DigestResolver.getData throws AssertionError since dataResponse is null
> ---
>
> Key: CASSANDRA-16097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16097
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Was running a benchmark at LOCAL_ONE and eventually saw the below exception
> {code}
> 2020-09-02 21:08:59,872 ERROR [Native-Transport-Requests-35]
> org.apache.cassandra.transport.Message - Unexpected exception during request;
> channel = [id: 0x13bb89d4, L:/10.14.92.74:9042 - R:/10.14.89.248:47112]
> java.lang.AssertionError
>at
> org.apache.cassandra.service.reads.DigestResolver.getData(DigestResolver.java:77)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:390)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1821)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1711)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1628)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1097)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:294)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:246)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:498)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:476)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
>at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {code}
> This exception was not frequent, out of the whole run (3h) only saw this
> twice.
--
This message was sent by Atlassian Jira
(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-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230079#comment-17230079
]
Sam Tunnicliffe commented on CASSANDRA-15299:
-
Something we'll need to do in order to merge this is to update the python
dtests to use a driver which supports the new protocol. Initial support has
been committed, but not yet released, so I propose updating dtests to pull a
specific commit from the driver repo. I thought it should be possible to do
this just by updating {{requirements.txt}} in the dtest repo, but unfortunately
not.
While this does cause the container to pull an updated version, but it only
wipes the source files, not the compiled {{.c}} and {{.so}} objects from the
installation and there are incompatibilities which cause {{ImportError}} when
trying to run the dtests. I spoke to [~eduard.tudenhoefner] about this and
published new docker images with the updated driver installed
([e1fc528a0|https://github.com/datastax/python-driver/commit/e1fc528a0deec67f725f066204e8c1ea8b26bbde]).
Docker images:
*
[beobal/cassandra-testing-ubuntu1910-java11:2020|https://hub.docker.com/layers/beobal/cassandra-testing-ubuntu1910-java11/2020/images/sha256-6c4bdcb82c6b25ec30495f3a49188206fbad99d5c8083217d576a8a84a610bf4?context=repo]
*
[beobal/cassandra-testing-ubuntu1910-java11-w-dependencies:2020|https://hub.docker.com/layers/beobal/cassandra-testing-ubuntu1910-java11-w-dependencies/2020/images/sha256-beda323a6fbba94dc6c2953f5cd5f95d71dfc3dafbd605470ecb0d4282fb0fa8?context=repo]
This works as expected, but there is one failing dtest, which looks to be
related so I'd like to open a follow up JIRA to fix that. One thing that's a
bit concerning is that the {{cassandra-test}} branch of the driver, which is
what dtests are currently using, is currently 693 commits behind the master
branch. But, if there are no objections to updating in this way, I'll open PRs
to {{cassandra-builds}} and {{cassandra-dtest}} before going any further here.
cc: [~mck] [~aboudreault] [~brandon.williams]
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-alpha
>
> Attachments: Process CQL Frame.png, V5 Flow Chart.png
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> particular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
&
[jira] [Updated] (CASSANDRA-15214) OOMs caught and not rethrown
[ https://issues.apache.org/jira/browse/CASSANDRA-15214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15214: Status: Changes Suggested (was: Review In Progress) Left a couple minor comments on GH. Overall the patch looks good. I would like to see test runs for upgrade jvm dtests and the python dtests before merging. > OOMs caught and not rethrown > > > Key: CASSANDRA-15214 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15214 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Benedict Elliott Smith >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0, 4.0-rc > > Attachments: oom-experiments.zip > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, > so presently there is no way to ensure that an OOM reaches the JVM handler to > trigger a crash/heapdump. > It may be that the simplest most consistent way to do this would be to have a > single thread spawned at startup that waits for any exceptions we must > propagate to the Runtime. > We could probably submit a patch upstream to Netty, but for a guaranteed > future proof approach, it may be worth paying the cost of a single thread. -- This message was sent by Atlassian Jira (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-15214) OOMs caught and not rethrown
[ https://issues.apache.org/jira/browse/CASSANDRA-15214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15214: Reviewers: David Capwell, Jordan West (was: David Capwell) > OOMs caught and not rethrown > > > Key: CASSANDRA-15214 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15214 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Benedict Elliott Smith >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0, 4.0-rc > > Attachments: oom-experiments.zip > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, > so presently there is no way to ensure that an OOM reaches the JVM handler to > trigger a crash/heapdump. > It may be that the simplest most consistent way to do this would be to have a > single thread spawned at startup that waits for any exceptions we must > propagate to the Runtime. > We could probably submit a patch upstream to Netty, but for a guaranteed > future proof approach, it may be worth paying the cost of a single thread. -- This message was sent by Atlassian Jira (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-16189) Add tests for the Hint service metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohamed Zafraan updated CASSANDRA-16189: Attachment: 0001-added-hints-metrics-test.patch > Add tests for the Hint service metrics > -- > > Key: CASSANDRA-16189 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16189 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Benjamin Lerer >Assignee: Mohamed Zafraan >Priority: Normal > Fix For: 4.0-beta > > Attachments: 0001-added-hints-metrics-test.patch > > > There are currently no tests for the hint metrics -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16237:
Reviewers: Andres de la Peña, David Capwell (was: Andres de la Peña)
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {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-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230126#comment-17230126
]
Andres de la Peña commented on CASSANDRA-16237:
---
All four CI rounds have succeeded. Changes look good to me.
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {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-13325) Bring back the accepted encryption protocols list as configurable option
[
https://issues.apache.org/jira/browse/CASSANDRA-13325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230158#comment-17230158
]
Jon Meredith commented on CASSANDRA-13325:
--
Branch rebased and updated now that CASSANDRA-16144 is merged. [~dcapwell]
would you be able to take a look?
> Bring back the accepted encryption protocols list as configurable option
>
>
> Key: CASSANDRA-13325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13325
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Nachiket Patil
>Assignee: Jon Meredith
>Priority: Low
> Fix For: 4.x
>
> Attachments: trunk.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> With CASSANDRA-10508, the hard coded list of accepted encryption protocols
> was eliminated. For some use cases, it is necessary to restrict the
> encryption protocols used for communication between client and server.
> Default JVM way of negotiations allows the best encryption protocol that
> client can use.
> e.g. I have set Cassandra to use encryption. Ideally client and server
> negotiate to use best protocol (TLSv1.2). But a malicious client might force
> TLSv1.0 which is susceptible to POODLE attacks.
> At the moment only way to restrict the encryption protocol is using the
> {{jdk.tls.client.protocols}} systems property. If I dont have enough access
> to modify this property, I dont have any way of restricting the encryption
> protocols.
> I am proposing bring back the accepted_protocols property but make it
> configurable. If not specified, let the JVM take care of the TLS negotiations.
--
This message was sent by Atlassian Jira
(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-13325) Bring back the accepted encryption protocols list as configurable option
[
https://issues.apache.org/jira/browse/CASSANDRA-13325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-13325:
-
Fix Version/s: (was: 4.x)
4.0-beta
> Bring back the accepted encryption protocols list as configurable option
>
>
> Key: CASSANDRA-13325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13325
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Nachiket Patil
>Assignee: Jon Meredith
>Priority: Low
> Fix For: 4.0-beta
>
> Attachments: trunk.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> With CASSANDRA-10508, the hard coded list of accepted encryption protocols
> was eliminated. For some use cases, it is necessary to restrict the
> encryption protocols used for communication between client and server.
> Default JVM way of negotiations allows the best encryption protocol that
> client can use.
> e.g. I have set Cassandra to use encryption. Ideally client and server
> negotiate to use best protocol (TLSv1.2). But a malicious client might force
> TLSv1.0 which is susceptible to POODLE attacks.
> At the moment only way to restrict the encryption protocol is using the
> {{jdk.tls.client.protocols}} systems property. If I dont have enough access
> to modify this property, I dont have any way of restricting the encryption
> protocols.
> I am proposing bring back the accepted_protocols property but make it
> configurable. If not specified, let the JVM take care of the TLS negotiations.
--
This message was sent by Atlassian Jira
(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-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230171#comment-17230171
]
David Capwell commented on CASSANDRA-16237:
---
+1
The patch is a clean refactor and should speed up CI runs; though sad we need
this refactor =/
I did leave a few comments about COMPACT STORAGE, but since this patch isn't
dealing with that I think its fine to punt to the patch adding COMPACT STORAGE
back (CASSANDRA-16217 [~ifesdjeen]).
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {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-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230172#comment-17230172
]
David Capwell commented on CASSANDRA-16237:
---
bq. Changes look good to me
[~adelapena] if this is your +1 then I can start the commit.
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {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-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230174#comment-17230174
]
Andres de la Peña commented on CASSANDRA-16237:
---
[~dcapwell] that is my +1.
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230177#comment-17230177 ] Caleb Rackliffe commented on CASSANDRA-16262: - Note: See CASSANDRA-16213 for an example of bootstrapping and host replacement with gossip enabled in an in-JVM test. > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, and > decommission. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16237:
--
Status: Ready to Commit (was: Review In Progress)
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {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-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230180#comment-17230180
]
David Capwell commented on CASSANDRA-16237:
---
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16237-trunk-7BBC8F6D-B889-4C4D-A616-D16740C06C01]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16237-trunk-7BBC8F6D-B889-4C4D-A616-D16740C06C01]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/191/]|
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {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-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230180#comment-17230180
]
David Capwell edited comment on CASSANDRA-16237 at 11/11/20, 8:00 PM:
--
Starting commit
CI Results: Yellow; known issues, and
`org.apache.cassandra.distributed.test.RepairTest` which had a timeout (calling
this as unrelated)
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16237-trunk-7BBC8F6D-B889-4C4D-A616-D16740C06C01]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16237-trunk-7BBC8F6D-B889-4C4D-A616-D16740C06C01]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/191/]|
was (Author: dcapwell):
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16237-trunk-7BBC8F6D-B889-4C4D-A616-D16740C06C01]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16237-trunk-7BBC8F6D-B889-4C4D-A616-D16740C06C01]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/191/]|
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new f88cd88 Fix flaky test mixedModeReadRepairUpdate -
org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
f88cd88 is described below
commit f88cd88419604dbe6f93389a7898d387f20bbf43
Author: Caleb Rackliffe
AuthorDate: Wed Nov 11 11:31:30 2020 -0800
Fix flaky test mixedModeReadRepairUpdate -
org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
patch by Caleb Rackliffe; reviewed by Andres de la Peña, David Capwell for
CASSANDRA-16237
---
.../upgrade/MixedModeReadRepairDeleteTest.java | 113 +++
.../upgrade/MixedModeReadRepairTest.java | 224 -
.../upgrade/MixedModeReadRepairWriteTest.java | 103 ++
.../ReadRepairCompactStorageUpgradeTest.java | 59 ++
.../distributed/upgrade/UpgradeTestBase.java | 10 +
5 files changed, 285 insertions(+), 224 deletions(-)
diff --git
a/test/distributed/org/apache/cassandra/distributed/upgrade/MixedModeReadRepairDeleteTest.java
b/test/distributed/org/apache/cassandra/distributed/upgrade/MixedModeReadRepairDeleteTest.java
new file mode 100644
index 000..01955c5
--- /dev/null
+++
b/test/distributed/org/apache/cassandra/distributed/upgrade/MixedModeReadRepairDeleteTest.java
@@ -0,0 +1,113 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.distributed.upgrade;
+
+import org.junit.Test;
+
+import org.apache.cassandra.distributed.api.ConsistencyLevel;
+
+import static org.apache.cassandra.distributed.shared.AssertUtils.assertRows;
+import static org.apache.cassandra.distributed.shared.AssertUtils.row;
+
+/**
+ * Test read repair after partial deletions when the cluster nodes are on
different versions.
+ *
+ * This test and {@link MixedModeReadRepairWriteTest} are separated to avoid
OOM errors in CI (see CASSANDRA-16237).
+ */
+public class MixedModeReadRepairDeleteTest extends UpgradeTestBase
+{
+/**
+ * Test that queries repair rows that exist in both replicas but have been
deleted only in one replica.
+ * The row deletion can be either in the upgraded or in the not-upgraded
node.
+ */
+@Test
+public void mixedModeReadRepairDeleteRow() throws Throwable
+{
+// rows for columns (k, c, v, s)
+Object[] row1 = row(0, 1, 10, 8);
+Object[] row2 = row(0, 2, 20, 8);
+
+allUpgrades(2, 1)
+.setup(cluster -> {
+cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int, c
int, v int, s int static, PRIMARY KEY (k, c))"));
+
+// insert the rows in all the nodes
+String insert = withKeyspace("INSERT INTO %s.t (k, c, v, s) VALUES
(?, ?, ?, ?)");
+cluster.coordinator(1).execute(insert, ConsistencyLevel.ALL, row1);
+cluster.coordinator(2).execute(insert, ConsistencyLevel.ALL, row2);
+})
+.runAfterClusterUpgrade(cluster -> {
+
+// internally delete one row per replica
+String delete = withKeyspace("DELETE FROM %s.t WHERE k=? AND c=?");
+cluster.get(1).executeInternal(delete, 0, 1);
+cluster.get(2).executeInternal(delete, 0, 2);
+
+// query to trigger read repair
+String query = withKeyspace("SELECT k, c, v, s FROM %s.t");
+assertRows(cluster.get(1).executeInternal(query), row2);
+assertRows(cluster.get(2).executeInternal(query), row1);
+Object[] emptyPartition = row(0, null, null, 8);
+assertRows(cluster.coordinator(2).execute(query,
ConsistencyLevel.ALL), emptyPartition);
+assertRows(cluster.get(1).executeInternal(query), emptyPartition);
+assertRows(cluster.get(2).executeInternal(query), emptyPartition);
+})
+.run();
+}
+
+/**
+ * Test that queries repair partitions that exist in both replicas but
have been deleted only in one replica.
+ * The partition deletion can be either in the upgraded or in the
not-upgrade
[jira] [Comment Edited] (CASSANDRA-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230180#comment-17230180
]
David Capwell edited comment on CASSANDRA-16237 at 11/11/20, 8:49 PM:
--
CI Results: Yellow; known issues, and
`org.apache.cassandra.distributed.test.RepairTest` which had a timeout (calling
this as unrelated)
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16237-trunk-7BBC8F6D-B889-4C4D-A616-D16740C06C01]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16237-trunk-7BBC8F6D-B889-4C4D-A616-D16740C06C01]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/191/]|
was (Author: dcapwell):
Starting commit
CI Results: Yellow; known issues, and
`org.apache.cassandra.distributed.test.RepairTest` which had a timeout (calling
this as unrelated)
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16237-trunk-7BBC8F6D-B889-4C4D-A616-D16740C06C01]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16237-trunk-7BBC8F6D-B889-4C4D-A616-D16740C06C01]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/191/]|
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {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-16237) Fix flaky test mixedModeReadRepairUpdate - org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16237:
--
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/4d5b68cfd8609b5a03a5966c4e5a2a76f2c5c872
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix flaky test mixedModeReadRepairUpdate -
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairTest
> ---
>
> Key: CASSANDRA-16237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16237
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4233]
>
> {code}
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:514)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:101)
> at
> org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:87)
> at
> org.apache.cassandra.net.OutboundConnections$UnusedConnectionMonitor.(OutboundConnections.java:265)
> at
> org.apache.cassandra.net.OutboundConnections.scheduleUnusedConnectionMonitoring(OutboundConnections.java:312)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:262)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:226)
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:231)
> at
> org.apache.cassandra.distributed.impl.Instance.registerMockMessaging(Instance.java:253)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:466)
> at
> org.apache.cassandra.distributed.impl.Instance$$Lambda$16500/806573706.run(Unknown
> Source)
> {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-15214) OOMs caught and not rethrown
[ https://issues.apache.org/jira/browse/CASSANDRA-15214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230243#comment-17230243 ] Yifan Cai commented on CASSANDRA-15214: --- Thanks [~jwest]. Addressed you comments and run CI (unit, jvm dtest and dtest) after rebasing. There are a few test failures, but do not look related to the change. CI result: https://app.circleci.com/pipelines/github/yifan-c/cassandra/159/workflows/a37b8a85-b705-479e-b7ca-846bb71b36dc > OOMs caught and not rethrown > > > Key: CASSANDRA-15214 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15214 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Benedict Elliott Smith >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0, 4.0-rc > > Attachments: oom-experiments.zip > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, > so presently there is no way to ensure that an OOM reaches the JVM handler to > trigger a crash/heapdump. > It may be that the simplest most consistent way to do this would be to have a > single thread spawned at startup that waits for any exceptions we must > propagate to the Runtime. > We could probably submit a patch upstream to Netty, but for a guaranteed > future proof approach, it may be worth paying the cost of a single thread. -- This message was sent by Atlassian Jira (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-16097) DigestResolver.getData throws AssertionError since dataResponse is null
[
https://issues.apache.org/jira/browse/CASSANDRA-16097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230247#comment-17230247
]
Adam Holmberg commented on CASSANDRA-16097:
---
I have a method of reproducing this 100%. Sharing a minimal dtest script for
repro in case anyone else is looking into it.
https://github.com/apache/cassandra-dtest/commit/ca57b258779d1d78adb95f5efa861ac9f36769d4
Haven't gotten to the bottom of it yet.
> DigestResolver.getData throws AssertionError since dataResponse is null
> ---
>
> Key: CASSANDRA-16097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16097
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Was running a benchmark at LOCAL_ONE and eventually saw the below exception
> {code}
> 2020-09-02 21:08:59,872 ERROR [Native-Transport-Requests-35]
> org.apache.cassandra.transport.Message - Unexpected exception during request;
> channel = [id: 0x13bb89d4, L:/10.14.92.74:9042 - R:/10.14.89.248:47112]
> java.lang.AssertionError
>at
> org.apache.cassandra.service.reads.DigestResolver.getData(DigestResolver.java:77)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:390)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1821)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1711)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1628)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1097)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:294)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:246)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:498)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:476)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
>at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {code}
> This exception was not frequent, out of the whole run (3h) only saw this
> twice.
--
This message was sent by Atlassian Jira
(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-16264) During rolling upgrade from C* 2.0.0 to 2.1.0, upgraded node fails to gossip with seed
Yongle Zhang created CASSANDRA-16264:
Summary: During rolling upgrade from C* 2.0.0 to 2.1.0, upgraded
node fails to gossip with seed
Key: CASSANDRA-16264
URL: https://issues.apache.org/jira/browse/CASSANDRA-16264
Project: Cassandra
Issue Type: Bug
Reporter: Yongle Zhang
Steps to reproduce:
# Start a 2-node C* 2.0.0 cluster with one seed
# upgrade the non-seed node to 2.1.0
Error stacktrace on upgraded node:
{code:java}
ERROR [main] 2020-07-22 08:12:53,406 CassandraDaemon.java:474 - Exception
encountered during startup
java.lang.RuntimeException: Unable to gossip with any seeds
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:451)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:667)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:615)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:509)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:338)
[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
[apache-cassandra-2.1.0.jar:2.1.0]
{code}
Analysis:
When a 2.1.0 node tries to make a connection with a 2.0.0 node, the 2.0.0 node
will send an integer representing its version. After receiving this integer,
the 2.1.0 node will compare it to the guessed version, and will update the
guessed version and shutdown the connection if it is older than the guessed
version, then it will make a second trial to connect to the 2.0.0 node.
--
This message was sent by Atlassian Jira
(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-16264) During rolling upgrade from C* 2.0.0 to 2.1.0, upgraded node fails to gossip with seed
[
https://issues.apache.org/jira/browse/CASSANDRA-16264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yongle Zhang updated CASSANDRA-16264:
-
Description:
Steps to reproduce:
# Start a 2-node C* 2.0.0 cluster with one seed
# upgrade the non-seed node to 2.1.0
Error stacktrace on upgraded node:
{code:java}
ERROR [main] 2020-07-22 08:12:53,406 CassandraDaemon.java:474 - Exception
encountered during startup
java.lang.RuntimeException: Unable to gossip with any seeds
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:451)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:667)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:615)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:509)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:338)
[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
[apache-cassandra-2.1.0.jar:2.1.0]
{code}
Analysis:
When a 2.1.0 node tries to make a connection with a 2.0.0 node, the 2.0.0 node
will send an integer representing its version. After receiving this integer,
the 2.1.0 node will compare it to the guessed version, and will update the
guessed version and shutdown the connection if it is older than the guessed
version, then it will make a second trial to connect to the 2.0.0 node.
However, the 2.1.0 node somehow got stuck at
https://github.com/apache/cassandra/blob/c6a2c65a75adea9a62896269da98dd036c8e57f3/src/java/org/apache/cassandra/net/OutboundTcpConnection.java#L138
and was never able to make the second connection trial. And thus the failure.
was:
Steps to reproduce:
# Start a 2-node C* 2.0.0 cluster with one seed
# upgrade the non-seed node to 2.1.0
Error stacktrace on upgraded node:
{code:java}
ERROR [main] 2020-07-22 08:12:53,406 CassandraDaemon.java:474 - Exception
encountered during startup
java.lang.RuntimeException: Unable to gossip with any seeds
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:451)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:667)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:615)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:509)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:338)
[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
[apache-cassandra-2.1.0.jar:2.1.0]
{code}
Analysis:
When a 2.1.0 node tries to make a connection with a 2.0.0 node, the 2.0.0 node
will send an integer representing its version. After receiving this integer,
the 2.1.0 node will compare it to the guessed version, and will update the
guessed version and shutdown the connection if it is older than the guessed
version, then it will make a second trial to connect to the 2.0.0 node.
> During rolling upgrade from C* 2.0.0 to 2.1.0, upgraded node fails to gossip
> with seed
> --
>
> Key: CASSANDRA-16264
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16264
> Project: Cassandra
> Issue Type: Bug
>Reporter: Yongle Zhang
>Priority: Normal
>
> Steps to reproduce:
> # Start a 2-node C* 2.0.0 cluster with one seed
> # upgrade the non-seed node to 2.1.0
> Error stacktrace on upgraded node:
>
> {code:java}
> ERROR [main] 2020-07-22 08:12:53,406 CassandraDaemon.java:474 - Exception
> encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:451)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.service.
[jira] [Created] (CASSANDRA-16265) During rolling upgrade from C* 2.0.0 to 2.1.0, upgraded node fails with IllegalArgumentException
Yongle Zhang created CASSANDRA-16265:
Summary: During rolling upgrade from C* 2.0.0 to 2.1.0, upgraded
node fails with IllegalArgumentException
Key: CASSANDRA-16265
URL: https://issues.apache.org/jira/browse/CASSANDRA-16265
Project: Cassandra
Issue Type: Bug
Reporter: Yongle Zhang
Steps to reproduce:
# start a 2-node C* 2.0.0 cluster with 1 seed.
# upgrade the non-seed node to 2.1.0
# run stress testing using /tools/bin/stress on two nodes, wait or it to
finish.
Error stack trace:
{code:java}
java.lang.IllegalArgumentException: No enum constant
org.apache.cassandra.config.CFMetaData.Caching.{"keys":"ALL",
"rows_per_partition":"NONE"}
at java.lang.Enum.valueOf(Enum.java:238)
at org.apache.cassandra.config.CFMetaData$Caching.valueOf(CFMetaData.java:261)
at
org.apache.cassandra.config.CFMetaData.fromSchemaNoColumnsNoTriggers(CFMetaData.java:1567)
at org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1642)
at
org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:312)
at org.apache.cassandra.db.DefsTables.mergeColumnFamilies(DefsTables.java:309)
at org.apache.cassandra.db.DefsTables.mergeSchema(DefsTables.java:184)
at
org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:67)
at
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:46)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:57)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
Root cause: Incompatible data
In 2.0.0 `CFMetaData.Caching` is an enum of 4 possible values. It is serialized
and deserialized using the Java builtin methods `valueOf` and `toString` for
enum class. See
[https://github.com/apache/cassandra/blob/03045ca22b11b0e5fc85c4fabd83ce6121b5709b/src/java/org/apache/cassandra/config/CFMetaData.java#L1567]
(ser) and
[https://github.com/apache/cassandra/blob/03045ca22b11b0e5fc85c4fabd83ce6121b5709b/src/java/org/apache/cassandra/config/CFMetaData.java#L1524]
(de).
In 2.1.0, `CachingOptions` is a class consisting of 2 fields. It is serialized
and deserialized using a textual form similar to JSON (e.g. the string
\{"keys":"ALL", "rows_per_partition":"NONE"} in the above log). See
[https://github.com/apache/cassandra/blob/c6a2c65a75adea9a62896269da98dd036c8e57f3/src/java/org/apache/cassandra/cache/CachingOptions.java#L95]
(ser) and
[https://github.com/apache/cassandra/blob/c6a2c65a75adea9a62896269da98dd036c8e57f3/src/java/org/apache/cassandra/cache/CachingOptions.java#L50]
(de).
Note that in 2.1.0 it will first check whether the input string is one of the 4
possible values in the old version, and will return a predefined constant for
these values, so it is compatible with the old versions. Unfortunately the old
versions have no idea about how to deserialize the string from the new versions.
--
This message was sent by Atlassian Jira
(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-16266) Stress testing a mixed cluster with C* 2.1.0 (seed) and 2.0.0 causes NPE
Yongle Zhang created CASSANDRA-16266:
Summary: Stress testing a mixed cluster with C* 2.1.0 (seed) and
2.0.0 causes NPE
Key: CASSANDRA-16266
URL: https://issues.apache.org/jira/browse/CASSANDRA-16266
Project: Cassandra
Issue Type: Bug
Reporter: Yongle Zhang
Steps to reproduce:
# setup a mixed cluster with C* 2.1.0 (seed node) and C* 2.0.0
# run the stress testing tool, e.g.,
{code:java}
/cassandra/tools/bin/cassandra-stress write n=1000 -rate threads=50 -node
250.16.238.1,250.16.238.2{code}
NPE:
{code:java}
ERROR [InternalResponseStage:2] 2020-07-22 08:29:36,170 CassandraDaemon.java
(line 186) Exception in thread Thread[InternalResponseStage:2,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:33)
at
org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:24)
at org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:142)
at
org.apache.cassandra.cql3.UntypedResultSet$Row.getBoolean(UntypedResultSet.java:106)
at
org.apache.cassandra.config.CFMetaData.fromSchemaNoColumnsNoTriggers(CFMetaData.java:1555)
at org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1642)
at
org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:305)
at org.apache.cassandra.db.DefsTables.mergeColumnFamilies(DefsTables.java:270)
at org.apache.cassandra.db.DefsTables.mergeSchema(DefsTables.java:183)
at
org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:66)
at
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:46)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
Root cause: incompatible data
In the `CFMetaData` class of version 2.0.0, there is a boolean field named
`replicate_on_write`. In the same class of version 2.1.0, however, this field
no longer exists. When serializing this class in function
`toSchemaNoColumnsNoTriggers`, it will first write all of its fields into a
`RowMutation` (in 2.0.0) / `Mutation` (in 2.1.0) class, and then serialize this
“Mutation” like class in the same way. In 2.0.0 the `replicate_on_write` field
gets serialized at
[https://github.com/apache/cassandra/blob/03045ca22b11b0e5fc85c4fabd83ce6121b5709b/src/java/org/apache/cassandra/config/CFMetaData.java#L1514]
.
When deserializing this class in function `fromSchemaNoColumnsNoTriggers`, it
reads all its fields from a map-like class `UntypedResultSet.Row`. In 2.0.0 the
`replicate_on_write` field gets deserialized at
[https://github.com/apache/cassandra/blob/03045ca22b11b0e5fc85c4fabd83ce6121b5709b/src/java/org/apache/cassandra/config/CFMetaData.java#L1555]
.
The problem is that the existence of the key is not checked, and the map
returns a `null` value because the message from 2.1.0 doesn’t contain the
`replicate_on_write` key, which leads to the NullPointerException.
--
This message was sent by Atlassian Jira
(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-16106) BufferOverflow exception while writing response to buffer
[
https://issues.apache.org/jira/browse/CASSANDRA-16106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230277#comment-17230277
]
Jon Meredith commented on CASSANDRA-16106:
--
Could this have been caused by CASSANDRA-16103?
> BufferOverflow exception while writing response to buffer
> -
>
> Key: CASSANDRA-16106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16106
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Was running a benchmark at LOCAL_ONE and eventually saw the below exception;
> this is related to CASSANDRA-16097 as it was found during the same test.
> {code}
> message="...SMALL_MESSAGES-1bb47c27 dropping message of type HINT_RSP due to
> error"
> exception="java.nio.BufferOverflowException
> at
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:153)
> at
> org.apache.cassandra.utils.vint.VIntCoding.writeUnsignedVInt(VIntCoding.java:191)
> at
> org.apache.cassandra.io.util.DataOutputPlus.writeUnsignedVInt(DataOutputPlus.java:55)
> at
> org.apache.cassandra.net.Message$Serializer.serializeHeaderPost40(Message.java:688)
> at
> org.apache.cassandra.net.Message$Serializer.serializePost40(Message.java:758)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:618)
> at
> org.apache.cassandra.net.OutboundConnection$EventLoopDelivery.doRun(OutboundConnection.java:813)
> at
> org.apache.cassandra.net.OutboundConnection$Delivery.run(OutboundConnection.java:687)
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)"
> {code}
> {code}
> message="...-SMALL_MESSAGES-e72423f4 dropping message of type MUTATION_RSP
> due to error"
> exception="java.nio.BufferOverflowException
> at
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:153)
> at
> org.apache.cassandra.utils.vint.VIntCoding.writeUnsignedVInt(VIntCoding.java:191)
> at
> org.apache.cassandra.io.util.DataOutputPlus.writeUnsignedVInt(DataOutputPlus.java:55)
> at
> org.apache.cassandra.net.Message$Serializer.serializeParams(Message.java:1112)
> at
> org.apache.cassandra.net.Message$Serializer.serializeHeaderPost40(Message.java:689)
> at
> org.apache.cassandra.net.Message$Serializer.serializePost40(Message.java:758)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:618)
> at
> org.apache.cassandra.net.OutboundConnection$EventLoopDelivery.doRun(OutboundConnection.java:813)
> at
> org.apache.cassandra.net.OutboundConnection$Delivery.run(OutboundConnection.java:687)
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16267) Adding a C* 1.2.0 node to a C* 1.1.0 cluster fails with connection failure
Yongle Zhang created CASSANDRA-16267:
Summary: Adding a C* 1.2.0 node to a C* 1.1.0 cluster fails with
connection failure
Key: CASSANDRA-16267
URL: https://issues.apache.org/jira/browse/CASSANDRA-16267
Project: Cassandra
Issue Type: Bug
Reporter: Yongle Zhang
Steps to reproduce:
# start a 2-node C* 1.1.0 cluster
# add a new C* 1.2.0 node
Error:
{code:java}
ERROR [main] 2020-06-18 01:12:12,894 CassandraDaemon.java (line 414) Exception
encountered during startup
java.lang.RuntimeException: No other nodes seen! Unable to bootstrap.If you
intended to start a single-node cluster, you should make sure your
broadcast_address (or listen_address) is listed as a seed. Otherwise, you need
to determine why the seed being contacted has no knowledge of the rest of the
cluster. Usually, this can be solved by giving all nodes the same seed list.
at
org.apache.cassandra.dht.BootStrapper.getBootstrapSource(BootStrapper.java:154)
at
org.apache.cassandra.dht.BootStrapper.getBalancedToken(BootStrapper.java:135)
at
org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:115)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:611)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:499)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:397)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:309)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:397)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:440)
ERROR [StorageServiceShutdownHook] 2020-06-18 01:12:12,898 CassandraDaemon.java
(line 133) Exception in thread Thread[StorageServiceShutdownHook,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.service.StorageService.stopRPCServer(StorageService.java:307)
at
org.apache.cassandra.service.StorageService$1.runMayThrow(StorageService.java:464)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.lang.Thread.run(Thread.java:748)
{code}
Root cause:
In 1.2.0, when a node wants to connect another node, it will expect to read a
int from it. See
https://github.com/apache/cassandra/blob/cassandra-1.2.0/src/java/org/apache/cassandra/net/OutboundTcpConnection.java#L276
.
There *seems* to exist a check (line 269 in the same file) about the target
version before trying to read int. It is based on variable `targetVersion`,
which is from
`MessagingService.instance().getVersion(poolReference.endPoint())`. This
function, however, returns the version of itself when the end point is unknown.
Also the target node will send this int if it is also running 1.2.0. See
https://github.com/apache/cassandra/blob/cassandra-1.2.0/src/java/org/apache/cassandra/net/IncomingTcpConnection.java#L90
.
However, in 1.1.0, there is no such mechanism, the 1.1.0 node won't send this
int. So when a 1.2.0 node tries to connect to a 1.1.0 node, it will stuck at
"readInt".
--
This message was sent by Atlassian Jira
(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-15897) Dropping compact storage with 2.1-sstables on disk make them unreadable
[ https://issues.apache.org/jira/browse/CASSANDRA-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230282#comment-17230282 ] Jon Meredith commented on CASSANDRA-15897: -- [~ifesdjeen] does CASSANDRA-16217 resolve the concerns in this ticket? > Dropping compact storage with 2.1-sstables on disk make them unreadable > --- > > Key: CASSANDRA-15897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15897 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Marcus Eriksson >Assignee: Sylvain Lebresne >Priority: Normal > Fix For: 3.0.x, 4.0-beta > > > Test reproducing: > https://github.com/krummas/cassandra/commits/marcuse/dropcompactstorage -- This message was sent by Atlassian Jira (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-16097) DigestResolver.getData throws AssertionError since dataResponse is null
[
https://issues.apache.org/jira/browse/CASSANDRA-16097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230289#comment-17230289
]
Adam Holmberg commented on CASSANDRA-16097:
---
I see what's happening. It has to do with error handling when there is an
occasional race with speculative execution. Should be straightforward to fix.
> DigestResolver.getData throws AssertionError since dataResponse is null
> ---
>
> Key: CASSANDRA-16097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16097
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Was running a benchmark at LOCAL_ONE and eventually saw the below exception
> {code}
> 2020-09-02 21:08:59,872 ERROR [Native-Transport-Requests-35]
> org.apache.cassandra.transport.Message - Unexpected exception during request;
> channel = [id: 0x13bb89d4, L:/10.14.92.74:9042 - R:/10.14.89.248:47112]
> java.lang.AssertionError
>at
> org.apache.cassandra.service.reads.DigestResolver.getData(DigestResolver.java:77)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:390)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1821)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1711)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1628)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1097)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:294)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:246)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:498)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:476)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
>at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {code}
> This exception was not frequent, out of the whole run (3h) only saw this
> twice.
--
This message was sent by Atlassian Jira
(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-16212) Cassandra version above 3.11.0 failing for ARM64
[ https://issues.apache.org/jira/browse/CASSANDRA-16212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Cole updated CASSANDRA-16212: Attachment: crash.txt > Cassandra version above 3.11.0 failing for ARM64 > - > > Key: CASSANDRA-16212 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16212 > Project: Cassandra > Issue Type: Task >Reporter: odidev >Priority: Normal > Attachments: crash.txt > > > Cassandra versions above 3.11.0 are failing on ARM64 platform with below > issue: > java.lang.UnsatisfiedLinkError: /tmp/jna-3506402/jna3214742498288082263.tmp: > *Error loading shared library ld-linux-aarch64.so.1: No such file or > directory (needed by /tmp/jna-3506402/jna3214742498288082263.tmp)* -- This message was sent by Atlassian Jira (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-16212) Cassandra version above 3.11.0 failing for ARM64
[
https://issues.apache.org/jira/browse/CASSANDRA-16212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230292#comment-17230292
]
Adrian Cole commented on CASSANDRA-16212:
-
The crash looks like it is happening here, which is also present in trunk
(cassandra 4)
```java
Native.register(com.sun.jna.NativeLibrary.getInstance("c",
Collections.emptyMap()));
```
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/NativeLibraryLinux.java#L55
added in 4 here
https://github.com/apache/cassandra/commit/d5005627b02b4e716947fa05a40473368017c0f9
merged into cassandra 3.11.4 here
https://github.com/apache/cassandra/commit/459945bcf4f029f068199cae1418dd3bc2fc01ce
[^crash.txt]
> Cassandra version above 3.11.0 failing for ARM64
> -
>
> Key: CASSANDRA-16212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16212
> Project: Cassandra
> Issue Type: Task
>Reporter: odidev
>Priority: Normal
> Attachments: crash.txt
>
>
> Cassandra versions above 3.11.0 are failing on ARM64 platform with below
> issue:
> java.lang.UnsatisfiedLinkError: /tmp/jna-3506402/jna3214742498288082263.tmp:
> *Error loading shared library ld-linux-aarch64.so.1: No such file or
> directory (needed by /tmp/jna-3506402/jna3214742498288082263.tmp)*
--
This message was sent by Atlassian Jira
(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-16212) Cassandra version above 3.11.0 failing for ARM64
[ https://issues.apache.org/jira/browse/CASSANDRA-16212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230297#comment-17230297 ] Adrian Cole commented on CASSANDRA-16212: - Locally, upgrading cassandra's 3.11.9's jna avoided the crash. Will test a bit more before raising a PR + + net.java.dev.jna + jna + 5.6.0 + > Cassandra version above 3.11.0 failing for ARM64 > - > > Key: CASSANDRA-16212 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16212 > Project: Cassandra > Issue Type: Task >Reporter: odidev >Priority: Normal > Attachments: crash.txt > > > Cassandra versions above 3.11.0 are failing on ARM64 platform with below > issue: > java.lang.UnsatisfiedLinkError: /tmp/jna-3506402/jna3214742498288082263.tmp: > *Error loading shared library ld-linux-aarch64.so.1: No such file or > directory (needed by /tmp/jna-3506402/jna3214742498288082263.tmp)* -- This message was sent by Atlassian Jira (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-16181) 4.0 Quality: Replication Test Audit
[ https://issues.apache.org/jira/browse/CASSANDRA-16181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16181: Description: This is a subtask of CASSANDRA-15579 focusing on replication. I think that the main reference dtest for this is [replication_test.py|https://github.com/apache/cassandra-dtest/blob/master/replication_test.py]. We should identify which other tests cover this and identify what should be extended, similarly to what has been done with CASSANDRA-15977. The (WIP) doc [here|https://docs.google.com/document/d/1yPbquhAALIkkTRMmyOv5cceD5N5sPFMB1O4iOd3O7FM/edit?usp=sharing] describes the existing state of testing around replication. was: This is a subtask of CASSANDRA-15579 focusing on replication. I think that the main reference dtest for this is [replication_test.py|https://github.com/apache/cassandra-dtest/blob/master/replication_test.py]. We should identify which other tests cover this and identify what should be extended, similarly to what has been done with CASSANDRA-15977. > 4.0 Quality: Replication Test Audit > --- > > Key: CASSANDRA-16181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16181 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Andres de la Peña >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0 > > > This is a subtask of CASSANDRA-15579 focusing on replication. > I think that the main reference dtest for this is > [replication_test.py|https://github.com/apache/cassandra-dtest/blob/master/replication_test.py]. > We should identify which other tests cover this and identify what should be > extended, similarly to what has been done with CASSANDRA-15977. > The (WIP) doc > [here|https://docs.google.com/document/d/1yPbquhAALIkkTRMmyOv5cceD5N5sPFMB1O4iOd3O7FM/edit?usp=sharing] > describes the existing state of testing around replication. -- This message was sent by Atlassian Jira (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-11978) StreamReader fails to write sstable if CF directory is symlink
[ https://issues.apache.org/jira/browse/CASSANDRA-11978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk True reassigned CASSANDRA-11978: - Assignee: (was: Kirk True) > StreamReader fails to write sstable if CF directory is symlink > -- > > Key: CASSANDRA-11978 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11978 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Michael Frisch >Priority: Normal > Labels: lhf > > I'm using Cassandra v2.2.6. If the CF is stored as a symlink in the keyspace > directory on disk then StreamReader.createWriter fails because > Descriptor.fromFilename is passed the actual path on disk instead of path > with the symlink. > Example: > /path/to/data/dir/Keyspace/CFName -> /path/to/data/dir/AnotherDisk/CFName > Descriptor.fromFilename is passed "/path/to/data/dir/AnotherDisk/CFName" > instead of "/path/to/data/dir/Keyspace/CFName", then it concludes that the > keyspace name is "AnotherDisk" which is erroneous. I've temporarily worked > around this by using cfs.keyspace.getName() to get the keyspace name and > cfs.name to get the CF name as those are correct. -- This message was sent by Atlassian Jira (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-16095) Nodetool tablestats WriteLatency error
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230317#comment-17230317
]
David Capwell commented on CASSANDRA-16095:
---
I have seen this as well with server running JVM 11 and nodetool JVM 11, the
issue went away on restart.
I took a dump of the metrics and saw that the tables had the MBeans registered,
but not TableMetrics (though some tables had both).
> Nodetool tablestats WriteLatency error
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
>Reporter: Altan Özlü
>Priority: Normal
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
This message was sent by Atlassian Jira
(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-16095) Nodetool tablestats WriteLatency error
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230317#comment-17230317
]
David Capwell edited comment on CASSANDRA-16095 at 11/12/20, 1:21 AM:
--
I have seen this as well with server running JVM 11 and nodetool JVM 11, the
issue went away on restart.
I took a dump of the metrics and saw that the tables had the MBeans registered,
but not TableMetrics (though some tables had both).
I am trying to figure out how this happened and will reopen if I make any
progress.
was (Author: dcapwell):
I have seen this as well with server running JVM 11 and nodetool JVM 11, the
issue went away on restart.
I took a dump of the metrics and saw that the tables had the MBeans registered,
but not TableMetrics (though some tables had both).
> Nodetool tablestats WriteLatency error
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
>Reporter: Altan Özlü
>Priority: Normal
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
This message was sent by Atlassian Jira
(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-16268) Rolling upgrade from 1.1.0 to 1.2.0 runs into IllegalArgumentException because of Invalid UUID
Yongle Zhang created CASSANDRA-16268:
Summary: Rolling upgrade from 1.1.0 to 1.2.0 runs into
IllegalArgumentException because of Invalid UUID
Key: CASSANDRA-16268
URL: https://issues.apache.org/jira/browse/CASSANDRA-16268
Project: Cassandra
Issue Type: Bug
Reporter: Yongle Zhang
Steps to reproduce:
# setup a 2-node C* 1.1.0 cluster
# upgrade the non-seed node to 1.2.0
# run stress testing tool on the 1.1.0 node, e.g.,
`/cassandra/tools/bin/stress -d 250.16.238.1 -r`
Error logs:
{code:java}
DEBUG [WRITE-/250.16.238.3] 2020-06-18 02:10:51,087 OutboundTcpConnection.java
(line 165) error writing to /250.16.238.3
java.net.SocketException: Broken pipe (Write failed)
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at java.io.DataOutputStream.flush(DataOutputStream.java:123)
at
org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:156)
at
org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:126)
DEBUG [Thrift:1] 2020-07-11 22:32:56,017 CassandraServer.java (line 962)
add_keyspace
DEBUG [WRITE-/250.16.238.2] 2020-07-11 22:32:56,024 OutboundTcpConnection.java
(line 229) attempting to connect to /250.16.238.2
DEBUG [MigrationStage:1] 2020-07-11 22:32:56,039 SchemaCheckVerbHandler.java
(line 36) Received schema check request.
DEBUG [InternalResponseStage:9] 2020-07-11 22:32:56,047
ResponseVerbHandler.java (line 44) Processing response on a callback from
380@/250.16.238.1
DEBUG [InternalResponseStage:9] 2020-07-11 22:32:56,048 StorageProxy.java (line
955) Received schema check response from 250.16.238.1
DEBUG [InternalResponseStage:10] 2020-07-11 22:32:56,049
ResponseVerbHandler.java (line 44) Processing response on a callback from
381@/250.16.238.2
DEBUG [InternalResponseStage:10] 2020-07-11 22:32:56,050 StorageProxy.java
(line 955) Received schema check response from 250.16.238.2
ERROR [InternalResponseStage:10] 2020-07-11 22:32:56,053
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[InternalResponseStage:10,5,main]
java.lang.IllegalArgumentException: Invalid UUID string: Y��N��>^B��[9X'E?
at java.util.UUID.fromString(UUID.java:194)
at org.apache.cassandra.service.StorageProxy$8.response(StorageProxy.java:956)
at
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:45)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
Root cause analysis: data format incompatibility
In 1.2.0, when the payload of `MessageOut` is `UUID`, it will write two long
integers to serialize the payload, representing the most significant 8 bytes
and the least significant 8 bytes of this `UUID`. See
[https://github.com/apache/cassandra/blob/69337a43670f71ae1fc55e23d6a9031230423900/src/java/org/apache/cassandra/utils/UUIDSerializer.java#L36].
In 1.1.0, it will read a String from the payload, and call `UUID.fromString` to
obtain the `UUID`. Since the string representation is different from the msb +
lsb 16 bytes representation, here we get the format mismatch. See
[https://github.com/apache/cassandra/blob/c671532825b9e05bd2b50e3aa2d1c5f5156d1c9f/src/java/org/apache/cassandra/service/StorageProxy.java#L956].
--
This message was sent by Atlassian Jira
(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-16269) Stress testing a mixed cluster with C* 1.2.0 (seed) and 1.1.0 fails with NumberFormatException
Yongle Zhang created CASSANDRA-16269:
Summary: Stress testing a mixed cluster with C* 1.2.0 (seed) and
1.1.0 fails with NumberFormatException
Key: CASSANDRA-16269
URL: https://issues.apache.org/jira/browse/CASSANDRA-16269
Project: Cassandra
Issue Type: Bug
Reporter: Yongle Zhang
Steps to reproduce:
# Set up a mixed 1.1.0 & 1.2.0 cluster with 2 nodes (1 seed, 1.2.0 node being
the seed).
# Run the stress testing tool, e.g., `/cassandra/tools/bin/stress -d
250.16.238.1,250.16.238.2 -r`, wait for finish.
Error log:
{code:java}
DEBUG [WRITE-/250.16.238.1] 2020-06-18 01:55:09,606 OutboundTcpConnection.java
(line 229) attempting to connect to /250.16.238.1
DEBUG [InternalResponseStage:1] 2020-06-18 01:55:09,613
ResponseVerbHandler.java (line 44) Processing response on a callback from
122@/250.16.238.1
ERROR [InternalResponseStage:1] 2020-06-18 01:55:09,615
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[InternalResponseStage:1,5,main]
java.lang.NumberFormatException: For input string: "'115"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:569)
at java.math.BigInteger.(BigInteger.java:470)
at java.math.BigInteger.(BigInteger.java:606)
at
org.apache.cassandra.dht.RandomPartitioner$1.fromString(RandomPartitioner.java:136)
at
org.apache.cassandra.dht.BootStrapper$BootstrapTokenCallback.response(BootStrapper.java:213)
at
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:45)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
DEBUG [InternalResponseStage:2] 2020-06-18 01:55:39,610
ResponseVerbHandler.java (line 44) Processing response on a callback from
262@/250.16.238.1
ERROR [InternalResponseStage:2] 2020-06-18 01:55:39,611
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[InternalResponseStage:2,5,main]
java.lang.NumberFormatException: For input string: "^@'115"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:569)
at java.math.BigInteger.(BigInteger.java:470)
at java.math.BigInteger.(BigInteger.java:606)
at
org.apache.cassandra.dht.RandomPartitioner$1.fromString(RandomPartitioner.java:136)
at
org.apache.cassandra.dht.BootStrapper$BootstrapTokenCallback.response(BootStrapper.java:213)
at
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:45)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)ERROR [main] 2020-06-18 01:57:39,614
AbstractCassandraDaemon.java (line 370) Exception encountered during startup
java.lang.RuntimeException: Bootstrap failed, could not obtain token from:
/250.16.238.1
at
org.apache.cassandra.dht.BootStrapper.getBootstrapTokenFrom(BootStrapper.java:177)
at
org.apache.cassandra.dht.BootStrapper.getBalancedToken(BootStrapper.java:110)
at
org.apache.cassandra.dht.BootStrapper.getBootstrapToken(BootStrapper.java:104)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:599)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:515)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:407)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:231)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106)
ERROR [main] 2020-06-18 01:58:13,206 AbstractCassandraDaemon.java (line 370)
Exception encountered during startup
java.lang.RuntimeException: No other nodes seen! Unable to bootstrap.If you
intended to start a single-node cluster, you should make sure your
broadcast_address (or listen_address) is listed as a seed. Otherwise, you need
to determine why the seed being contacted has no knowledge of the rest of the
cluster. Usually, this can be solved by giving all nodes the same seed list.
at
org.apache.cassandra.dht.BootStrapper.getBootstrapSource(BootStrapper.java:127)
at
org.apache.cassandra.dht.BootStrapper.getBalancedToken(BootStrapper.java:109)
at
org.apache.cassandra.dht.BootStrapper.getBootstrapToken(BootStrapper.java:104)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:599)
at
org.apache
[jira] [Commented] (CASSANDRA-16189) Add tests for the Hint service metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230361#comment-17230361 ] Mohamed Zafraan commented on CASSANDRA-16189: - test: test_hintedhandoff_metrics is added > Add tests for the Hint service metrics > -- > > Key: CASSANDRA-16189 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16189 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Benjamin Lerer >Assignee: Mohamed Zafraan >Priority: Normal > Fix For: 4.0-beta > > Attachments: 0001-added-hints-metrics-test.patch > > > There are currently no tests for the hint metrics -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16013) sstablescrub unit test hardening an docs improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16013:
Labels: (was: low-hanging-fruit)
> sstablescrub unit test hardening an docs improvements
> -
>
> Key: CASSANDRA-16013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16013
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> During CASSANDRA-15883 / CASSANDRA-15991 it was detected unit test coverage
> for this tool is minimal. There is a unit test to enhance upon under
> {{test/unit/org/apache/cassandra/tools}}. Also docs need updating to reflect
> the latest options available.
--
This message was sent by Atlassian Jira
(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-15583) 4.0 quality testing: Tooling, Bundled and First Party
[
https://issues.apache.org/jira/browse/CASSANDRA-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15583:
Reviewers: Sam Tunnicliffe (was: scott hendrickson, Vinay Chella)
> 4.0 quality testing: Tooling, Bundled and First Party
> -
>
> Key: CASSANDRA-15583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15583
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python, Test/unit
>Reporter: Josh McKenzie
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Reference [doc from
> NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#]
> for context.
> *Shepherd: Sam Tunnicliffe*
> Test plans should cover bundled first-party tooling and CLIs such as
> nodetool, cqlsh, and new tools supporting full query and audit logging
> (CASSANDRA-13983, CASSANDRA-12151).
> *Progress as of Aug 2020*
> {{ToolRunner}} has been added enabling us to test tools in java unit tests.
> This includes capturing their stdout/err and stdin i.e. Most tools have a
> starting unit test testing their cmd line args happy path. Tickets have been
> created to improve coverage of those and flagged LHF. Also for those tools
> big enough they can't be addressed in a simple ticket such as nodetool, a
> placeholder ticket for future improvements has been created as well. Tickets
> and status are:
> ||Tool||UX test||UT coverage||dtest coverage||Comments||
> |Nodetool|(x)|(x) CASSANDRA-16026|(!)|Not all the sub commands are tested.
> Dtest also test nodetool as a side effect|
> |Cqlsh|(x)|(x) CASSANDRA-16025|(!)| |
> |Cassandra-stress|(x)|(x) CASSANDRA-16024|(x)| |
> |debug-cql|(x)|(x) CASSANDRA-16023|(x)| |
> |fqltool|(x)|(/) CASSANDRA-16022|(!)| |
> |auditlogviewer|(/) CASSANDRA-15991|(!) CASSANDRA-16021|(!)| |
> |*Sstable utilities*| | | | |
> |sstabledump|(/) CASSANDRA-15991|(/) CASSANDRA-16020|(!)| |
> |sstableexpiredblockers|(/) CASSANDRA-15991|(x) CASSANDRA-16019|(!)| |
> |sstablelevelreset|(/) CASSANDRA-15991|(x) CASSANDRA-16018|(!)| |
> |sstableloader|(x)|(x) CASSANDRA-16017|(!)| |
> |sstablemetadata|(/) CASSANDRA-15991|(x) CASSANDRA-16016|(x)|Ran in dtests,
> no dedicated test|
> |sstableofflinerelevel|(/) CASSANDRA-15991|(x) CASSANDRA-16015|(!)| |
> |sstablerepairedset|(/) CASSANDRA-15991|(x) CASSANDRA-16014|(x)|Ran in
> dtests, no dedicated test|
> |sstablescrub|(/) CASSANDRA-15991|(x) CASSANDRA-16013|(!)| |
> |sstablesplit|(/) CASSANDRA-15991|(x) CASSANDRA-16012|(!)| |
> |sstableupgrade|(/) CASSANDRA-15991|(x) CASSANDRA-16011|(!)| |
> |sstableutil|(/) CASSANDRA-15991|(x) CASSANDRA-16010|(!)| |
> |sstableverify|(/) CASSANDRA-15991|(x) CASSANDRA-16009|(!)| |
--
This message was sent by Atlassian Jira
(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-16097) DigestResolver.getData throws AssertionError since dataResponse is null
[
https://issues.apache.org/jira/browse/CASSANDRA-16097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230364#comment-17230364
]
Berenguer Blasi commented on CASSANDRA-16097:
-
[~aholmber] I was wondering if this is related to CASSANDRA-16106 and both can
be folded in the same ticket in your opinion?
> DigestResolver.getData throws AssertionError since dataResponse is null
> ---
>
> Key: CASSANDRA-16097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16097
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Was running a benchmark at LOCAL_ONE and eventually saw the below exception
> {code}
> 2020-09-02 21:08:59,872 ERROR [Native-Transport-Requests-35]
> org.apache.cassandra.transport.Message - Unexpected exception during request;
> channel = [id: 0x13bb89d4, L:/10.14.92.74:9042 - R:/10.14.89.248:47112]
> java.lang.AssertionError
>at
> org.apache.cassandra.service.reads.DigestResolver.getData(DigestResolver.java:77)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:390)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1821)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1711)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1628)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1097)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:294)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:246)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:498)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:476)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
>at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {code}
> This exception was not frequent, out of the whole run (3h) only saw this
> twice.
--
This message was sent by Atlassian Jira
(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-16159) Reduce the Severity of Errors Reported in FailureDetector#isAlive()
[
https://issues.apache.org/jira/browse/CASSANDRA-16159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohamed Zafraan reassigned CASSANDRA-16159:
---
Assignee: Mohamed Zafraan (was: Shubham Arora)
> Reduce the Severity of Errors Reported in FailureDetector#isAlive()
> ---
>
> Key: CASSANDRA-16159
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16159
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Caleb Rackliffe
>Assignee: Mohamed Zafraan
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Noticed the following error in the failure detector during a host replacement:
> {noformat}
> java.lang.IllegalArgumentException: Unknown endpoint: 10.38.178.98:7000
> at
> org.apache.cassandra.gms.FailureDetector.isAlive(FailureDetector.java:281)
> at
> org.apache.cassandra.service.StorageService.handleStateBootreplacing(StorageService.java:2502)
> at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:2182)
> at
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:3145)
> at
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1242)
> at
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1368)
> at
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:50)
> at
> org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:77)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:93)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:44)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:884)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> {noformat}
> This particular error looks benign, given that even if it occurs, the node
> continues to handle the {{BOOT_REPLACE}} state. There are two things we might
> be able to do to improve {{FailureDetector#isAlive()}} though:
> 1.) We don’t short circuit in the case that the endpoint in question is in
> quarantine after being removed. It may be useful to check for this so we can
> avoid logging an ERROR when the endpoint is clearly doomed/dead. (Quarantine
> works great when the gossip message is _from_ a quarantined endpoint, but in
> this case, that would be the new/replacing and not the old/replaced one.)
> 2.) We can reduce the severity of the logging from ERROR to WARN and provide
> better context around how to determine whether or not there’s actually a
> problem. (ex. “If this occurs while trying to determine liveness for a node
> that is currently being replaced, it can be safely ignored.”)
--
This message was sent by Atlassian Jira
(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-16254) Make sure OOM errors are rethrown on truncation failure
[ https://issues.apache.org/jira/browse/CASSANDRA-16254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230373#comment-17230373 ] Berenguer Blasi commented on CASSANDRA-16254: - Left a couple comments in commit #justfyi > Make sure OOM errors are rethrown on truncation failure > --- > > Key: CASSANDRA-16254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16254 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta4 > > > Seems we don't rethrow OOM errors in [truncation verb > handler|https://github.com/apache/cassandra/blob/609876275738589fdfb9a3e20cb2f594aa404037/src/java/org/apache/cassandra/db/TruncateVerbHandler.java#L44] > We also send both success and failure messages if the failure reason is not > an FSError -- This message was sent by Atlassian Jira (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-16254) Make sure OOM errors are rethrown on truncation failure
[ https://issues.apache.org/jira/browse/CASSANDRA-16254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16254: Reviewers: Berenguer Blasi, Berenguer Blasi (was: Berenguer Blasi) Berenguer Blasi, Berenguer Blasi Status: Review In Progress (was: Patch Available) > Make sure OOM errors are rethrown on truncation failure > --- > > Key: CASSANDRA-16254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16254 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta4 > > > Seems we don't rethrow OOM errors in [truncation verb > handler|https://github.com/apache/cassandra/blob/609876275738589fdfb9a3e20cb2f594aa404037/src/java/org/apache/cassandra/db/TruncateVerbHandler.java#L44] > We also send both success and failure messages if the failure reason is not > an FSError -- This message was sent by Atlassian Jira (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-16212) Cassandra version above 3.11.0 failing for ARM64
[ https://issues.apache.org/jira/browse/CASSANDRA-16212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230384#comment-17230384 ] Adrian Cole commented on CASSANDRA-16212: - this fixes it in Zipkin as our integration tests now pass with arm running AWS Graviton2 Cassandra cc [~mck] [~llinder] > Cassandra version above 3.11.0 failing for ARM64 > - > > Key: CASSANDRA-16212 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16212 > Project: Cassandra > Issue Type: Task >Reporter: odidev >Priority: Normal > Attachments: crash.txt > > > Cassandra versions above 3.11.0 are failing on ARM64 platform with below > issue: > java.lang.UnsatisfiedLinkError: /tmp/jna-3506402/jna3214742498288082263.tmp: > *Error loading shared library ld-linux-aarch64.so.1: No such file or > directory (needed by /tmp/jna-3506402/jna3214742498288082263.tmp)* -- This message was sent by Atlassian Jira (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-16191) Add tests for Repair metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yasar Arafath Baigh reassigned CASSANDRA-16191:
---
Assignee: Yasar Arafath Baigh
> Add tests for Repair metrics
>
>
> Key: CASSANDRA-16191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16191
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Benjamin Lerer
>Assignee: Yasar Arafath Baigh
>Priority: Normal
> Fix For: 4.0-beta
>
>
> We do not seems to have some tests for the {{RepairMetrics.previewFailures}}
> counter.
--
This message was sent by Atlassian Jira
(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-16212) Cassandra version above 3.11.0 failing for ARM64
[ https://issues.apache.org/jira/browse/CASSANDRA-16212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever reassigned CASSANDRA-16212: -- Assignee: Michael Semb Wever > Cassandra version above 3.11.0 failing for ARM64 > - > > Key: CASSANDRA-16212 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16212 > Project: Cassandra > Issue Type: Task >Reporter: odidev >Assignee: Michael Semb Wever >Priority: Normal > Attachments: crash.txt > > > Cassandra versions above 3.11.0 are failing on ARM64 platform with below > issue: > java.lang.UnsatisfiedLinkError: /tmp/jna-3506402/jna3214742498288082263.tmp: > *Error loading shared library ld-linux-aarch64.so.1: No such file or > directory (needed by /tmp/jna-3506402/jna3214742498288082263.tmp)* -- This message was sent by Atlassian Jira (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-16212) Cassandra version above 3.11.0 failing for ARM64
[ https://issues.apache.org/jira/browse/CASSANDRA-16212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16212: --- Platform: ARM (was: All) > Cassandra version above 3.11.0 failing for ARM64 > - > > Key: CASSANDRA-16212 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16212 > Project: Cassandra > Issue Type: Task >Reporter: odidev >Assignee: Michael Semb Wever >Priority: Normal > Attachments: crash.txt > > > Cassandra versions above 3.11.0 are failing on ARM64 platform with below > issue: > java.lang.UnsatisfiedLinkError: /tmp/jna-3506402/jna3214742498288082263.tmp: > *Error loading shared library ld-linux-aarch64.so.1: No such file or > directory (needed by /tmp/jna-3506402/jna3214742498288082263.tmp)* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
