[jira] [Commented] (CASSANDRA-16121) Circleci should run cqlshlib tests as well
[
https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201281#comment-17201281
]
Berenguer Blasi commented on CASSANDRA-16121:
-
Replied in GH. LGTM it's just {{diff}} 'noise' making things hard to follow
iiuc what you meant.
> Circleci should run cqlshlib tests as well
> --
>
> Key: CASSANDRA-16121
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16121
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Currently circleci is not running cqlshlib tests. This resulted in some bugs
> not being caught before committing.
--
This message was sent by Atlassian Jira
(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-16127) NullPointerException when calling nodetool enablethrift
[
https://issues.apache.org/jira/browse/CASSANDRA-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201264#comment-17201264
]
Yifan Cai commented on CASSANDRA-16127:
---
dtest has [2
failures|https://app.circleci.com/pipelines/github/dcapwell/cassandra/566/workflows/05b20cbd-2312-4b36-a869-9207f26c6811/jobs/3101]
that looks related to the patch.
> NullPointerException when calling nodetool enablethrift
> ---
>
> Key: CASSANDRA-16127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16127
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Thrift
>Reporter: Tibor Repasi
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> Having thrift disabled, it's impossible to enable it again without restarting
> the node:
> {code}
> $ nodetool statusthrift
> not running
> $ nodetool enablethrift
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.startRPCServer(StorageService.java:392)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> 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}
--
This message was sent by Atlassian Jira
(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-15457) Remove bad assert when getting active compactions for an sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-15457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201263#comment-17201263 ] Yifan Cai commented on CASSANDRA-15457: --- Need a second eye? > Remove bad assert when getting active compactions for an sstable > > > Key: CASSANDRA-15457 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15457 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > CASSANDRA-14935 added a check that an sstable can only be in a single > 'compaction', this is wrong. An sstable can be in a validation and a normal > compaction at the same time for example. -- This message was sent by Atlassian Jira (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] (CASSANDRASC-27) CDC reader in Apache Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201261#comment-17201261 ] maxwellguo commented on CASSANDRASC-27: --- [~vinaykumarcse] [~tharanga] the googel is updated, any other thoughts? > CDC reader in Apache Cassandra Sidecar > -- > > Key: CASSANDRASC-27 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-27 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature >Reporter: Vinay Chella >Assignee: Tharanga Sampath Gamaethige >Priority: Normal > > Apache Cassandra has the CDC (Change Data Capture) features since 3.8. This > is further enhanced with (CASS-12148) in Cassandra 4.0. > However, there’s no generally available mechanism to stream changes out of a > Cassandra database; hence the utility of this feature is limited if not > absent. > Many applications use Cassandra as their primary data store. For various > reasons(Caching, analyzing, indexing, etc), this data needs to be > synchronized with derived/secondary data stores. We would like to emit > change streams in real-time to consumers so that changes to Cassandra can be > used for various purposes. > *Goals* > * Enhance Apache Cassandra sidecar with a CDC reader that can read and emit > changes in real-time. Priority for the initial implementation is safety and > correctness, performance enhancements will follow in subsequent iterations > *Nongoals* > * Modify Cassandra storage engine to emit changes > > *Proposal* > https://docs.google.com/document/d/11YywfJTm29szZOVOSRbtfvClbmMQtJ8WyCB7_CUgo-U/edit?usp=sharing > -- This message was sent by Atlassian Jira (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-16134) Fix architecture docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201251#comment-17201251 ] Lorina Poland commented on CASSANDRA-16134: --- Please be aware that there is a major effort going on to convert the docs to Asciidoc. A lot of editing is also being done as part of that effort. > Fix architecture docs > - > > Key: CASSANDRA-16134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16134 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Fábio Takeo Ueno >Assignee: Fábio Takeo Ueno >Priority: Normal > > There are minor issues like formatting and punctuation in docs about > architecture. -- This message was sent by Atlassian Jira (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-16134) Fix architecture docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201251#comment-17201251 ] Lorina Poland edited comment on CASSANDRA-16134 at 9/24/20, 3:58 AM: - Please be aware that there is a major effort going on to convert the docs to Asciidoc. A lot of editing is also being done as part of that effort. https://issues.apache.org/jira/browse/CASSANDRA-16029 was (Author: polandll): Please be aware that there is a major effort going on to convert the docs to Asciidoc. A lot of editing is also being done as part of that effort. > Fix architecture docs > - > > Key: CASSANDRA-16134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16134 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Fábio Takeo Ueno >Assignee: Fábio Takeo Ueno >Priority: Normal > > There are minor issues like formatting and punctuation in docs about > architecture. -- This message was sent by Atlassian Jira (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-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16116: -- Status: Ready to Commit (was: Review In Progress) > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Fix For: 4.0-beta > > Time Spent: 40m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian Jira (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-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201246#comment-17201246 ] Chris Lohfink commented on CASSANDRA-16116: --- Committed thanks! > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Fix For: 4.0-beta > > Time Spent: 40m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian Jira (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-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16116: -- Source Control Link: https://github.com/apache/cassandra/commit/e973344305ed2cd5821ccf51cfeb1481010ef18b Resolution: Fixed Status: Resolved (was: Ready to Commit) > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Fix For: 4.0-beta > > Time Spent: 40m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian 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: Emit a metric for mutations that are too large
This is an automated email from the ASF dual-hosted git repository.
clohfink 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 e973344 Emit a metric for mutations that are too large
e973344 is described below
commit e973344305ed2cd5821ccf51cfeb1481010ef18b
Author: Lee Tang
AuthorDate: Wed Sep 23 22:34:33 2020 -0500
Emit a metric for mutations that are too large
Patch by Lee Tang; Reviewed by Chris Lohfink, Jordan West for
CASSANDRA-16116
---
doc/source/operating/metrics.rst | 1 +
src/java/org/apache/cassandra/db/Mutation.java| 2 ++
src/java/org/apache/cassandra/db/commitlog/CommitLog.java | 2 +-
src/java/org/apache/cassandra/metrics/CommitLogMetrics.java | 4
.../unit/org/apache/cassandra/db/commitlog/CommitLogTest.java | 11 ++-
5 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/doc/source/operating/metrics.rst b/doc/source/operating/metrics.rst
index 3c9cc7d..2cabfd5 100644
--- a/doc/source/operating/metrics.rst
+++ b/doc/source/operating/metrics.rst
@@ -514,6 +514,7 @@ PendingTasks GaugeNumber of commit
log messages written
TotalCommitLogSize GaugeCurrent size, in bytes, used by all
the commit log segments.
WaitingOnSegmentAllocation Timer Time spent waiting for a
CommitLogSegment to be allocated - under normal conditions this should be zero.
WaitingOnCommitTimer The time spent waiting on CL fsync;
for Periodic this is only occurs when the sync is lagging its sync interval.
+OverSizedMutations Meter Throughput for mutations that exceed
limit.
== == ===
Storage Metrics
diff --git a/src/java/org/apache/cassandra/db/Mutation.java
b/src/java/org/apache/cassandra/db/Mutation.java
index 16d20db..0b64620 100644
--- a/src/java/org/apache/cassandra/db/Mutation.java
+++ b/src/java/org/apache/cassandra/db/Mutation.java
@@ -28,6 +28,7 @@ import com.google.common.collect.ImmutableMap;
import org.apache.commons.lang3.StringUtils;
import org.apache.cassandra.config.DatabaseDescriptor;
+import org.apache.cassandra.db.commitlog.CommitLog;
import org.apache.cassandra.db.partitions.PartitionUpdate;
import org.apache.cassandra.db.rows.DeserializationHelper;
import org.apache.cassandra.io.IVersionedSerializer;
@@ -127,6 +128,7 @@ public class Mutation implements IMutation
long totalSize = serializedSize(version) + overhead;
if(totalSize > MAX_MUTATION_SIZE)
{
+CommitLog.instance.metrics.oversizedMutations.mark();
throw new MutationExceededMaxSizeException(this, version,
totalSize);
}
}
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
index e7f8743..14b1a3a 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
@@ -67,7 +67,7 @@ public class CommitLog implements CommitLogMBean
final public AbstractCommitLogSegmentManager segmentManager;
public final CommitLogArchiver archiver;
-final CommitLogMetrics metrics;
+public final CommitLogMetrics metrics;
final AbstractCommitLogService executor;
volatile Configuration configuration;
diff --git a/src/java/org/apache/cassandra/metrics/CommitLogMetrics.java
b/src/java/org/apache/cassandra/metrics/CommitLogMetrics.java
index 08c1c8e..a3302bc 100644
--- a/src/java/org/apache/cassandra/metrics/CommitLogMetrics.java
+++ b/src/java/org/apache/cassandra/metrics/CommitLogMetrics.java
@@ -18,6 +18,7 @@
package org.apache.cassandra.metrics;
import com.codahale.metrics.Gauge;
+import com.codahale.metrics.Meter;
import com.codahale.metrics.Timer;
import org.apache.cassandra.db.commitlog.AbstractCommitLogService;
import org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager;
@@ -41,11 +42,14 @@ public class CommitLogMetrics
public final Timer waitingOnSegmentAllocation;
/** The time spent waiting on CL sync; for Periodic this is only occurs
when the sync is lagging its sync interval */
public final Timer waitingOnCommit;
+/** Number and rate of oversized mutations */
+public final Meter oversizedMutations;
public CommitLogMetrics()
{
waitingOnSegmentAllocation =
Metrics.timer(factory.createMetricName("WaitingOnSegmentAllocation"));
waitingOnCommit =
Metrics.timer(factory.createMetricName("WaitingOnCommit"));
+oversizedMutations =
Metrics.meter(factory.createMetricName("OverSizedMutations"));
}
public void attach(final AbstractCommitLogService service, final
AbstractCommitLogSegmentManager segmentManager)
diff --git a/test/unit/org/apache/cassandra/db/commitlog/CommitLogTest.java
[jira] [Commented] (CASSANDRA-16074) Add metric for client concurrent byte throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201199#comment-17201199 ] David Capwell commented on CASSANDRA-16074: --- Overall the patch LGTM, only remaining comment is https://github.com/apache/cassandra/pull/719#discussion_r493986775; can you run the tests in a loop with lower resources to make sure it is stable? > Add metric for client concurrent byte throttle > -- > > Key: CASSANDRA-16074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16074 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client, Observability/Metrics >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > > Add a metric to expose the current bytes and bytes per ip used that is used > in the existing throttle so its possible to determine what to set it to. -- This message was sent by Atlassian Jira (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-16068) SSL connection to storage port when internode encryption is disabled still try to load keystore
[
https://issues.apache.org/jira/browse/CASSANDRA-16068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-16068:
-
Resolution: Fixed
Status: Resolved (was: Triage Needed)
Apologies, forgot I already filed this one. Closing this one against
CASSANDRA-16144 as that has my plan for resolving.
> SSL connection to storage port when internode encryption is disabled still
> try to load keystore
> ---
>
> Key: CASSANDRA-16068
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16068
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Jon Meredith
>Priority: Normal
>
> Starting a 4.0 cluster with internode encryption disabled can throw an
> exception if the keystore is not present after CASSANDRA-15262.
> Part of {{cassandra.yaml}}, the keystore is optional and it just defaults to
> {{conf/.keystore}}
> {code}
> server_encryption_options:
> internode_encryption: none
> keystore: conf/.keystore
> keystore_password: cassandra
> truststore: conf/.truststore
> truststore_password: cassandra
> {code}
> Start the service and try to connect with openssl
> {code}
> $ openssl s_client -connect 127.0.0.1:7000
> CONNECTED(0003)
> 4790519404:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake
> failure:ssl_pkt.c:585:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 0 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol : TLSv1.2
> Cipher:
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> Start Time: 1597969961
> Timeout : 7200 (sec)
> Verify return code: 0 (ok)
> ---
> {code}
> Which triggers an ERROR message with exception
> {code}
> ERROR [Messaging-EventLoop-3-1] 2020-08-20 18:34:52,855
> InboundConnectionInitiator.java:355 - Failed to properly handshake with peer
> /127.0.0.1:61851. Closing the channel.
> io.netty.handler.codec.DecoderException: java.io.IOException: failed to build
> trust manager store for secure connections
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
> 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)
> Caused by: java.io.IOException: failed to build trust manager store for
> secure connections
> at
> org.apache.cassandra.security.SSLFactory.buildKeyManagerFactory(SSLFactory.java:232)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:300)
> at
> org.apache.cassandra.security.SSLFactory.getOrCreateSslContext(SSLFactory.java:276)
> at
> org.apache.cassandra.security.SSLFactory.getOrCreateSslContext(SSLFactory.java:257)
> at
> org.apache.cassandra.net.InboundConnectionInitiator$OptionalSslHandler.decode(InboundConnectionInitiator.java:492)
> at
>
[jira] [Commented] (CASSANDRA-15160) Add flag to ignore unreplicated keyspaces during repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201182#comment-17201182
]
David Capwell commented on CASSANDRA-15160:
---
Overall LGTM +1.
I would need to look closer to make sure the python dtest change doesn't break
2.2, '(, ignore unreplicated keyspaces: (?Ptrue|false))?' I think
this should be ignored if not present, so should be fine?
> Add flag to ignore unreplicated keyspaces during repair
> ---
>
> Key: CASSANDRA-15160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15160
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> When a repair is triggered on a node in 'dc2' for a keyspace with replication
> factor {'dc1':3, 'dc2':0} we just ignore the repair in versions < 3. In 3.0+
> we fail the repair to make sure the operator does not think the keyspace is
> fully repaired.
> There might be tooling that relies on the old behaviour though, so we should
> add a flag to ignore those unreplicated keyspaces
>
--
This message was sent by Atlassian Jira
(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-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16116: -- Fix Version/s: 4.0-beta > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Fix For: 4.0-beta > > Time Spent: 40m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian Jira (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-16127) NullPointerException when calling nodetool enablethrift
[
https://issues.apache.org/jira/browse/CASSANDRA-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201171#comment-17201171
]
Yifan Cai commented on CASSANDRA-16127:
---
+1 on the 3.11 patch.
(One unit test failure in the 3.11 CI. but not related)
Now looking at the dtest patch.
> NullPointerException when calling nodetool enablethrift
> ---
>
> Key: CASSANDRA-16127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16127
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Thrift
>Reporter: Tibor Repasi
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> Having thrift disabled, it's impossible to enable it again without restarting
> the node:
> {code}
> $ nodetool statusthrift
> not running
> $ nodetool enablethrift
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.startRPCServer(StorageService.java:392)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> 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}
--
This message was sent by Atlassian Jira
(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-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201149#comment-17201149 ] Ekaterina Dimitrova commented on CASSANDRA-16121: - Thanks [~Bereng], I left some small comments on github, maybe during squash something went wrong with the patch files. Please check them. Thanks > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- This message was sent by Atlassian Jira (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-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-16116: Reviewers: Chris Lohfink, Jordan West, Jordan West (was: Chris Lohfink, Jordan West) Chris Lohfink, Jordan West, Jordan West (was: Chris Lohfink) Status: Review In Progress (was: Patch Available) +1 > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Time Spent: 40m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian Jira (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-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-16116: Test and Documentation Plan: Unit test added. Metrics docs added. Status: Patch Available (was: Open) > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Time Spent: 40m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian Jira (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-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201112#comment-17201112 ] Chris Lohfink commented on CASSANDRA-15164: --- Committed, thanks > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (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-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15164: -- Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra/commit/4782fd399d97be551032576c4d77f079e862fdba Resolution: Fixed Status: Resolved (was: Ready to Commit) > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (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-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15164: -- Reviewers: Benjamin Lerer, Chris Lohfink, Chris Lohfink (was: Benjamin Lerer, Chris Lohfink) Benjamin Lerer, Chris Lohfink, Chris Lohfink (was: Benjamin Lerer, Chris Lohfink) Status: Review In Progress (was: Patch Available) > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (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-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15164: -- Status: Ready to Commit (was: Review In Progress) > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Avoid failing compactions with very large partitions
This is an automated email from the ASF dual-hosted git repository.
clohfink 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 4782fd3 Avoid failing compactions with very large partitions
4782fd3 is described below
commit 4782fd399d97be551032576c4d77f079e862fdba
Author: Caleb Rackliffe
AuthorDate: Wed Sep 23 16:28:47 2020 -0500
Avoid failing compactions with very large partitions
Patch by Caleb Rackliffe; Reviewed by Chris Lohfink and Benjamin Lerer for
CASSANDRA-15164
---
CHANGES.txt| 1 +
.../io/sstable/metadata/MetadataCollector.java | 4 +--
.../io/sstable/metadata/StatsMetadata.java | 31 +++---
.../apache/cassandra/utils/EstimatedHistogram.java | 31 +++---
.../sstable/metadata/MetadataSerializerTest.java | 27 +++
.../cassandra/utils/EstimatedHistogramTest.java| 12 +
.../apache/cassandra/utils/SerializationsTest.java | 2 +-
7 files changed, 99 insertions(+), 9 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 42b7aa7..1db3ebc 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-beta3
+ * Avoid failing compactions with very large partitions (CASSANDRA-15164)
* Prevent NPE in StreamMessage in type lookup (CASSANDRA-16131)
* Avoid invalid state transition exception during incremental repair
(CASSANDRA-16067)
* Allow zero padding in timestamp serialization (CASSANDRA-16105)
diff --git
a/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java
b/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java
index 570ede7..65d534e 100755
--- a/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java
+++ b/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java
@@ -53,8 +53,8 @@ public class MetadataCollector implements
PartitionStatisticsCollector
static EstimatedHistogram defaultCellPerPartitionCountHistogram()
{
-// EH of 114 can track a max value of 2395318855, i.e., > 2B columns
-return new EstimatedHistogram(114);
+// EH of 118 can track a max value of 4139110981, i.e., > 4B cells
+return new EstimatedHistogram(118);
}
static EstimatedHistogram defaultPartitionSizeHistogram()
diff --git
a/src/java/org/apache/cassandra/io/sstable/metadata/StatsMetadata.java
b/src/java/org/apache/cassandra/io/sstable/metadata/StatsMetadata.java
index f4e5beb..e985f40 100755
--- a/src/java/org/apache/cassandra/io/sstable/metadata/StatsMetadata.java
+++ b/src/java/org/apache/cassandra/io/sstable/metadata/StatsMetadata.java
@@ -23,14 +23,17 @@ import java.util.ArrayList;
import java.util.List;
import java.util.UUID;
-import org.apache.cassandra.db.rows.EncodingStats;
-import org.apache.cassandra.io.ISerializer;
-import org.apache.cassandra.io.sstable.format.Version;
import org.apache.commons.lang3.builder.EqualsBuilder;
import org.apache.commons.lang3.builder.HashCodeBuilder;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import org.apache.cassandra.db.rows.EncodingStats;
import org.apache.cassandra.db.TypeSizes;
import org.apache.cassandra.db.commitlog.CommitLogPosition;
import org.apache.cassandra.db.commitlog.IntervalSet;
+import org.apache.cassandra.io.ISerializer;
+import org.apache.cassandra.io.sstable.format.Version;
import org.apache.cassandra.io.util.DataInputPlus;
import org.apache.cassandra.io.util.DataOutputPlus;
import org.apache.cassandra.utils.ByteBufferUtil;
@@ -248,6 +251,8 @@ public class StatsMetadata extends MetadataComponent
public static class StatsMetadataSerializer implements
IMetadataComponentSerializer
{
+private static final Logger logger =
LoggerFactory.getLogger(StatsMetadataSerializer.class);
+
public int serializedSize(Version version, StatsMetadata component)
throws IOException
{
int size = 0;
@@ -340,7 +345,27 @@ public class StatsMetadata extends MetadataComponent
public StatsMetadata deserialize(Version version, DataInputPlus in)
throws IOException
{
EstimatedHistogram partitionSizes =
EstimatedHistogram.serializer.deserialize(in);
+
+if (partitionSizes.isOverflowed())
+{
+logger.warn("Deserialized partition size histogram with {}
values greater than the maximum of {}. " +
+"Clearing the overflow bucket to allow for
degraded mean and percentile calculations...",
+partitionSizes.overflowCount(),
partitionSizes.getLargestBucketOffset());
+
+partitionSizes.clearOverflow();
+}
+
EstimatedHistogram columnCounts =
EstimatedHistogram.serializer.deserialize(in);
+
+if (columnCounts.isOverflowed())
+{
+
[jira] [Updated] (CASSANDRA-16113) Consolidate dead nodes check in force repair
[ https://issues.apache.org/jira/browse/CASSANDRA-16113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16113: Reviewers: Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Caleb Rackliffe, Caleb Rackliffe Status: Review In Progress (was: Patch Available) > Consolidate dead nodes check in force repair > > > Key: CASSANDRA-16113 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16113 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > The check for dead nodes during force repair is duplicated in the normal and > incremental repair. We could consolidate those 2 checks to make the code more > dry. > The check should throw a more meaningful error message to indicate that all > neighbor nodes are down, instead of "java.lang.IllegalArgumentException: > Endpoints can not be empty" -- This message was sent by Atlassian Jira (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-15997) TestBootstrap::test_cleanup failing on unexpected number of SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-15997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe reassigned CASSANDRA-15997:
---
Assignee: Caleb Rackliffe
> TestBootstrap::test_cleanup failing on unexpected number of SSTables
>
>
> Key: CASSANDRA-15997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15997
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
>
> This failure has now occurred in a number of places on trunk (4.0), including
> both Java 8 and 11 dtest runs. Nominally, there appear to be more SSTables
> after cleanup than the test is expecting.
> {noformat}
> if len(sstables) > basecount + jobs:
> logger.debug("Current count is {}, basecount was
> {}".format(len(sstables), basecount))
> failed.set()
> {noformat}
> Examples:
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/92/workflows/c59be4f8-329e-4d76-9c59-d49c38e58dd2/jobs/448
> https://app.circleci.com/pipelines/github/jolynch/cassandra/20/workflows/9d6c3b86-6207-4ead-aa4b-79022fc84182/jobs/893
--
This message was sent by Atlassian Jira
(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-16139) Safe Ring Membership Protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201081#comment-17201081
]
Benedict Elliott Smith commented on CASSANDRA-16139:
{quote}I'm doing it on my free voluntary time,
{quote}
It's nice to see somebody put their time into such an important part of the
database, that has languished for so long. Perhaps we will be able to work
together on this at a later date.
Some provocative statements to consider, while you think about this:
* Any replacement should not be built upon Gossip (either in its current or an
improved form)
* Nor should it use the concept of a token ring
I'll justify these statements at a much later date, but it anyway helps to
consider wider context when thinking about these problems, even if you end up
disagreeing.
Some other things to consider:
* Being able to operate with a quorum is probably a lot harder than with every
node's involvement, so I'd suggest thinking about that sooner than later
* How do you guarantee that all participants in an operation have a consistent
view of the ring for the purposes of that operation?
> Safe Ring Membership Protocol
> -
>
> Key: CASSANDRA-16139
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16139
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip, Cluster/Membership
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
>
> This ticket presents a practical protocol for performing safe ring membership
> updates in Cassandra. This protocol will enable reliable concurrent ring
> membership updates.
> The proposed protocol is composed of the following macro-steps:
> *PROPOSE:* An initiator node wanting to make updates to the current ring
> structure (such as joining, leaving the ring or changing token assignments)
> must propose the change to the other members of the ring (cohort).
> *ACCEPT:* Upon receiving a proposal the other ring members determine if the
> change is compatible with their local version of the ring, and if so, they
> promise to accept the change proposed by the initiator. The ring members do
> not accept proposals if they had already promised to honor another proposal,
> to avoid conflicting ring membership updates.
> *COMMIT:* Once the initiator receives acceptances from all the nodes in the
> cohort, it commits the proposal by broadcasting the proposed ring delta via
> gossip. Upon receiving these changes, the other members of the cohort apply
> the delta to their local version of the ring and broadcast their new computed
> version via gossip. The initiator concludes the ring membership update
> operation by checking that all nodes agree on the new proposed version.
> *ABORT:* A proposal not accepted by all members of the cohort may be
> automatically aborted by the initiator or manually via a command line tool.
> For simplicity the protocol above requires that all nodes are up during the
> proposal step, but it should be possible to optimize it to require only a
> quorum of nodes up to perform ring changes.
> A python pseudo-code of the protocol is available
> [here|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-safe_ring_membership-py].
> With the abstraction above it becomes very simple to perform ring change
> operations:
> *
> [bootstrap|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-bootstrap-py]
> *
> [replace|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-replace-py]
> *
> [move|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-move-py]
> * [remove
> node|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_node-py]
> * [remove
> token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_token-py]
> h4. Token Ring Data Structure
> The token ring data structure can be seen as a [Delta State Replicated Data
> Type|https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type#State-based_CRDTs]
> (Delta CRDT) containing the state of all (virtual) nodes in the cluster
> where updates to the ring are operations on this CRDT.
> Each member publishes its latest local accepted state (delta state) via
> gossip and the union of all delta states comprise the global ring state. The
> delta state must be commutative and idempotent to ensure all nodes will
> eventually reach the same global state no matter the order received.
> The content-addressed fingerprint of the global ring state uniquely
> identifies the ring version and provides a simple way to verify agreement
> between nodes in the cluster. Any change to the ring membership must be
> agreed using the described protocol, ensuring that both
[jira] [Commented] (CASSANDRA-15977) 4.0 quality testing: Read Repair
[ https://issues.apache.org/jira/browse/CASSANDRA-15977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201079#comment-17201079 ] Caleb Rackliffe commented on CASSANDRA-15977: - +1 > 4.0 quality testing: Read Repair > > > Key: CASSANDRA-15977 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15977 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/unit >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 13h 10m > Remaining Estimate: 0h > > This is a subtask of CASSANDRA-15579 focusing on read repair. > [This > document|https://docs.google.com/document/d/1-gldHcdLSMRbDhhI8ahs_tPeAZsjurjXr38xABVjWHE/edit?usp=sharing] > lists and describes the existing functional tests for read repair, so we can > have a broad view of what is currently covered. We can comment on this > document and add ideas for new cases/tests, so it can gradually evolve to a > more or less detailed test plan. -- This message was sent by Atlassian Jira (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-15997) TestBootstrap::test_cleanup failing on unexpected number of SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-15997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201077#comment-17201077
]
Caleb Rackliffe commented on CASSANDRA-15997:
-
Saw this again on
https://app.circleci.com/pipelines/github/maedhroz/cassandra/120/workflows/03a81457-1d8a-47a2-a169-779a346053dc/jobs/656
> TestBootstrap::test_cleanup failing on unexpected number of SSTables
>
>
> Key: CASSANDRA-15997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15997
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
>
> This failure has now occurred in a number of places on trunk (4.0), including
> both Java 8 and 11 dtest runs. Nominally, there appear to be more SSTables
> after cleanup than the test is expecting.
> {noformat}
> if len(sstables) > basecount + jobs:
> logger.debug("Current count is {}, basecount was
> {}".format(len(sstables), basecount))
> failed.set()
> {noformat}
> Examples:
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/92/workflows/c59be4f8-329e-4d76-9c59-d49c38e58dd2/jobs/448
> https://app.circleci.com/pipelines/github/jolynch/cassandra/20/workflows/9d6c3b86-6207-4ead-aa4b-79022fc84182/jobs/893
--
This message was sent by Atlassian Jira
(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-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200995#comment-17200995 ] Caleb Rackliffe edited comment on CASSANDRA-15164 at 9/23/20, 8:30 PM: --- Updated version of the patch: [trunk|https://github.com/apache/cassandra/pull/750], [j8 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/120/workflows/da3718e8-6cb0-4727-b89d-2c17e14e347f], [j11 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/120/workflows/03a81457-1d8a-47a2-a169-779a346053dc] UPDATE: The only test failures I see are CASSANDRA-15958, CASSANDRA-15892, and CASSANDRA-15997. was (Author: maedhroz): Updated version of the patch: [trunk|https://github.com/apache/cassandra/pull/750], [j8 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/120/workflows/da3718e8-6cb0-4727-b89d-2c17e14e347f], [j11 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/120/workflows/03a81457-1d8a-47a2-a169-779a346053dc] > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (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-15892) JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201075#comment-17201075 ] Caleb Rackliffe commented on CASSANDRA-15892: - Saw this today in https://app.circleci.com/pipelines/github/maedhroz/cassandra/120/workflows/03a81457-1d8a-47a2-a169-779a346053dc/jobs/653 > JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild > -- > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-rc > > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (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-15854) Truncation should fail any ongoing repairs
[
https://issues.apache.org/jira/browse/CASSANDRA-15854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201069#comment-17201069
]
David Capwell commented on CASSANDRA-15854:
---
Been running the tests in a loop to make sure not flaky, found this failure
{code}
testclasslist:
[echo] Number of test runners: 1
[junit-timeout] Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true
[junit-timeout] Testsuite:
org.apache.cassandra.distributed.test.IncRepairTruncationTest
[junit-timeout] Testsuite:
org.apache.cassandra.distributed.test.IncRepairTruncationTest Tests run: 1,
Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 108.5 sec
[junit-timeout]
[junit-timeout] Testcase:
testTruncateDuringIncRepair(org.apache.cassandra.distributed.test.IncRepairTruncationTest):
FAILED
[junit-timeout] null
[junit-timeout] junit.framework.AssertionFailedError
[junit-timeout] at
org.apache.cassandra.distributed.test.IncRepairTruncationTest.testTruncateDuringIncRepair(IncRepairTruncationTest.java:100)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test
org.apache.cassandra.distributed.test.IncRepairTruncationTest FAILED
[junitreport] Processing
/Users/davidcapwell/src/github/apache/team/marcus-cassandra/build/test/TESTS-TestSuites.xml
to /var/folders/cm/08cddl2s25j7fq3jdb76gh4rgn/T/null1038731269
[junitreport] Loading stylesheet
jar:file:/usr/local/Cellar/ant/1.10.7/libexec/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
[junitreport] Transform time: 5425ms
[junitreport] Deleting:
/var/folders/cm/08cddl2s25j7fq3jdb76gh4rgn/T/null1038731269
BUILD FAILED
/Users/davidcapwell/src/github/apache/team/marcus-cassandra/build.xml:2004: The
following error occurred while executing this line:
/Users/davidcapwell/src/github/apache/team/marcus-cassandra/build.xml:1894:
Some test(s) failed.
{code}
Seems an inconsistency was found; this was on the branch without changes.
This failed after the 13th run with lower resources (2 physical cores; 4
hyper-threaded).
> Truncation should fail any ongoing repairs
> --
>
> Key: CASSANDRA-15854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15854
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Truncation may race with ongoing repairs, making it possible to clear data on
> one node but then stream data its truncation would have deleted from another
> node. We should abort any ongoing preview repairs if we get a truncation
> request.
--
This message was sent by Atlassian Jira
(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-16144) TLS connections to the storage port on a node without server encryption configured causes java.io.IOException accessing missing keystore
[
https://issues.apache.org/jira/browse/CASSANDRA-16144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16144:
--
Bug Category: Parent values: Availability(12983)Level 1 values: Response
Crash(12991)
Complexity: Normal
Discovered By: Shadow Traffic
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
> TLS connections to the storage port on a node without server encryption
> configured causes java.io.IOException accessing missing keystore
>
>
> Key: CASSANDRA-16144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16144
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
>
> If a TLS connection is requested against a node with all encryption disabled
> by configuration,
> configured with
> {code}
> server_encryption_options: {optional:false, internode_encryption: none}
> {code}
> it logs the following error if no keystore exists for the node.
> {code}
> INFO [Messaging-EventLoop-3-3] 2020-09-15T14:30:02,952 : -
> 127.0.0.1:7000->127.0.1.1:7000-URGENT_MESSAGES-[no-channel] failed to connect
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: local1-i1/127.0.1.1:7000
> Caused by: java.net.ConnectException: Connection refused
>at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[?:?]
>at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779) ~[?:?]
>at
> io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:330)
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334)
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:702)
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
> ~[netty-all-4.1.50.Final.jar:4.1.50.Final]
>at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.lang.Thread.run(Thread.java:834) [?:?]
> WARN [Messaging-EventLoop-3-9] 2020-09-15T14:30:06,375 : - Failed to
> initialize a channel. Closing: [id: 0x0746c157, L:/127.0.0.1:7000 -
> R:/127.0.0.1:59623]
> java.io.IOException: failed to build trust manager store for secure
> connections
>at
> org.apache.cassandra.security.SSLFactory.buildKeyManagerFactory(SSLFactory.java:232)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:300)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> org.apache.cassandra.security.SSLFactory.getOrCreateSslContext(SSLFactory.java:276)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> org.apache.cassandra.security.SSLFactory.getOrCreateSslContext(SSLFactory.java:257)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> org.apache.cassandra.net.InboundConnectionInitiator$Initializer.initChannel(InboundConnectionInitiator.java:107)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> org.apache.cassandra.net.InboundConnectionInitiator$Initializer.initChannel(InboundConnectionInitiator.java:71)
> ~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
>at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:938)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at
>
[jira] [Updated] (CASSANDRA-16143) Streaming fails when s SSTable writer finish() exceeds internode_tcp_user_timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-16143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16143:
--
Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear
Impact(13164)
Complexity: Normal
Discovered By: Shadow Traffic
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
> Streaming fails when s SSTable writer finish() exceeds
> internode_tcp_user_timeout
> -
>
> Key: CASSANDRA-16143
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16143
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
>
> tl;dr The internode TCP user timeout that provides more responsive detection
> of dead nodes for internode message will cause streaming to fail if system
> calls to fsync/fdatasync exceed the timeout (default 30s).
> To workaround, explicitly set internode_tcp_user_timeout to longer than
> fsync/fdatasync, or to zero to revert to the operating system default.
> Details:
> While bootstrapping a replacement 4.0beta3 node in an existing cluster,
> bootstrap streaming repeatedly failed with the streaming follower logging
> {code:java}
> ERROR 2020-09-10T14:29:34,711 [NettyStreaming-Outbound-1.1.1.1.7000:1]
> org.apache.cassandra.streaming.StreamSession:693 - [Stream
> #7cb67c00-f3ac-11ea-b940-f7836f164528] Streaming error occurred on session
> with peer 1.1.1.1:7000
> org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException: The channel
> this output stream was writing to has been closed
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.propagateFailedFlush(AsyncChannelOutputPlus.java:200)
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitUntilFlushed(AsyncChannelOutputPlus.java:158)
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.waitForSpace(AsyncChannelOutputPlus.java:140)
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.beginFlush(AsyncChannelOutputPlus.java:97)
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.lambda$writeToChannel$0(AsyncStreamingOutputPlus.java:142)
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.lambda$write$0(CassandraCompressedStreamWriter.java:90)
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.writeToChannel(AsyncStreamingOutputPlus.java:138)
>at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.write(CassandraCompressedStreamWriter.java:89)
>at
> org.apache.cassandra.db.streaming.CassandraOutgoingFile.write(CassandraOutgoingFile.java:180)
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage.serialize(OutgoingStreamMessage.java:87)
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:45)
>at
> org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:34)
>at
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:40)
>at
> org.apache.cassandra.streaming.async.NettyStreamingMessageSender$FileStreamTask.run(NettyStreamingMessageSender.java:347)
>at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
>at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.lang.Thread.run(Thread.java:834) [?:?]
>Suppressed: java.nio.channels.ClosedChannelException
>at
> org.apache.cassandra.net.AsyncStreamingOutputPlus.doFlush(AsyncStreamingOutputPlus.java:78)
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.flush(AsyncChannelOutputPlus.java:229)
>at
> org.apache.cassandra.net.AsyncChannelOutputPlus.close(AsyncChannelOutputPlus.java:248)
>at
> org.apache.cassandra.streaming.async.NettyStreamingMessageSender$FileStreamTask.run(NettyStreamingMessageSender.java:348)
>at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
>at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
>at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
>
[jira] [Commented] (CASSANDRA-15991) 15583 - Add UX tests to intree LHF tooling
[ https://issues.apache.org/jira/browse/CASSANDRA-15991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201054#comment-17201054 ] David Capwell commented on CASSANDRA-15991: --- Thanks, I have a bit of a hectic week so likely won't be able to review till Tuesday. > 15583 - Add UX tests to intree LHF tooling > -- > > Key: CASSANDRA-15991 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15991 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > As per CASSANDRA-15583 many in tree tools lack proper UX tooling: mandatory > params are indeed mandatory, 'help' produces an actual help, return codes etc > This ticket is an attempt to add it to those tools that classify as LHF. > Other tools such as nodetool, with many sub-commands, deserve a separate > ticket of their own -- This message was sent by Atlassian Jira (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-16139) Safe Ring Membership Protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201036#comment-17201036 ] Paulo Motta commented on CASSANDRA-16139: - bq. The proposals will probably be mutually exclusive, so it is probably not advisable to proceed too far with implementation before the project assesses its preferred approach. Thanks for the kind advice! I'm by no means attached to this proposal, as I'm doing it on my free voluntary time, and I will be very happy to see this issue solved no matter which proposal ends up being selected by the community. In the very worst case I will have learned a bit more about distributed membership coordination. :-) > Safe Ring Membership Protocol > - > > Key: CASSANDRA-16139 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16139 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip, Cluster/Membership >Reporter: Paulo Motta >Assignee: Paulo Motta >Priority: Normal > > This ticket presents a practical protocol for performing safe ring membership > updates in Cassandra. This protocol will enable reliable concurrent ring > membership updates. > The proposed protocol is composed of the following macro-steps: > *PROPOSE:* An initiator node wanting to make updates to the current ring > structure (such as joining, leaving the ring or changing token assignments) > must propose the change to the other members of the ring (cohort). > *ACCEPT:* Upon receiving a proposal the other ring members determine if the > change is compatible with their local version of the ring, and if so, they > promise to accept the change proposed by the initiator. The ring members do > not accept proposals if they had already promised to honor another proposal, > to avoid conflicting ring membership updates. > *COMMIT:* Once the initiator receives acceptances from all the nodes in the > cohort, it commits the proposal by broadcasting the proposed ring delta via > gossip. Upon receiving these changes, the other members of the cohort apply > the delta to their local version of the ring and broadcast their new computed > version via gossip. The initiator concludes the ring membership update > operation by checking that all nodes agree on the new proposed version. > *ABORT:* A proposal not accepted by all members of the cohort may be > automatically aborted by the initiator or manually via a command line tool. > For simplicity the protocol above requires that all nodes are up during the > proposal step, but it should be possible to optimize it to require only a > quorum of nodes up to perform ring changes. > A python pseudo-code of the protocol is available > [here|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-safe_ring_membership-py]. > With the abstraction above it becomes very simple to perform ring change > operations: > * > [bootstrap|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-bootstrap-py] > * > [replace|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-replace-py] > * > [move|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-move-py] > * [remove > node|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_node-py] > * [remove > token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_token-py] > h4. Token Ring Data Structure > The token ring data structure can be seen as a [Delta State Replicated Data > Type|https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type#State-based_CRDTs] > (Delta CRDT) containing the state of all (virtual) nodes in the cluster > where updates to the ring are operations on this CRDT. > Each member publishes its latest local accepted state (delta state) via > gossip and the union of all delta states comprise the global ring state. The > delta state must be commutative and idempotent to ensure all nodes will > eventually reach the same global state no matter the order received. > The content-addressed fingerprint of the global ring state uniquely > identifies the ring version and provides a simple way to verify agreement > between nodes in the cluster. Any change to the ring membership must be > agreed using the described protocol, ensuring that both conditions are met: > * All nodes have the same current view of the cluster before the update > (verified via the ring version fingerprint). > * All nodes have agreed to make the exact same update and not accept any > other update before the current proposed update is committed or aborted. > h4. Ring Convergence Time > Assuming there are no network partitions, the ring membership convergence > time will be dominated by the commit step since
[jira] [Commented] (CASSANDRA-8494) incremental bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-8494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201025#comment-17201025 ] Paulo Motta commented on CASSANDRA-8494: Dynamic virtual nodes (CASSANDRA-16141) will make it trivial to support incremental bootstrap. The idea is similar to [~rustyrazorblade] suggestion on [this comment|https://issues.apache.org/jira/browse/CASSANDRA-8494?focusedCommentId=14264970=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14264970]: a node will bootstrap one token at a time and announce to the cluster that token is ready to receive requests before bootstrapping the next token. The pseudo-code is available [here|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-incremental_bootstrap-py]. > incremental bootstrap > - > > Key: CASSANDRA-8494 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8494 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Streaming and Messaging >Reporter: Jon Haddad >Assignee: Yuki Morishita >Priority: Low > Labels: dense-storage > Fix For: 4.x > > > Current bootstrapping involves (to my knowledge) picking tokens and streaming > data before the node is available for requests. This can be problematic with > "fat nodes", since it may require 20TB of data to be streamed over before the > machine can be useful. This can result in a massive window of time before > the machine can do anything useful. > As a potential approach to mitigate the huge window of time before a node is > available, I suggest modifying the bootstrap process to only acquire a single > initial token before being marked UP. This would likely be a configuration > parameter "incremental_bootstrap" or something similar. > After the node is bootstrapped with this one token, it could go into UP > state, and could then acquire additional tokens (one or a handful at a time), > which would be streamed over while the node is active and serving requests. > The benefit here is that with the default 256 tokens a node could become an > active part of the cluster with less than 1% of it's final data streamed over. -- This message was sent by Atlassian Jira (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-16139) Safe Ring Membership Protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201023#comment-17201023
]
Benedict Elliott Smith commented on CASSANDRA-16139:
{quote}my focus is to validate the technical merits and feasibility of this
design before formally presenting it to the community... feedback on this
pre-proposal is more than welcome
{quote}
My focus will be on 4.0 and quality assurance for now. Since you intend to
flesh out the proposal on your own in the meantime, just keep in mind that for
5.0 there will be another proposal that approaches the problem very
differently; perhaps more than one (but at least one). The proposals will
probably be mutually exclusive, so it is probably not advisable to proceed too
far with implementation before the project assesses its preferred approach.
When I am able to find time I will publish details, but I have no timeline
given the project's focus on 4.0 and quality assurance.
> Safe Ring Membership Protocol
> -
>
> Key: CASSANDRA-16139
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16139
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip, Cluster/Membership
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
>
> This ticket presents a practical protocol for performing safe ring membership
> updates in Cassandra. This protocol will enable reliable concurrent ring
> membership updates.
> The proposed protocol is composed of the following macro-steps:
> *PROPOSE:* An initiator node wanting to make updates to the current ring
> structure (such as joining, leaving the ring or changing token assignments)
> must propose the change to the other members of the ring (cohort).
> *ACCEPT:* Upon receiving a proposal the other ring members determine if the
> change is compatible with their local version of the ring, and if so, they
> promise to accept the change proposed by the initiator. The ring members do
> not accept proposals if they had already promised to honor another proposal,
> to avoid conflicting ring membership updates.
> *COMMIT:* Once the initiator receives acceptances from all the nodes in the
> cohort, it commits the proposal by broadcasting the proposed ring delta via
> gossip. Upon receiving these changes, the other members of the cohort apply
> the delta to their local version of the ring and broadcast their new computed
> version via gossip. The initiator concludes the ring membership update
> operation by checking that all nodes agree on the new proposed version.
> *ABORT:* A proposal not accepted by all members of the cohort may be
> automatically aborted by the initiator or manually via a command line tool.
> For simplicity the protocol above requires that all nodes are up during the
> proposal step, but it should be possible to optimize it to require only a
> quorum of nodes up to perform ring changes.
> A python pseudo-code of the protocol is available
> [here|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-safe_ring_membership-py].
> With the abstraction above it becomes very simple to perform ring change
> operations:
> *
> [bootstrap|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-bootstrap-py]
> *
> [replace|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-replace-py]
> *
> [move|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-move-py]
> * [remove
> node|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_node-py]
> * [remove
> token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_token-py]
> h4. Token Ring Data Structure
> The token ring data structure can be seen as a [Delta State Replicated Data
> Type|https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type#State-based_CRDTs]
> (Delta CRDT) containing the state of all (virtual) nodes in the cluster
> where updates to the ring are operations on this CRDT.
> Each member publishes its latest local accepted state (delta state) via
> gossip and the union of all delta states comprise the global ring state. The
> delta state must be commutative and idempotent to ensure all nodes will
> eventually reach the same global state no matter the order received.
> The content-addressed fingerprint of the global ring state uniquely
> identifies the ring version and provides a simple way to verify agreement
> between nodes in the cluster. Any change to the ring membership must be
> agreed using the described protocol, ensuring that both conditions are met:
> * All nodes have the same current view of the cluster before the update
> (verified via the ring version fingerprint).
> * All nodes
[jira] [Created] (CASSANDRA-16144) TLS connections to the storage port on a node without server encryption configured causes java.io.IOException accessing missing keystore
Jon Meredith created CASSANDRA-16144:
Summary: TLS connections to the storage port on a node without
server encryption configured causes java.io.IOException accessing missing
keystore
Key: CASSANDRA-16144
URL: https://issues.apache.org/jira/browse/CASSANDRA-16144
Project: Cassandra
Issue Type: Bug
Components: Messaging/Internode
Reporter: Jon Meredith
Assignee: Jon Meredith
If a TLS connection is requested against a node with all encryption disabled by
configuration,
configured with
{code}
server_encryption_options: {optional:false, internode_encryption: none}
{code}
it logs the following error if no keystore exists for the node.
{code}
INFO [Messaging-EventLoop-3-3] 2020-09-15T14:30:02,952 : -
127.0.0.1:7000->127.0.1.1:7000-URGENT_MESSAGES-[no-channel] failed to connect
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
local1-i1/127.0.1.1:7000
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[?:?]
at
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779) ~[?:?]
at
io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:330)
~[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334)
~[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:702)
~[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
~[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
~[netty-all-4.1.50.Final.jar:4.1.50.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at java.lang.Thread.run(Thread.java:834) [?:?]
WARN [Messaging-EventLoop-3-9] 2020-09-15T14:30:06,375 : - Failed to
initialize a channel. Closing: [id: 0x0746c157, L:/127.0.0.1:7000 -
R:/127.0.0.1:59623]
java.io.IOException: failed to build trust manager store for secure connections
at
org.apache.cassandra.security.SSLFactory.buildKeyManagerFactory(SSLFactory.java:232)
~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
at
org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:300)
~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
at
org.apache.cassandra.security.SSLFactory.getOrCreateSslContext(SSLFactory.java:276)
~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
at
org.apache.cassandra.security.SSLFactory.getOrCreateSslContext(SSLFactory.java:257)
~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
at
org.apache.cassandra.net.InboundConnectionInitiator$Initializer.initChannel(InboundConnectionInitiator.java:107)
~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
at
org.apache.cassandra.net.InboundConnectionInitiator$Initializer.initChannel(InboundConnectionInitiator.java:71)
~[apache-cassandra-4.0-beta1-SNAPSHOT.jar:4.0-beta1-SNAPSHOT]
at
io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:938)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at
[jira] [Created] (CASSANDRA-16143) Streaming fails when s SSTable writer finish() exceeds internode_tcp_user_timeout
Jon Meredith created CASSANDRA-16143:
Summary: Streaming fails when s SSTable writer finish() exceeds
internode_tcp_user_timeout
Key: CASSANDRA-16143
URL: https://issues.apache.org/jira/browse/CASSANDRA-16143
Project: Cassandra
Issue Type: Bug
Components: Messaging/Internode
Reporter: Jon Meredith
Assignee: Jon Meredith
tl;dr The internode TCP user timeout that provides more responsive detection of
dead nodes for internode message will cause streaming to fail if system calls
to fsync/fdatasync exceed the timeout (default 30s).
To workaround, explicitly set internode_tcp_user_timeout to longer than
fsync/fdatasync, or to zero to revert to the operating system default.
Details:
While bootstrapping a replacement 4.0beta3 node in an existing cluster,
bootstrap streaming repeatedly failed with the streaming follower logging
{code:java}
ERROR 2020-09-10T14:29:34,711 [NettyStreaming-Outbound-1.1.1.1.7000:1]
org.apache.cassandra.streaming.StreamSession:693 - [Stream
#7cb67c00-f3ac-11ea-b940-f7836f164528] Streaming error occurred on session with
peer 1.1.1.1:7000
org.apache.cassandra.net.AsyncChannelOutputPlus$FlushException: The channel
this output stream was writing to has been closed
at
org.apache.cassandra.net.AsyncChannelOutputPlus.propagateFailedFlush(AsyncChannelOutputPlus.java:200)
at
org.apache.cassandra.net.AsyncChannelOutputPlus.waitUntilFlushed(AsyncChannelOutputPlus.java:158)
at
org.apache.cassandra.net.AsyncChannelOutputPlus.waitForSpace(AsyncChannelOutputPlus.java:140)
at
org.apache.cassandra.net.AsyncChannelOutputPlus.beginFlush(AsyncChannelOutputPlus.java:97)
at
org.apache.cassandra.net.AsyncStreamingOutputPlus.lambda$writeToChannel$0(AsyncStreamingOutputPlus.java:142)
at
org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.lambda$write$0(CassandraCompressedStreamWriter.java:90)
at
org.apache.cassandra.net.AsyncStreamingOutputPlus.writeToChannel(AsyncStreamingOutputPlus.java:138)
at
org.apache.cassandra.db.streaming.CassandraCompressedStreamWriter.write(CassandraCompressedStreamWriter.java:89)
at
org.apache.cassandra.db.streaming.CassandraOutgoingFile.write(CassandraOutgoingFile.java:180)
at
org.apache.cassandra.streaming.messages.OutgoingStreamMessage.serialize(OutgoingStreamMessage.java:87)
at
org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:45)
at
org.apache.cassandra.streaming.messages.OutgoingStreamMessage$1.serialize(OutgoingStreamMessage.java:34)
at
org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:40)
at
org.apache.cassandra.streaming.async.NettyStreamingMessageSender$FileStreamTask.run(NettyStreamingMessageSender.java:347)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at java.lang.Thread.run(Thread.java:834) [?:?]
Suppressed: java.nio.channels.ClosedChannelException
at
org.apache.cassandra.net.AsyncStreamingOutputPlus.doFlush(AsyncStreamingOutputPlus.java:78)
at
org.apache.cassandra.net.AsyncChannelOutputPlus.flush(AsyncChannelOutputPlus.java:229)
at
org.apache.cassandra.net.AsyncChannelOutputPlus.close(AsyncChannelOutputPlus.java:248)
at
org.apache.cassandra.streaming.async.NettyStreamingMessageSender$FileStreamTask.run(NettyStreamingMessageSender.java:348)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[netty-all-4.1.50.Final.jar:4.1.50.Final]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: io.netty.channel.unix.Errors$NativeIoException: writeAddress(..)
failed: Connection timed out
{code}
and the boostrapping node (the streaming initiator) logging (times are from two
separate attempts, pattern was very similar each time, IP addresses doctored to
protect the innocent)
{code:java}
ERROR 2020-09-11T09:45:54,720
[jira] [Updated] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-15164: Status: Patch Available (was: In Progress) Updated version of the patch: [trunk|https://github.com/apache/cassandra/pull/750], [j8 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/120/workflows/da3718e8-6cb0-4727-b89d-2c17e14e347f], [j11 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/120/workflows/03a81457-1d8a-47a2-a169-779a346053dc] > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (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-16139) Safe Ring Membership Protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200993#comment-17200993
]
Paulo Motta commented on CASSANDRA-16139:
-
{quote}Just an FYI that this subsystem is on others' hitlist, we're just
waiting until post-4.0 to engage on list about it.
{quote}
Thanks for the heads up! I didn't find any mention of this intent in a public
forum, besides the stale discussion from CASSANDRA-9667, so I assumed nobody
else was looking into this.
{quote}I would recommend starting a CEP process to gather interested parties,
as I have a very different idea about how this work should proceed, as might
others. We will have to work to reconcile our different thoughts into progress
for the project.
{quote}
I plan to open a CEP with this proposal, as mentioned on the parent epic
(CASSANDRA-16137), but it's not my priority right now as my focus is to
validate the technical merits and feasibility of this design before formally
presenting it to the community.
In any case, yours (and others) feedback on this pre-proposal is more than
welcome! I'm looking forward to reach a common ground with alternative
proposals towards a solution to this long old project pain.
> Safe Ring Membership Protocol
> -
>
> Key: CASSANDRA-16139
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16139
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip, Cluster/Membership
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
>
> This ticket presents a practical protocol for performing safe ring membership
> updates in Cassandra. This protocol will enable reliable concurrent ring
> membership updates.
> The proposed protocol is composed of the following macro-steps:
> *PROPOSE:* An initiator node wanting to make updates to the current ring
> structure (such as joining, leaving the ring or changing token assignments)
> must propose the change to the other members of the ring (cohort).
> *ACCEPT:* Upon receiving a proposal the other ring members determine if the
> change is compatible with their local version of the ring, and if so, they
> promise to accept the change proposed by the initiator. The ring members do
> not accept proposals if they had already promised to honor another proposal,
> to avoid conflicting ring membership updates.
> *COMMIT:* Once the initiator receives acceptances from all the nodes in the
> cohort, it commits the proposal by broadcasting the proposed ring delta via
> gossip. Upon receiving these changes, the other members of the cohort apply
> the delta to their local version of the ring and broadcast their new computed
> version via gossip. The initiator concludes the ring membership update
> operation by checking that all nodes agree on the new proposed version.
> *ABORT:* A proposal not accepted by all members of the cohort may be
> automatically aborted by the initiator or manually via a command line tool.
> For simplicity the protocol above requires that all nodes are up during the
> proposal step, but it should be possible to optimize it to require only a
> quorum of nodes up to perform ring changes.
> A python pseudo-code of the protocol is available
> [here|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-safe_ring_membership-py].
> With the abstraction above it becomes very simple to perform ring change
> operations:
> *
> [bootstrap|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-bootstrap-py]
> *
> [replace|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-replace-py]
> *
> [move|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-move-py]
> * [remove
> node|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_node-py]
> * [remove
> token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_token-py]
> h4. Token Ring Data Structure
> The token ring data structure can be seen as a [Delta State Replicated Data
> Type|https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type#State-based_CRDTs]
> (Delta CRDT) containing the state of all (virtual) nodes in the cluster
> where updates to the ring are operations on this CRDT.
> Each member publishes its latest local accepted state (delta state) via
> gossip and the union of all delta states comprise the global ring state. The
> delta state must be commutative and idempotent to ensure all nodes will
> eventually reach the same global state no matter the order received.
> The content-addressed fingerprint of the global ring state uniquely
> identifies the ring version and provides a simple way to verify agreement
> between nodes in the cluster. Any change to the ring
[jira] [Commented] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200986#comment-17200986 ] Jon Meredith commented on CASSANDRA-15164: -- I'd support increasing the number of buckets and keeping the changes to continue to operate if there is an overflow. Looks like the histogram #buckets is written by the serializer so no compatibility concerns with the file formats. > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (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-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200960#comment-17200960 ] Caleb Rackliffe commented on CASSANDRA-15164: - [~blerer] As long as [~clohfink] doesn't have any objections, I think raising the number of buckets to 118 should be a pretty innocuous change, and we already encode the length, so it won't break anything (...and I'll keep the rest of the latest version of the patch in place to catch existing corruption). > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (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-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200944#comment-17200944 ] Caleb Rackliffe commented on CASSANDRA-16048: - [~jwest] Dropped a couple more minor nits (mostly agreeing w/ Sylvain that some logging wouldn't hurt), but otherwise, LGTM +1 > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > -- > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- This message was sent by Atlassian Jira (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-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[
https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200940#comment-17200940
]
Benjamin Lerer edited comment on CASSANDRA-15164 at 9/23/20, 4:38 PM:
--
After thinking about that problem overnight, I realized that a corruption might
not necessary be the problem. I had a quick chat with [~slebresne] who believe
that it should be possible to create a partitions with more than 2 billions
cells.
By consequence, I think that we should change the code to ensure that we do not
overflow if a partition has more than 2 billion cells. For that we can either
increase the default number of buckets (using {{118}} instead of {{114}} will
allow for more than 4 billions cells) or dynamically increasing the number of
buckets if needed.
Otherwise, the approach to clear the overflow seems reasonable to me as it will
solve the problem of the already corrupted {{Statistics}}.
wdyt?
was (Author: blerer):
After thinking about that problem overnight, I realized that a corruption might
not necessary be the problem. I had a quick chat with [~slebresne] who believe
that it should be possible to create a partitions with more than 2 billions
cells.
By consequence, I think that we should change the code to ensure that we do not
overflow if a partition has more than 2 billion cells. For that we can either
increase the default number of buckets (using {{118}} instead of {{114}} will
allow for more than 4 billions cells) or dynamically increasing the number of
buckets if needed.
Otherwise, the approach to clear the overflow seems reasonable to me as it will
solve the problem of the already corrupted {{Statistics}}.
WDYT?
> Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
> ---
>
> Key: CASSANDRA-15164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15164
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Ankur Jha
>Assignee: Caleb Rackliffe
>Priority: Urgent
> Labels: compaction, partition
> Fix For: 4.0-beta
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Hi, we are running 6 node Cassandra cluster in production with 3 seed node
> but from last night one of our seed nodes is continuously throwing an error
> like this;-
> cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max
> when histogram overflowed">
> For a cluster to be up and running I Drained this node.
> Can somebody help me out with this?
>
> Any help or lead would be appreciated
>
> Note : We are using Cassandra version 3.7
--
This message was sent by Atlassian Jira
(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-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[
https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200940#comment-17200940
]
Benjamin Lerer edited comment on CASSANDRA-15164 at 9/23/20, 4:36 PM:
--
After thinking about that problem overnight, I realized that a corruption might
not necessary be the problem. I had a quick chat with [~slebresne] who believe
that it should be possible to create a partitions with more than 2 billions
cells.
By consequence, I think that we should change the code to ensure that we do not
overflow if a partition has more than 2 billion cells. For that we can either
increase the default number of buckets (using {{118}} instead of {{114}} will
allow for more than 4 billions cells) or dynamically increasing the number of
buckets if needed.
Otherwise, the approach to clear the overflow seems reasonable to me as it will
solve the problem of the already corrupted {{Statistics}}.
was (Author: blerer):
After thinking about that problem overnight, I realized that the serialization
might not necessary be the problem. I had a quick chat with [~slebresne] who
believe that it should be possible to create a partitions with more than 2
billions cells.
By consequence, I think that we should change the code to ensure that we do not
overflow if a partition has more than 2 billion cells. For that we can either
increase the default number of buckets (using {{118}} instead of {{114}} will
allow for more than 4 billions cells) or dynamically increasing the number of
buckets if needed.
Otherwise, the approach to clear the overflow seems reasonable to me as it will
solve the problem of the already corrupted {{Statistics}}.
> Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
> ---
>
> Key: CASSANDRA-15164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15164
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Ankur Jha
>Assignee: Caleb Rackliffe
>Priority: Urgent
> Labels: compaction, partition
> Fix For: 4.0-beta
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Hi, we are running 6 node Cassandra cluster in production with 3 seed node
> but from last night one of our seed nodes is continuously throwing an error
> like this;-
> cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max
> when histogram overflowed">
> For a cluster to be up and running I Drained this node.
> Can somebody help me out with this?
>
> Any help or lead would be appreciated
>
> Note : We are using Cassandra version 3.7
--
This message was sent by Atlassian Jira
(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-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[
https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200940#comment-17200940
]
Benjamin Lerer edited comment on CASSANDRA-15164 at 9/23/20, 4:36 PM:
--
After thinking about that problem overnight, I realized that a corruption might
not necessary be the problem. I had a quick chat with [~slebresne] who believe
that it should be possible to create a partitions with more than 2 billions
cells.
By consequence, I think that we should change the code to ensure that we do not
overflow if a partition has more than 2 billion cells. For that we can either
increase the default number of buckets (using {{118}} instead of {{114}} will
allow for more than 4 billions cells) or dynamically increasing the number of
buckets if needed.
Otherwise, the approach to clear the overflow seems reasonable to me as it will
solve the problem of the already corrupted {{Statistics}}.
WDYT?
was (Author: blerer):
After thinking about that problem overnight, I realized that a corruption might
not necessary be the problem. I had a quick chat with [~slebresne] who believe
that it should be possible to create a partitions with more than 2 billions
cells.
By consequence, I think that we should change the code to ensure that we do not
overflow if a partition has more than 2 billion cells. For that we can either
increase the default number of buckets (using {{118}} instead of {{114}} will
allow for more than 4 billions cells) or dynamically increasing the number of
buckets if needed.
Otherwise, the approach to clear the overflow seems reasonable to me as it will
solve the problem of the already corrupted {{Statistics}}.
> Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
> ---
>
> Key: CASSANDRA-15164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15164
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Ankur Jha
>Assignee: Caleb Rackliffe
>Priority: Urgent
> Labels: compaction, partition
> Fix For: 4.0-beta
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Hi, we are running 6 node Cassandra cluster in production with 3 seed node
> but from last night one of our seed nodes is continuously throwing an error
> like this;-
> cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max
> when histogram overflowed">
> For a cluster to be up and running I Drained this node.
> Can somebody help me out with this?
>
> Any help or lead would be appreciated
>
> Note : We are using Cassandra version 3.7
--
This message was sent by Atlassian Jira
(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-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[
https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200940#comment-17200940
]
Benjamin Lerer commented on CASSANDRA-15164:
After thinking about that problem overnight, I realized that the serialization
might not necessary be the problem. I had a quick chat with [~slebresne] who
believe that it should be possible to create a partitions with more than 2
billions cells.
By consequence, I think that we should change the code to ensure that we do not
overflow if a partition has more than 2 billion cells. For that we can either
increase the default number of buckets (using {{118}} instead of {{114}} will
allow for more than 4 billions cells) or dynamically increasing the number of
buckets if needed.
Otherwise, the approach to clear the overflow seems reasonable to me as it will
solve the problem of the already corrupted {{Statistics}}.
> Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
> ---
>
> Key: CASSANDRA-15164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15164
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Ankur Jha
>Assignee: Caleb Rackliffe
>Priority: Urgent
> Labels: compaction, partition
> Fix For: 4.0-beta
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Hi, we are running 6 node Cassandra cluster in production with 3 seed node
> but from last night one of our seed nodes is continuously throwing an error
> like this;-
> cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max
> when histogram overflowed">
> For a cluster to be up and running I Drained this node.
> Can somebody help me out with this?
>
> Any help or lead would be appreciated
>
> Note : We are using Cassandra version 3.7
--
This message was sent by Atlassian Jira
(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-16139) Safe Ring Membership Protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200889#comment-17200889 ] Benedict Elliott Smith commented on CASSANDRA-16139: Just an FYI that this subsystem is on others' hitlist, we're just waiting until post-4.0 to engage on list about it. I would recommend starting a CEP process to gather interested parties, as I have a very different idea about how this work should proceed, as might others. We will have to work to reconcile our different thoughts into progress for the project. > Safe Ring Membership Protocol > - > > Key: CASSANDRA-16139 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16139 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip, Cluster/Membership >Reporter: Paulo Motta >Assignee: Paulo Motta >Priority: Normal > > This ticket presents a practical protocol for performing safe ring membership > updates in Cassandra. This protocol will enable reliable concurrent ring > membership updates. > The proposed protocol is composed of the following macro-steps: > *PROPOSE:* An initiator node wanting to make updates to the current ring > structure (such as joining, leaving the ring or changing token assignments) > must propose the change to the other members of the ring (cohort). > *ACCEPT:* Upon receiving a proposal the other ring members determine if the > change is compatible with their local version of the ring, and if so, they > promise to accept the change proposed by the initiator. The ring members do > not accept proposals if they had already promised to honor another proposal, > to avoid conflicting ring membership updates. > *COMMIT:* Once the initiator receives acceptances from all the nodes in the > cohort, it commits the proposal by broadcasting the proposed ring delta via > gossip. Upon receiving these changes, the other members of the cohort apply > the delta to their local version of the ring and broadcast their new computed > version via gossip. The initiator concludes the ring membership update > operation by checking that all nodes agree on the new proposed version. > *ABORT:* A proposal not accepted by all members of the cohort may be > automatically aborted by the initiator or manually via a command line tool. > For simplicity the protocol above requires that all nodes are up during the > proposal step, but it should be possible to optimize it to require only a > quorum of nodes up to perform ring changes. > A python pseudo-code of the protocol is available > [here|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-safe_ring_membership-py]. > With the abstraction above it becomes very simple to perform ring change > operations: > * > [bootstrap|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-bootstrap-py] > * > [replace|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-replace-py] > * > [move|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-move-py] > * [remove > node|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_node-py] > * [remove > token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_token-py] > h4. Token Ring Data Structure > The token ring data structure can be seen as a [Delta State Replicated Data > Type|https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type#State-based_CRDTs] > (Delta CRDT) containing the state of all (virtual) nodes in the cluster > where updates to the ring are operations on this CRDT. > Each member publishes its latest local accepted state (delta state) via > gossip and the union of all delta states comprise the global ring state. The > delta state must be commutative and idempotent to ensure all nodes will > eventually reach the same global state no matter the order received. > The content-addressed fingerprint of the global ring state uniquely > identifies the ring version and provides a simple way to verify agreement > between nodes in the cluster. Any change to the ring membership must be > agreed using the described protocol, ensuring that both conditions are met: > * All nodes have the same current view of the cluster before the update > (verified via the ring version fingerprint). > * All nodes have agreed to make the exact same update and not accept any > other update before the current proposed update is committed or aborted. > h4. Ring Convergence Time > Assuming there are no network partitions, the ring membership convergence > time will be dominated by the commit step since that is performed via gossip > broadcast. > The gossip broadcast is performed by sending the ring delta to the seed > nodes,
[jira] [Updated] (CASSANDRA-16141) Enable Adding and Removing Tokens to a Node (Dynamic Virtual Nodes)
[ https://issues.apache.org/jira/browse/CASSANDRA-16141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16141: Description: The new ring membership protocol added on CASSANDRA-16139 allows adding and removing tokens to an existing cluster node. This allows operators to increase/reduce the number of virtual nodes per node on a live cluster. Furthermore this also enables Incremental Bootstrap (CASSANDRA-8494). This ticket is to enable this functionality to users via ringtool (CASSANDRA-16140). The pseudo-code for each operation is available below: * [add token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-bootstrap-py] (essentially similar to bootstrap) * [remove token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_token-py] was: The new ring membership protocol added on CASSANDRA-16139 allows adding and removing tokens to an existing cluster node. This allows operators to increase/reduce the number of virtual nodes per node on a live cluster. Furthermore this also enables Incremental Bootstrap (CASSANDRA-8494). This ticket is to enable this functionality to users via ringtool (CASSANDRA-16140). The pseudo-code for each operation is available below: * [add token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-bootstrap-py] (essentially similar to bootstrap) * [remove token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_token-py) > Enable Adding and Removing Tokens to a Node (Dynamic Virtual Nodes) > --- > > Key: CASSANDRA-16141 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16141 > Project: Cassandra > Issue Type: New Feature > Components: Cluster/Membership, Feature/Virtual Nodes >Reporter: Paulo Motta >Priority: Normal > > The new ring membership protocol added on CASSANDRA-16139 allows adding and > removing tokens to an existing cluster node. > This allows operators to increase/reduce the number of virtual nodes per node > on a live cluster. Furthermore this also enables Incremental Bootstrap > (CASSANDRA-8494). > This ticket is to enable this functionality to users via ringtool > (CASSANDRA-16140). > The pseudo-code for each operation is available below: > * [add > token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-bootstrap-py] > (essentially similar to bootstrap) > * [remove > token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_token-py] -- This message was sent by Atlassian Jira (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-16008) 2.2.17 fails to start up with ExceptionInInitializerError
[
https://issues.apache.org/jira/browse/CASSANDRA-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16008:
-
Fix Version/s: (was: 2.2.x)
2.2.19
Since Version: 2.2.18
Source Control Link:
https://github.com/apache/cassandra/commit/ed8005552376188abb81894fb8c9c611ebd6379a
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks.
> 2.2.17 fails to start up with ExceptionInInitializerError
> -
>
> Key: CASSANDRA-16008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16008
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tianon Gravi
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 2.2.19
>
> Attachments: CASSANDRA-16008-2.2.txt
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After the upgrade to 2.2.17, Cassandra fails to start with the following
> error:
> {noformat}
> INFO 20:28:57 JVM Arguments: [-Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false, -ea,
> -javaagent:/opt/cassandra/lib/jamm-0.3.0.jar, -XX:+CMSClassUnloadingEnabled,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42, -Xms128m, -Xmx128m,
> -Xmn32m, -XX:+HeapDumpOnOutOfMemoryError, -Xss256k,
> -XX:StringTableSize=103, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC,
> -XX:+CMSParallelRemarkEnabled, -XX:SurvivorRatio=8,
> -XX:MaxTenuringThreshold=1, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly, -XX:+UseTLAB, -XX:+PerfDisableSharedMem,
> -XX:CompileCommandFile=/etc/cassandra/hotspot_compiler,
> -XX:CMSWaitDuration=1, -XX:+CMSParallelInitialMarkEnabled,
> -XX:+CMSEdenChunksRecordAlways, -XX:CMSWaitDuration=1,
> -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC,
> -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime,
> -XX:+PrintPromotionFailure, -Xloggc:/opt/cassandra/logs/gc.log,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -Djava.net.preferIPv4Stack=true, -Dcassandra.jmx.local.port=7199,
> -XX:+DisableExplicitGC, -Djava.library.path=/opt/cassandra/lib/sigar-bin,
> -Dcassandra.libjemalloc=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1,
> -XX:OnOutOfMemoryError=kill -9 %p, -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/opt/cassandra/logs,
> -Dcassandra.storagedir=/opt/cassandra/data, -Dcassandra-foreground=yes]
> WARN 20:28:57 Unable to lock JVM memory (ENOMEM). This can result in part of
> the JVM being swapped out, especially with mmapped I/O enabled. Increase
> RLIMIT_MEMLOCK or run Cassandra as root.
> INFO 20:28:57 jemalloc seems to be preloaded from
> /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
> INFO 20:28:57 JMX is enabled to receive remote connections on port: 7199
> WARN 20:28:57 OpenJDK is not recommended. Please upgrade to the newest
> Oracle Java release
> INFO 20:28:57 Initializing SIGAR library
> INFO 20:28:57 Checked OS settings and found them configured for optimal
> performance.
> WARN 20:28:57 Directory /opt/cassandra/data/commitlog doesn't exist
> WARN 20:28:57 Directory /opt/cassandra/data/saved_caches doesn't exist
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:717)
> Caused by: java.lang.IllegalArgumentException: Bad configuration; unable to
> start server: At least one DataFileDirectory must be specified
> at
> org.apache.cassandra.config.DatabaseDescriptor.createAllDirectories(DatabaseDescriptor.java:846)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:66)
> ... 6 more
> ERROR 20:28:58 Exception encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
>
[jira] [Updated] (CASSANDRA-16008) 2.2.17 fails to start up with ExceptionInInitializerError
[
https://issues.apache.org/jira/browse/CASSANDRA-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16008:
-
Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams)
Brandon Williams, Brandon Williams
Status: Review In Progress (was: Patch Available)
> 2.2.17 fails to start up with ExceptionInInitializerError
> -
>
> Key: CASSANDRA-16008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16008
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tianon Gravi
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 2.2.x
>
> Attachments: CASSANDRA-16008-2.2.txt
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After the upgrade to 2.2.17, Cassandra fails to start with the following
> error:
> {noformat}
> INFO 20:28:57 JVM Arguments: [-Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false, -ea,
> -javaagent:/opt/cassandra/lib/jamm-0.3.0.jar, -XX:+CMSClassUnloadingEnabled,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42, -Xms128m, -Xmx128m,
> -Xmn32m, -XX:+HeapDumpOnOutOfMemoryError, -Xss256k,
> -XX:StringTableSize=103, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC,
> -XX:+CMSParallelRemarkEnabled, -XX:SurvivorRatio=8,
> -XX:MaxTenuringThreshold=1, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly, -XX:+UseTLAB, -XX:+PerfDisableSharedMem,
> -XX:CompileCommandFile=/etc/cassandra/hotspot_compiler,
> -XX:CMSWaitDuration=1, -XX:+CMSParallelInitialMarkEnabled,
> -XX:+CMSEdenChunksRecordAlways, -XX:CMSWaitDuration=1,
> -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC,
> -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime,
> -XX:+PrintPromotionFailure, -Xloggc:/opt/cassandra/logs/gc.log,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -Djava.net.preferIPv4Stack=true, -Dcassandra.jmx.local.port=7199,
> -XX:+DisableExplicitGC, -Djava.library.path=/opt/cassandra/lib/sigar-bin,
> -Dcassandra.libjemalloc=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1,
> -XX:OnOutOfMemoryError=kill -9 %p, -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/opt/cassandra/logs,
> -Dcassandra.storagedir=/opt/cassandra/data, -Dcassandra-foreground=yes]
> WARN 20:28:57 Unable to lock JVM memory (ENOMEM). This can result in part of
> the JVM being swapped out, especially with mmapped I/O enabled. Increase
> RLIMIT_MEMLOCK or run Cassandra as root.
> INFO 20:28:57 jemalloc seems to be preloaded from
> /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
> INFO 20:28:57 JMX is enabled to receive remote connections on port: 7199
> WARN 20:28:57 OpenJDK is not recommended. Please upgrade to the newest
> Oracle Java release
> INFO 20:28:57 Initializing SIGAR library
> INFO 20:28:57 Checked OS settings and found them configured for optimal
> performance.
> WARN 20:28:57 Directory /opt/cassandra/data/commitlog doesn't exist
> WARN 20:28:57 Directory /opt/cassandra/data/saved_caches doesn't exist
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:717)
> Caused by: java.lang.IllegalArgumentException: Bad configuration; unable to
> start server: At least one DataFileDirectory must be specified
> at
> org.apache.cassandra.config.DatabaseDescriptor.createAllDirectories(DatabaseDescriptor.java:846)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:66)
> ... 6 more
> ERROR 20:28:58 Exception encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
>
[jira] [Updated] (CASSANDRA-16008) 2.2.17 fails to start up with ExceptionInInitializerError
[
https://issues.apache.org/jira/browse/CASSANDRA-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16008:
-
Status: Ready to Commit (was: Review In Progress)
> 2.2.17 fails to start up with ExceptionInInitializerError
> -
>
> Key: CASSANDRA-16008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16008
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tianon Gravi
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 2.2.x
>
> Attachments: CASSANDRA-16008-2.2.txt
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After the upgrade to 2.2.17, Cassandra fails to start with the following
> error:
> {noformat}
> INFO 20:28:57 JVM Arguments: [-Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false, -ea,
> -javaagent:/opt/cassandra/lib/jamm-0.3.0.jar, -XX:+CMSClassUnloadingEnabled,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42, -Xms128m, -Xmx128m,
> -Xmn32m, -XX:+HeapDumpOnOutOfMemoryError, -Xss256k,
> -XX:StringTableSize=103, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC,
> -XX:+CMSParallelRemarkEnabled, -XX:SurvivorRatio=8,
> -XX:MaxTenuringThreshold=1, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly, -XX:+UseTLAB, -XX:+PerfDisableSharedMem,
> -XX:CompileCommandFile=/etc/cassandra/hotspot_compiler,
> -XX:CMSWaitDuration=1, -XX:+CMSParallelInitialMarkEnabled,
> -XX:+CMSEdenChunksRecordAlways, -XX:CMSWaitDuration=1,
> -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC,
> -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime,
> -XX:+PrintPromotionFailure, -Xloggc:/opt/cassandra/logs/gc.log,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -Djava.net.preferIPv4Stack=true, -Dcassandra.jmx.local.port=7199,
> -XX:+DisableExplicitGC, -Djava.library.path=/opt/cassandra/lib/sigar-bin,
> -Dcassandra.libjemalloc=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1,
> -XX:OnOutOfMemoryError=kill -9 %p, -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/opt/cassandra/logs,
> -Dcassandra.storagedir=/opt/cassandra/data, -Dcassandra-foreground=yes]
> WARN 20:28:57 Unable to lock JVM memory (ENOMEM). This can result in part of
> the JVM being swapped out, especially with mmapped I/O enabled. Increase
> RLIMIT_MEMLOCK or run Cassandra as root.
> INFO 20:28:57 jemalloc seems to be preloaded from
> /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
> INFO 20:28:57 JMX is enabled to receive remote connections on port: 7199
> WARN 20:28:57 OpenJDK is not recommended. Please upgrade to the newest
> Oracle Java release
> INFO 20:28:57 Initializing SIGAR library
> INFO 20:28:57 Checked OS settings and found them configured for optimal
> performance.
> WARN 20:28:57 Directory /opt/cassandra/data/commitlog doesn't exist
> WARN 20:28:57 Directory /opt/cassandra/data/saved_caches doesn't exist
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:717)
> Caused by: java.lang.IllegalArgumentException: Bad configuration; unable to
> start server: At least one DataFileDirectory must be specified
> at
> org.apache.cassandra.config.DatabaseDescriptor.createAllDirectories(DatabaseDescriptor.java:846)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:66)
> ... 6 more
> ERROR 20:28:58 Exception encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
>
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 1dd6a10b695fa02ef44a68d6299c63075eb8a4ff Merge: fb49ab2 85338f7 Author: Brandon Williams AuthorDate: Wed Sep 23 10:06:16 2020 -0500 Merge branch 'cassandra-3.11' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (492009a -> 85338f7)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 492009a Merge branch 'cassandra-3.0' into cassandra-3.11 new ed80055 Fix ExceptionInInitializerError when data_file_directories is not set new fa7a258 Merge branch 'cassandra-2.2' into cassandra-3.0 new 85338f7 Merge branch 'cassandra-3.0' into cassandra-3.11 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (fb49ab2 -> 1dd6a10)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from fb49ab2 Fix test failure caused by CASSANDRA-16102 new ed80055 Fix ExceptionInInitializerError when data_file_directories is not set new fa7a258 Merge branch 'cassandra-2.2' into cassandra-3.0 new 85338f7 Merge branch 'cassandra-3.0' into cassandra-3.11 new 1dd6a10 Merge branch 'cassandra-3.11' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (2cde7a7 -> fa7a258)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 2cde7a7 Merge branch 'cassandra-2.2' into cassandra-3.0 new ed80055 Fix ExceptionInInitializerError when data_file_directories is not set new fa7a258 Merge branch 'cassandra-2.2' into cassandra-3.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit fa7a258f7b2c59a8adf07332fa51914919e30fcd Merge: 2cde7a7 ed80055 Author: Brandon Williams AuthorDate: Wed Sep 23 10:05:59 2020 -0500 Merge branch 'cassandra-2.2' into cassandra-3.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-2.2 updated: Fix ExceptionInInitializerError when data_file_directories is not set
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-2.2
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-2.2 by this push:
new ed80055 Fix ExceptionInInitializerError when data_file_directories is
not set
ed80055 is described below
commit ed8005552376188abb81894fb8c9c611ebd6379a
Author: Erick Ramirez
AuthorDate: Wed Sep 23 21:14:54 2020 +1000
Fix ExceptionInInitializerError when data_file_directories is not set
Patch by Erick Ramirez, reviewed by brandonwilliams for CASSANDRA-16008
---
CHANGES.txt | 1 +
src/java/org/apache/cassandra/config/DatabaseDescriptor.java | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 9cccd7c..73e9ba9 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.19
+ * Fix ExceptionInInitializerError when data_file_directories is not set
(CASSANDRA-16008)
2.2.18
* Fix CQL parsing of collections when the column type is reversed
(CASSANDRA-15814)
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 41a09e9..1c37459 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -561,7 +561,7 @@ public class DatabaseDescriptor
throw new ConfigurationException("saved_caches_directory is
missing and -Dcassandra.storagedir is not set", false);
conf.saved_caches_directory += File.separator + "saved_caches";
}
-if (conf.data_file_directories == null)
+if (conf.data_file_directories == null ||
conf.data_file_directories.length == 0)
{
String defaultDataDir = System.getProperty("cassandra.storagedir",
null);
if (defaultDataDir == null)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 85338f71715baf92327b559b053afc2b4664085f Merge: 492009a fa7a258 Author: Brandon Williams AuthorDate: Wed Sep 23 10:06:10 2020 -0500 Merge branch 'cassandra-3.0' into cassandra-3.11 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15823) Support for networking via identity instead of IP
[ https://issues.apache.org/jira/browse/CASSANDRA-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200879#comment-17200879 ] Jeff Jirsa commented on CASSANDRA-15823: Will note that CASSANDRA-10134 likely solves some of the things I describe, and my knowledge was out of date because CASSANDRA-10134 landed in a version I don't pay attention to. > Support for networking via identity instead of IP > - > > Key: CASSANDRA-15823 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15823 > Project: Cassandra > Issue Type: Improvement >Reporter: Christopher Bradford >Priority: Normal > Labels: kubernetes > Attachments: consul-mesh-gateways.png, > istio-multicluster-with-gateways.svg, linkerd-service-mirroring.svg > > > TL;DR: Instead of mapping host ids to IPs, use hostnames. This allows > resolution to different IP addresses per DC that may then be forwarded to > nodes on remote networks without requiring node to node IP connectivity for > cross-dc links. > > This approach should not affect existing deployments as those could continue > to use IPs as the hostname and skip resolution. > > With orchestration platforms like Kubernetes and the usage of ephemeral > containers in environments today we should consider some changes to how we > handle the tracking of nodes and their network location. Currently we > maintain a mapping between host ids and IP addresses. > > With traditional infrastructure, if a node goes down it, usually, comes back > up with the same IP. In some environments this contract may be explicit with > virtual IPs that may move between hosts. In newer deployments, like on > Kubernetes, this contract is not possible. Pods (analogous to nodes) are > assigned an IP address at start time. Should the pod be restarted or > scheduled on a different host there is no guarantee we would have the same > IP. Cassandra is protected here as we already have logic in place to update > peers when we come up with the same host id, but a different IP address. > > There are ways to get Kubernetes to assign a specific IP per Pod. Most > recommendations involve the use of a service per pod. Communication with the > fixed service IP would automatically forward to the associated pod, > regardless of address. We _could_ use this approach, but it seems like this > would needlessly create a number of extra resources in our k8s cluster to get > around the problem. Which, to be fair, doesn't seem like much of a problem > with the aforementioned mitigations built into C*. > > So what is the _actual_ problem? *Cross-region, cross-cloud, > hybrid-deployment connectivity between pods is a pain.* This can be solved > with significant investment by those who want to deploy these types of > topologies. You can definitely configure connectivity between clouds over > dedicated connections, or VPN tunnels. With a big chunk of time insuring that > pod to pod connectivity just works even if those pods are managed by separate > control planes, but that again requires time and talent. There are a number > of edge cases to support between the ever so slight, but very important, > differences in cloud vendor networks. > > Recently there have been a number of innovations that aid in the deployment > and operation of these types of applications on Kubernetes. Service meshes > support distributed microservices running across multiple k8s cluster control > planes in disparate networks. Instead of directly connecting to IP addresses > of remote services instead they use a hostname. With this approach, hostname > traffic may then be routed to a proxy that sends traffic over the WAN > (sometimes with mTLS) to another proxy pod in the remote cluster which then > forwards the data along to the correct pod in that network. (See attached > diagrams) > > Which brings us to the point of this ticket. Instead of mapping host ids to > IPs, use hostnames (and update the underlying address periodically instead of > caching indefinitely). This allows resolution to different IP addresses per > DC (k8s cluster) that may then be forwarded to nodes (pods) on remote > networks (k8s clusters) without requiring node to node (pod to pod) IP > connectivity between them. Traditional deployments can still function like > they do today (even if operators opt to keep using IPs as identifiers instead > of hostnames). This proxy approach is then enabled like those we see in > service meshes. > > _Notes_ > C* already has the concept of broadcast addresses vs those which are bound on > the node. This approach _could_ be leveraged to provide the behavior we're > looking for, but then the broadcast values would need to be pre-computed > _*and match*_ across all k8s control planes. By
[jira] [Commented] (CASSANDRA-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200876#comment-17200876 ] Berenguer Blasi commented on CASSANDRA-16121: - [~e.dimitrova] squashed and you can see in the previous message low, mid and high CI runs. Feel free to butcher it :-) > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- This message was sent by Atlassian Jira (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-16138) Refactor Local Ring Management
[ https://issues.apache.org/jira/browse/CASSANDRA-16138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200863#comment-17200863 ] Paulo Motta commented on CASSANDRA-16138: - For those interested, an initial WIP prototype of the refactoring is available on this branch: [pauloricardomg/tokenmetadata-refactor-wip|https://github.com/pauloricardomg/cassandra/tree/tokenmetadata-refactor-wip]. Virtual Node Lifecycle: !vnode-lifecyle.png! The refactoring is mostly contained in the [a.o.c.ring package|https://github.com/pauloricardomg/cassandra/tree/tokenmetadata-refactor-wip/src/java/org/apache/cassandra/ring]. Below is a short description of each relevant class: * [RingManager|https://github.com/pauloricardomg/cassandra/blob/tokenmetadata-refactor-wip/src/java/org/apache/cassandra/ring/RingManager.java] : Receives cluster membership updates from gossip and maintains an immutable snapshot of the current local ring membership view. * [RingSnapshot|https://github.com/pauloricardomg/cassandra/blob/tokenmetadata-refactor-wip/src/java/org/apache/cassandra/ring/RingSnapshot.java] : an immutable local view of the current cluster ring membership state. * [VirtualNode|https://github.com/pauloricardomg/cassandra/blob/tokenmetadata-refactor-wip/src/java/org/apache/cassandra/ring/token/VirtualNode.java] : an immutable Token-Owner relationship and its current state. * [RingOverlay|https://github.com/pauloricardomg/cassandra/blob/tokenmetadata-refactor-wip/src/java/org/apache/cassandra/ring/RingOverlay.java]: a token routing overlay on top of a RingSnapshot. * [MultiDataCenterRingOverlay|https://github.com/pauloricardomg/cassandra/blob/tokenmetadata-refactor-wip/src/java/org/apache/cassandra/ring/MultiDatacenterRingOverlay.java]: the RingOverlay generated by NetworkTopologyStrategy. * [RingOverlayStableTest|https://github.com/pauloricardomg/cassandra/blob/tokenmetadata-refactor-wip/test/unit/org/apache/cassandra/ring/RingOverlayStableTest.java]: ensure parity between MultiDataCenterRingOverlay and legacy TokenMetadata/NTS on a stable ring. * [RingOverlayStableTest|https://github.com/pauloricardomg/cassandra/blob/tokenmetadata-refactor-wip/test/unit/org/apache/cassandra/ring/RingOverlayBootstrapTest.java] : ensure parity between MultiDataCenterRingOverlay and legacy TokenMetadata/NTS on a ring with bootstrapping nodes. Current TODO is to finish mapping all current legacy states to the vnode lifecycle above and testing to ensure parity with the current implementation. > Refactor Local Ring Management > -- > > Key: CASSANDRA-16138 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16138 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership, Feature/Virtual Nodes, > Legacy/Distributed Metadata >Reporter: Paulo Motta >Assignee: Paulo Motta >Priority: Normal > Attachments: vnode-lifecyle.png > > > Token ring management is one of the most critical parts of Cassandra, yet one > of the most overlooked. Some of the problems include but are not limited to: > * Complexity (ie. [pending range > calculation|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/TokenMetadata.java#L878]) > > * Inefficiency (ie. [pending range > calculation|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/TokenMetadata.java#L878], > > [AbstractReplicationStrategy.getAddressReplicas|https://github.com/apache/cassandra/blob/33eada06a6dd3529da644377dba180795f522176/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L233]) > * Prone to race conditions (ie. > [here|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/ReplicaLayout.java#L198]) > * Poor modularity and consistency (ie. natural replicas computed from > [NetworkTopologyStrategy|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java] > and pending replicas computed from > [TokenMetadata|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1271]) > * Insufficient testing (due to complexity and poor modularity) > These limitations make it difficult to reliably fix bugs like properly > supporting node replacement with the same IP address (CASSANDRA-12344), add > improvements such as safe ring membership changes, support for networking via > identity instead of IP (CASSANDRA-15823) or add new features such as dynamic > virtual nodes. > This ticket aims at refactoring the ring management sub-module (namely > TokenMetadata
[jira] [Updated] (CASSANDRA-16138) Refactor Local Ring Management
[ https://issues.apache.org/jira/browse/CASSANDRA-16138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16138: Attachment: vnode-lifecyle.png > Refactor Local Ring Management > -- > > Key: CASSANDRA-16138 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16138 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership, Feature/Virtual Nodes, > Legacy/Distributed Metadata >Reporter: Paulo Motta >Assignee: Paulo Motta >Priority: Normal > Attachments: vnode-lifecyle.png > > > Token ring management is one of the most critical parts of Cassandra, yet one > of the most overlooked. Some of the problems include but are not limited to: > * Complexity (ie. [pending range > calculation|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/TokenMetadata.java#L878]) > > * Inefficiency (ie. [pending range > calculation|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/TokenMetadata.java#L878], > > [AbstractReplicationStrategy.getAddressReplicas|https://github.com/apache/cassandra/blob/33eada06a6dd3529da644377dba180795f522176/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L233]) > * Prone to race conditions (ie. > [here|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/ReplicaLayout.java#L198]) > * Poor modularity and consistency (ie. natural replicas computed from > [NetworkTopologyStrategy|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java] > and pending replicas computed from > [TokenMetadata|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1271]) > * Insufficient testing (due to complexity and poor modularity) > These limitations make it difficult to reliably fix bugs like properly > supporting node replacement with the same IP address (CASSANDRA-12344), add > improvements such as safe ring membership changes, support for networking via > identity instead of IP (CASSANDRA-15823) or add new features such as dynamic > virtual nodes. > This ticket aims at refactoring the ring management sub-module (namely > TokenMetadata and related classes) to address most of its current limitations > in order to support further improvements and new features. > Some of the requirements of the proposed refactoring are: > # Make node-local ring representation fully immutable and snapshottable. > # Add content-based versioning to uniquely identify a ring snapshot > throughout the cluster. > # Make token ring management vnode-centric to support membership operations > on individual tokens and simplify token assignment calculations. > # Primarily identify ring endpoints by node ID to decouple a node’s identity > from its IP address. > # Add a local publish/subscribe mechanism for ring change notifications, so > other modules can subscribe to it and receive the newest snapshot of the ring > after membership changes. > # Add testing framework to verify correctness of ring membership operations. > # Ensure the refactored sub-module does not change current behavior via > comprehensive testing. -- This message was sent by Atlassian Jira (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-16142) Enable Moving Tokens on Nodes with Multiple Tokens
Paulo Motta created CASSANDRA-16142: --- Summary: Enable Moving Tokens on Nodes with Multiple Tokens Key: CASSANDRA-16142 URL: https://issues.apache.org/jira/browse/CASSANDRA-16142 Project: Cassandra Issue Type: Improvement Components: Cluster/Membership, Feature/Virtual Nodes Reporter: Paulo Motta Currently it’s only possible to move tokens on nodes with single tokens, but the protocol introduced on CASSANDRA-16139 makes this a possibility on nodes with multiple tokens. This may be useful to perform ring rebalancing operations. A pseudo-code for the move token operation is available [here|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-move-py]. This ticket is to enable this functionality to users via ringtool (CASSANDRA-16140). -- This message was sent by Atlassian Jira (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-16141) Enable Adding and Removing Tokens to a Node (Dynamic Virtual Nodes)
Paulo Motta created CASSANDRA-16141: --- Summary: Enable Adding and Removing Tokens to a Node (Dynamic Virtual Nodes) Key: CASSANDRA-16141 URL: https://issues.apache.org/jira/browse/CASSANDRA-16141 Project: Cassandra Issue Type: New Feature Components: Cluster/Membership, Feature/Virtual Nodes Reporter: Paulo Motta The new ring membership protocol added on CASSANDRA-16139 allows adding and removing tokens to an existing cluster node. This allows operators to increase/reduce the number of virtual nodes per node on a live cluster. Furthermore this also enables Incremental Bootstrap (CASSANDRA-8494). This ticket is to enable this functionality to users via ringtool (CASSANDRA-16140). The pseudo-code for each operation is available below: * [add token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-bootstrap-py] (essentially similar to bootstrap) * [remove token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_token-py) -- This message was sent by Atlassian Jira (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-16140) Add Tool to Perform Ring Membership Changes
Paulo Motta created CASSANDRA-16140: --- Summary: Add Tool to Perform Ring Membership Changes Key: CASSANDRA-16140 URL: https://issues.apache.org/jira/browse/CASSANDRA-16140 Project: Cassandra Issue Type: Improvement Components: Cluster/Membership, Tool/nodetool Reporter: Paulo Motta It would be nice to provide a specific tool (ie. ringtool) to allow operators to perform safe ring membership operations (CASSANDRA-16139) such as removing failed nodes, aborting failed ring update proposals, adding or removing tokens to a host, moving tokens etc. While we could provide this functionality via nodetool as done currently, I think it would be better to have an exclusive tool for this to separate concerns. Furthermore we can add specific permissions to this tool that are different from nodetool to allow only authorized operators to perform ring membership changes. We should support the current methods available on nodetool (such as nodetool move, nodetool join, nodetool bootstrap resume, etc) and deprecate them on nodetool asking users to use the new tool moving forward. -- This message was sent by Atlassian Jira (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-16139) Safe Ring Membership Protocol
Paulo Motta created CASSANDRA-16139: --- Summary: Safe Ring Membership Protocol Key: CASSANDRA-16139 URL: https://issues.apache.org/jira/browse/CASSANDRA-16139 Project: Cassandra Issue Type: Improvement Components: Cluster/Gossip, Cluster/Membership Reporter: Paulo Motta Assignee: Paulo Motta This ticket presents a practical protocol for performing safe ring membership updates in Cassandra. This protocol will enable reliable concurrent ring membership updates. The proposed protocol is composed of the following macro-steps: *PROPOSE:* An initiator node wanting to make updates to the current ring structure (such as joining, leaving the ring or changing token assignments) must propose the change to the other members of the ring (cohort). *ACCEPT:* Upon receiving a proposal the other ring members determine if the change is compatible with their local version of the ring, and if so, they promise to accept the change proposed by the initiator. The ring members do not accept proposals if they had already promised to honor another proposal, to avoid conflicting ring membership updates. *COMMIT:* Once the initiator receives acceptances from all the nodes in the cohort, it commits the proposal by broadcasting the proposed ring delta via gossip. Upon receiving these changes, the other members of the cohort apply the delta to their local version of the ring and broadcast their new computed version via gossip. The initiator concludes the ring membership update operation by checking that all nodes agree on the new proposed version. *ABORT:* A proposal not accepted by all members of the cohort may be automatically aborted by the initiator or manually via a command line tool. For simplicity the protocol above requires that all nodes are up during the proposal step, but it should be possible to optimize it to require only a quorum of nodes up to perform ring changes. A python pseudo-code of the protocol is available [here|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-safe_ring_membership-py]. With the abstraction above it becomes very simple to perform ring change operations: * [bootstrap|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-bootstrap-py] * [replace|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-replace-py] * [move|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-move-py] * [remove node|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_node-py] * [remove token|https://gist.github.com/pauloricardomg/1930c8cf645aa63387a57bb57f79a0f7#file-remove_token-py] h4. Token Ring Data Structure The token ring data structure can be seen as a [Delta State Replicated Data Type|https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type#State-based_CRDTs] (Delta CRDT) containing the state of all (virtual) nodes in the cluster where updates to the ring are operations on this CRDT. Each member publishes its latest local accepted state (delta state) via gossip and the union of all delta states comprise the global ring state. The delta state must be commutative and idempotent to ensure all nodes will eventually reach the same global state no matter the order received. The content-addressed fingerprint of the global ring state uniquely identifies the ring version and provides a simple way to verify agreement between nodes in the cluster. Any change to the ring membership must be agreed using the described protocol, ensuring that both conditions are met: * All nodes have the same current view of the cluster before the update (verified via the ring version fingerprint). * All nodes have agreed to make the exact same update and not accept any other update before the current proposed update is committed or aborted. h4. Ring Convergence Time Assuming there are no network partitions, the ring membership convergence time will be dominated by the commit step since that is performed via gossip broadcast. The gossip broadcast is performed by sending the ring delta to the seed nodes, since other nodes will contact seed nodes with a #seeds / #nodes probability. This will define an upper bound for the maximum time it takes to propagate a ring update that was accepted by all members of the ring. On a cluster with 10% of the nodes as seeds, it’s guaranteed that a ring membership update operation will not take much longer than 10 seconds with the current gossip interval of 1 second. A simple way to reduce this upper bound is to make cohort acceptors gossip more frequently with seeds when there are pending ring membership updates. h4. Failure Modes - Concurrent Proposals: -- Concurrent initiators will not gather sufficient promises from all cohort members, and thus, will not succeed.
[jira] [Created] (CASSANDRA-16138) Refactor Local Ring Management
Paulo Motta created CASSANDRA-16138: --- Summary: Refactor Local Ring Management Key: CASSANDRA-16138 URL: https://issues.apache.org/jira/browse/CASSANDRA-16138 Project: Cassandra Issue Type: Improvement Components: Cluster/Membership, Feature/Virtual Nodes, Legacy/Distributed Metadata Reporter: Paulo Motta Assignee: Paulo Motta Token ring management is one of the most critical parts of Cassandra, yet one of the most overlooked. Some of the problems include but are not limited to: * Complexity (ie. [pending range calculation|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/TokenMetadata.java#L878]) * Inefficiency (ie. [pending range calculation|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/TokenMetadata.java#L878], [AbstractReplicationStrategy.getAddressReplicas|https://github.com/apache/cassandra/blob/33eada06a6dd3529da644377dba180795f522176/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L233]) * Prone to race conditions (ie. [here|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/ReplicaLayout.java#L198]) * Poor modularity and consistency (ie. natural replicas computed from [NetworkTopologyStrategy|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java] and pending replicas computed from [TokenMetadata|https://github.com/apache/cassandra/blob/8ba163f25a56cb507e621b89b6928c2aef0ecc57/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1271]) * Insufficient testing (due to complexity and poor modularity) These limitations make it difficult to reliably fix bugs like properly supporting node replacement with the same IP address (CASSANDRA-12344), add improvements such as safe ring membership changes, support for networking via identity instead of IP (CASSANDRA-15823) or add new features such as dynamic virtual nodes. This ticket aims at refactoring the ring management sub-module (namely TokenMetadata and related classes) to address most of its current limitations in order to support further improvements and new features. Some of the requirements of the proposed refactoring are: # Make node-local ring representation fully immutable and snapshottable. # Add content-based versioning to uniquely identify a ring snapshot throughout the cluster. # Make token ring management vnode-centric to support membership operations on individual tokens and simplify token assignment calculations. # Primarily identify ring endpoints by node ID to decouple a node’s identity from its IP address. # Add a local publish/subscribe mechanism for ring change notifications, so other modules can subscribe to it and receive the newest snapshot of the ring after membership changes. # Add testing framework to verify correctness of ring membership operations. # Ensure the refactored sub-module does not change current behavior via comprehensive testing. -- This message was sent by Atlassian Jira (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-16137) Improve Ring Membership Management
Paulo Motta created CASSANDRA-16137: --- Summary: Improve Ring Membership Management Key: CASSANDRA-16137 URL: https://issues.apache.org/jira/browse/CASSANDRA-16137 Project: Cassandra Issue Type: Epic Components: Cluster/Membership, Consistency/Bootstrap and Decommission, Feature/Virtual Nodes Reporter: Paulo Motta Assignee: Paulo Motta This is an umbrella ticket to group tasks to improve the status quo of token ring management. The plan is to refactor and enhance the current ring management sub-module to ultimately support advanced ring membership operations such as reliable concurrent ring membership changes and dynamic virtual nodes. A Cassandra Enhancement Proposal (CEP) will be submitted to the community with a detailed proposal of the tickets contained in this epic. -- This message was sent by Atlassian Jira (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-15160) Add flag to ignore unreplicated keyspaces during repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200837#comment-17200837
]
Marcus Eriksson commented on CASSANDRA-15160:
-
ah nice catches, pushed fixes to the branches above + rebased the old dtest
branch with the log greping fix.
running cci with that dtest branch here:
[3.0|https://app.circleci.com/pipelines/github/krummas/cassandra/538/workflows/c3cc5064-7c70-4873-8af6-268560883825]
[3.11|https://app.circleci.com/pipelines/github/krummas/cassandra/540/workflows/83c6341a-b386-473d-ae71-bbf292fbc0c1]
[trunk|https://app.circleci.com/pipelines/github/krummas/cassandra/539/workflows/a2cd8cc2-2072-49b7-a63e-5a99063a0ec9]
> Add flag to ignore unreplicated keyspaces during repair
> ---
>
> Key: CASSANDRA-15160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15160
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> When a repair is triggered on a node in 'dc2' for a keyspace with replication
> factor {'dc1':3, 'dc2':0} we just ignore the repair in versions < 3. In 3.0+
> we fail the repair to make sure the operator does not think the keyspace is
> fully repaired.
> There might be tooling that relies on the old behaviour though, so we should
> add a flag to ignore those unreplicated keyspaces
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (fef03bd -> 74c3518)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard fef03bd generate docs for 06395edd new 74c3518 generate docs for 06395edd This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (fef03bd) \ N -- N -- N refs/heads/asf-staging (74c3518) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/feed.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16128) Jenkins: dsl for website build, logging repo SHAs, and using nightlies.a.o instead of archiving
[ https://issues.apache.org/jira/browse/CASSANDRA-16128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200832#comment-17200832 ] Michael Semb Wever commented on CASSANDRA-16128: Committed fixes (to previous comment) in [4ac6686480120557e5b55e63d127264adc88d75b|https://github.com/apache/cassandra-builds/commit/4ac6686480120557e5b55e63d127264adc88d75b]. > Jenkins: dsl for website build, logging repo SHAs, and using nightlies.a.o > instead of archiving > --- > > Key: CASSANDRA-16128 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16128 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0-beta > > > Jenkins improvements > 1. Add the cassandra-website job into cassandra_job_dsl.seed.groovy (so we > don't lose it next time the Jenkins master is corrupted) > 2. Print the SHAs of the different git repos used during the build process. > Also store them in the .head files (so the pipeline can print them out too). > 3. Instead of archiving artefacts, ssh them to > https://nightlies.apache.org/cassandra/ > (Disk usage on agents is largely under control, but disk usage on master was > the new problem. The suspicion here is the Cassandra-*-artifact's artefacts > was the disk usage culprit, though we have to evidence to support it.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: ninja-fix: website dsl (prebuild cleanup wrapper required, not scm extension clean/wipe)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/master by this push:
new 62085c6 ninja-fix: website dsl (prebuild cleanup wrapper required,
not scm extension clean/wipe)
62085c6 is described below
commit 62085c62a3944af567e97ae5f330dbc8552f7d52
Author: Mick Semb Wever
AuthorDate: Wed Sep 23 15:34:44 2020 +0200
ninja-fix: website dsl (prebuild cleanup wrapper required, not scm
extension clean/wipe)
---
jenkins-dsl/cassandra_job_dsl_seed.groovy | 1 +
1 file changed, 1 insertion(+)
diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index 8c7ebfc..cc40ae3 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -948,6 +948,7 @@ job('cassandra-website') {
artifactNumToKeep(10)
}
wrappers {
+preBuildCleanup()
timeout {
noActivity(300)
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (37527a8 -> fef03bd)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 37527a8 generate docs for 06395edd new fef03bd generate docs for 06395edd This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (37527a8) \ N -- N -- N refs/heads/asf-staging (fef03bd) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/feed.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: Follow-up to CASSANDRA-16128. Fixes printing of *.head files, website dsl, and removes javadoc->nightlies uploads.
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/master by this push:
new 4ac6686 Follow-up to CASSANDRA-16128. Fixes printing of *.head files,
website dsl, and removes javadoc->nightlies uploads.
4ac6686 is described below
commit 4ac6686480120557e5b55e63d127264adc88d75b
Author: Mick Semb Wever
AuthorDate: Wed Sep 23 15:01:44 2020 +0200
Follow-up to CASSANDRA-16128. Fixes printing of *.head files, website dsl,
and removes javadoc->nightlies uploads.
ref:
https://issues.apache.org/jira/browse/CASSANDRA-16128?focusedCommentId=17199475=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17199475
---
jenkins-dsl/cassandra_job_dsl_seed.groovy | 24 +++-
jenkins-dsl/cassandra_pipeline.groovy | 4 ++--
2 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index 50e0102..8c7ebfc 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -137,10 +137,6 @@ matrixJob('Cassandra-template-artifacts') {
sourceFiles("build/apache-cassandra-*.tar.gz,
build/apache-cassandra-*.jar, build/apache-cassandra-*.pom,
build/cassandra*.deb, build/cassandra*.rpm")
remoteDirectory("cassandra/\${JOB_NAME}/\${BUILD_NUMBER}/")
}
-transferSet {
-sourceFiles("build/javadoc/**/*")
-remoteDirectory("cassandra/\${JOB_NAME}/")
-}
}
failOnError(false)
}
@@ -308,10 +304,6 @@ matrixJob('Cassandra-template-dtest-matrix') {
sourceFiles("**/nosetests.xml,**/test_stdout.txt,**/ccm_logs.tar.xz")
remoteDirectory("cassandra/\${JOB_NAME}/\${BUILD_NUMBER}/")
}
-transferSet {
-sourceFiles("build/javadoc/**/*")
-remoteDirectory("cassandra/\${JOB_NAME}/")
-}
}
failOnError(false)
}
@@ -627,10 +619,6 @@ matrixJob('Cassandra-devbranch-artifacts') {
sourceFiles("build/apache-cassandra-*.tar.gz,
build/apache-cassandra-*.jar, build/apache-cassandra-*.pom,
build/cassandra*.deb, build/cassandra*.rpm")
remoteDirectory("cassandra/\${JOB_NAME}/\${BUILD_NUMBER}/")
}
-transferSet {
-sourceFiles("build/javadoc/**/*")
-remoteDirectory("cassandra/\${JOB_NAME}/")
-}
}
failOnError(false)
}
@@ -697,7 +685,7 @@ testTargets.each {
git clean -xdff ;
git clone --depth 1 --single-branch -b ${buildsBranch}
${buildsRepo} ;
echo "cassandra-builds at: `git -C cassandra-builds log -1
--pretty=format:'%h %an %ad %s'`" ;
-echo "Cassandra-devbranch-${targetName}: `git log -1
--pretty=format:'%h %an %ad %s'`" > Cassandra-devbranch-${targetName}.head ;
+echo "Cassandra-devbranch-${targetName} cassandra: `git
log -1 --pretty=format:'%h %an %ad %s'`" >
Cassandra-devbranch-${targetName}.head ;
""")
shell("./cassandra-builds/build-scripts/cassandra-test.sh
${targetName}")
}
@@ -803,7 +791,7 @@ dtestTargets.each {
git clean -xdff ;
git clone --depth 1 --single-branch -b ${buildsBranch}
${buildsRepo} ;
echo "cassandra-builds at: `git -C cassandra-builds log -1
--pretty=format:'%h %an %ad %s'`" ;
-echo "Cassandra-devbranch-${targetName}: `git log -1
--pretty=format:'%h %an %ad %s'`" > Cassandra-devbranch-${targetName}.head ;
+echo "Cassandra-devbranch-${targetName} cassandra: `git
log -1 --pretty=format:'%h %an %ad %s'`" >
Cassandra-devbranch-${targetName}.head ;
""")
shell("sh ./cassandra-builds/docker/jenkins/jenkinscommand.sh
\$REPO \$BRANCH \$DTEST_REPO \$DTEST_BRANCH ${buildsRepo} ${buildsBranch}
\$DOCKER_IMAGE ${targetName} \${split}/${splits}")
}
@@ -826,7 +814,7 @@ dtestTargets.each {
postBuildTask {
task('.', """
echo "Cleaning project…" ; git clean -xdff ;
-echo "Pruning docker…" ; if pgrep -af jenkinscommand.sh;
then system prune -f --filter "until=${maxJobHours}h"; else docker system prune
-f --volumes ; fi;
+echo "Pruning docker…" ; if pgrep -af jenkinscommand.sh;
then docker system prune -f --filter "until=${maxJobHours}h"; else docker
system prune -f --volumes ; fi;
echo "Reporting disk
[jira] [Comment Edited] (CASSANDRA-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17199912#comment-17199912 ] Berenguer Blasi edited comment on CASSANDRA-16121 at 9/23/20, 12:26 PM: I added that new executor and updated the files. I will now run small, medium and high to make sure the 3 still work and then we should be able to merge. - Small: [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/121/workflows/7d278dce-3f13-46f0-bde2-79dcf61c6ad1] [j8|https://app.circleci.com/pipelines/github/bereng/cassandra/121/workflows/6bba245b-ac4d-426a-9041-c90571070d51]: OOM on the final test report which is a known problem, otherwise LGTM. - Medium [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/123/workflows/16aa4612-4a27-4bea-bebf-97efeef56353] [j8|https://app.circleci.com/pipelines/github/bereng/cassandra/123/workflows/c261dcdb-d878-4d66-afa6-5791d01dc45d] Failures look unrelated or known to fail. LGTM - High [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/125/workflows/69b234d0-dc70-4dd7-850a-23cb20ba4891] [j8|https://app.circleci.com/pipelines/github/bereng/cassandra/125/workflows/2e2143f0-6750-4579-b301-9c6747df1aa4] Same as prevoius. LGTM was (Author: bereng): I added that new executor and updated the files. I will now run small, medium and high to make sure the 3 still work and then we should be able to merge. - Small: [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/121/workflows/7d278dce-3f13-46f0-bde2-79dcf61c6ad1] [j8|https://app.circleci.com/pipelines/github/bereng/cassandra/121/workflows/6bba245b-ac4d-426a-9041-c90571070d51]: OOM on the final test report which is a known problem, otherwise lgtm. - Medium [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/123/workflows/16aa4612-4a27-4bea-bebf-97efeef56353] [j8|https://app.circleci.com/pipelines/github/bereng/cassandra/123/workflows/c261dcdb-d878-4d66-afa6-5791d01dc45d] Failures look unrelated or known to fail. LGTM - High > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- This message was sent by Atlassian 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 master updated: remove redundant params wait_for_binary_proto=True and wait_other_notice=True from Cluster.start calls
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git The following commit(s) were added to refs/heads/master by this push: new 4acae58 remove redundant params wait_for_binary_proto=True and wait_other_notice=True from Cluster.start calls 4acae58 is described below commit 4acae58e0c0bbe665f5a1c38aa24a7b4f4ad06d1 Author: Christopher Lambert AuthorDate: Wed Sep 23 11:01:24 2020 +0200 remove redundant params wait_for_binary_proto=True and wait_other_notice=True from Cluster.start calls Since https://github.com/riptano/ccm/pull/561 ccm Cluster.start() defaults to: wait_for_binary_proto=True wait_other_notice=True Since their presence could suggest that these are non-default values, we clean up the code by removing them. patch by Christopher Lambert; reviewed by Mick Semb Wever --- README.md| 1 - auditlog_test.py | 10 ++--- auth_join_ring_false_test.py | 2 +- auth_test.py | 14 +++--- batch_test.py| 2 +- bootstrap_test.py| 28 ++-- cdc_test.py | 2 +- cfid_test.py | 2 +- compaction_test.py | 30 ++--- compression_test.py | 8 ++-- configuration_test.py| 6 +-- consistency_test.py | 28 ++-- consistent_bootstrap_test.py | 2 +- counter_test.py | 2 +- cql_test.py | 16 +++ cql_tracing_test.py | 2 +- cqlsh_tests/test_cqlsh.py| 73 cqlsh_tests/test_cqlsh_copy.py | 2 +- delete_insert_test.py| 2 +- deletion_test.py | 2 +- disk_balance_test.py | 16 +++ fqltool_test.py | 6 +-- hintedhandoff_test.py| 2 +- jmx_test.py | 10 ++--- legacy_sstables_test.py | 2 +- materialized_views_test.py | 6 +-- metadata_test.py | 2 +- nodetool_test.py | 6 +-- offline_tools_test.py| 24 +-- paging_test.py | 2 +- paxos_test.py| 8 ++-- pending_range_test.py| 2 +- pushed_notifications_test.py | 12 +++--- read_failures_test.py| 2 +- read_repair_test.py | 9 ++-- rebuild_test.py | 6 +-- refresh_test.py | 2 +- repair_tests/deprecated_repair_test.py | 2 +- repair_tests/incremental_repair_test.py | 4 +- repair_tests/repair_test.py | 42 +- replication_test.py | 10 ++--- secondary_indexes_test.py| 6 +-- snapshot_test.py | 4 +- snitch_test.py | 2 +- sstable_generation_loading_test.py | 4 +- sstablesplit_test.py | 4 +- sstableutil_test.py | 4 +- streaming_test.py| 2 +- stress_tool_test.py | 4 +- thrift_hsha_test.py | 2 +- thrift_test.py | 3 +- token_generator_test.py | 2 +- topology_test.py | 12 +++--- transient_replication_ring_test.py | 2 +- transient_replication_test.py| 2 +- ttl_test.py | 6 +-- upgrade_tests/compatibility_flag_test.py | 4 +- upgrade_tests/cql_tests.py | 2 +- upgrade_tests/upgrade_base.py| 2 +- user_types_test.py | 2 +- write_failures_test.py | 2 +- 61 files changed, 236 insertions(+), 244 deletions(-) diff --git a/README.md b/README.md index a6be874..4e64587 100644 --- a/README.md +++ b/README.md @@ -101,7 +101,6 @@ JAVA7_HOME and JAVA8_HOME, respectively. Writing Tests - -- Most of the time when you start a cluster with `cluster.start()`, you'll want to pass in `wait_for_binary_proto=True` so the call blocks until the cluster is ready to accept CQL connections. We tried setting this to `True` by default once, but the problems caused there (e.g. when it waited the full timeout time on a node that was deliberately down) were more unpleasant and more difficult to debug than the problems caused by having it `False` by default. - If you're using JMX via [the `tools.jmxutils` module](tools/jmxutils.py), make sure to call `remove_perf_disable_shared_mem` on the
[jira] [Updated] (CASSANDRA-16008) 2.2.17 fails to start up with ExceptionInInitializerError
[
https://issues.apache.org/jira/browse/CASSANDRA-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16008:
--
Fix Version/s: (was: 2.2.18)
> 2.2.17 fails to start up with ExceptionInInitializerError
> -
>
> Key: CASSANDRA-16008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16008
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tianon Gravi
>Assignee: Erick Ramirez
>Priority: Normal
> Attachments: CASSANDRA-16008-2.2.txt
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After the upgrade to 2.2.17, Cassandra fails to start with the following
> error:
> {noformat}
> INFO 20:28:57 JVM Arguments: [-Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false, -ea,
> -javaagent:/opt/cassandra/lib/jamm-0.3.0.jar, -XX:+CMSClassUnloadingEnabled,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42, -Xms128m, -Xmx128m,
> -Xmn32m, -XX:+HeapDumpOnOutOfMemoryError, -Xss256k,
> -XX:StringTableSize=103, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC,
> -XX:+CMSParallelRemarkEnabled, -XX:SurvivorRatio=8,
> -XX:MaxTenuringThreshold=1, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly, -XX:+UseTLAB, -XX:+PerfDisableSharedMem,
> -XX:CompileCommandFile=/etc/cassandra/hotspot_compiler,
> -XX:CMSWaitDuration=1, -XX:+CMSParallelInitialMarkEnabled,
> -XX:+CMSEdenChunksRecordAlways, -XX:CMSWaitDuration=1,
> -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC,
> -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime,
> -XX:+PrintPromotionFailure, -Xloggc:/opt/cassandra/logs/gc.log,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -Djava.net.preferIPv4Stack=true, -Dcassandra.jmx.local.port=7199,
> -XX:+DisableExplicitGC, -Djava.library.path=/opt/cassandra/lib/sigar-bin,
> -Dcassandra.libjemalloc=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1,
> -XX:OnOutOfMemoryError=kill -9 %p, -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/opt/cassandra/logs,
> -Dcassandra.storagedir=/opt/cassandra/data, -Dcassandra-foreground=yes]
> WARN 20:28:57 Unable to lock JVM memory (ENOMEM). This can result in part of
> the JVM being swapped out, especially with mmapped I/O enabled. Increase
> RLIMIT_MEMLOCK or run Cassandra as root.
> INFO 20:28:57 jemalloc seems to be preloaded from
> /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
> INFO 20:28:57 JMX is enabled to receive remote connections on port: 7199
> WARN 20:28:57 OpenJDK is not recommended. Please upgrade to the newest
> Oracle Java release
> INFO 20:28:57 Initializing SIGAR library
> INFO 20:28:57 Checked OS settings and found them configured for optimal
> performance.
> WARN 20:28:57 Directory /opt/cassandra/data/commitlog doesn't exist
> WARN 20:28:57 Directory /opt/cassandra/data/saved_caches doesn't exist
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:717)
> Caused by: java.lang.IllegalArgumentException: Bad configuration; unable to
> start server: At least one DataFileDirectory must be specified
> at
> org.apache.cassandra.config.DatabaseDescriptor.createAllDirectories(DatabaseDescriptor.java:846)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:66)
> ... 6 more
> ERROR 20:28:58 Exception encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> [apache-cassandra-2.2.17.jar:2.2.17]
> at
>
[jira] [Updated] (CASSANDRA-16008) 2.2.17 fails to start up with ExceptionInInitializerError
[
https://issues.apache.org/jira/browse/CASSANDRA-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16008:
--
Fix Version/s: 2.2.x
> 2.2.17 fails to start up with ExceptionInInitializerError
> -
>
> Key: CASSANDRA-16008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16008
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tianon Gravi
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 2.2.x
>
> Attachments: CASSANDRA-16008-2.2.txt
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After the upgrade to 2.2.17, Cassandra fails to start with the following
> error:
> {noformat}
> INFO 20:28:57 JVM Arguments: [-Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false, -ea,
> -javaagent:/opt/cassandra/lib/jamm-0.3.0.jar, -XX:+CMSClassUnloadingEnabled,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42, -Xms128m, -Xmx128m,
> -Xmn32m, -XX:+HeapDumpOnOutOfMemoryError, -Xss256k,
> -XX:StringTableSize=103, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC,
> -XX:+CMSParallelRemarkEnabled, -XX:SurvivorRatio=8,
> -XX:MaxTenuringThreshold=1, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly, -XX:+UseTLAB, -XX:+PerfDisableSharedMem,
> -XX:CompileCommandFile=/etc/cassandra/hotspot_compiler,
> -XX:CMSWaitDuration=1, -XX:+CMSParallelInitialMarkEnabled,
> -XX:+CMSEdenChunksRecordAlways, -XX:CMSWaitDuration=1,
> -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC,
> -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime,
> -XX:+PrintPromotionFailure, -Xloggc:/opt/cassandra/logs/gc.log,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -Djava.net.preferIPv4Stack=true, -Dcassandra.jmx.local.port=7199,
> -XX:+DisableExplicitGC, -Djava.library.path=/opt/cassandra/lib/sigar-bin,
> -Dcassandra.libjemalloc=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1,
> -XX:OnOutOfMemoryError=kill -9 %p, -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/opt/cassandra/logs,
> -Dcassandra.storagedir=/opt/cassandra/data, -Dcassandra-foreground=yes]
> WARN 20:28:57 Unable to lock JVM memory (ENOMEM). This can result in part of
> the JVM being swapped out, especially with mmapped I/O enabled. Increase
> RLIMIT_MEMLOCK or run Cassandra as root.
> INFO 20:28:57 jemalloc seems to be preloaded from
> /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
> INFO 20:28:57 JMX is enabled to receive remote connections on port: 7199
> WARN 20:28:57 OpenJDK is not recommended. Please upgrade to the newest
> Oracle Java release
> INFO 20:28:57 Initializing SIGAR library
> INFO 20:28:57 Checked OS settings and found them configured for optimal
> performance.
> WARN 20:28:57 Directory /opt/cassandra/data/commitlog doesn't exist
> WARN 20:28:57 Directory /opt/cassandra/data/saved_caches doesn't exist
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:717)
> Caused by: java.lang.IllegalArgumentException: Bad configuration; unable to
> start server: At least one DataFileDirectory must be specified
> at
> org.apache.cassandra.config.DatabaseDescriptor.createAllDirectories(DatabaseDescriptor.java:846)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:66)
> ... 6 more
> ERROR 20:28:58 Exception encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> [apache-cassandra-2.2.17.jar:2.2.17]
> at
>
[jira] [Comment Edited] (CASSANDRA-16008) 2.2.17 fails to start up with ExceptionInInitializerError
[
https://issues.apache.org/jira/browse/CASSANDRA-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200754#comment-17200754
]
Erick Ramirez edited comment on CASSANDRA-16008 at 9/23/20, 11:29 AM:
--
Applied CASSANDRA-7066 fix in C* 3.0/3.11 to {{DatabaseDescriptor.java}} broken
by commit {{257fb03}}:
* 2.2 PR - https://github.com/apache/cassandra/pull/757
* 2.2 Patch - [^CASSANDRA-16008-2.2.txt]
This only applies to the 2.2 branch since it's already fixed in C* 3.x/4.0.
was (Author: flightc):
Applied CASSANDRA-7066 fix in C* 3.0/3.11 to `DatabaseDescriptor.java` broken
by commit `257fb03`:
* 2.2 PR - https://github.com/apache/cassandra/pull/757
* 2.2 Patch - [^CASSANDRA-16008-2.2.txt]
This only applies to the 2.2 branch since it's already fixed in C* 3.x/4.0.
> 2.2.17 fails to start up with ExceptionInInitializerError
> -
>
> Key: CASSANDRA-16008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16008
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tianon Gravi
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 2.2.18
>
> Attachments: CASSANDRA-16008-2.2.txt
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After the upgrade to 2.2.17, Cassandra fails to start with the following
> error:
> {noformat}
> INFO 20:28:57 JVM Arguments: [-Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false, -ea,
> -javaagent:/opt/cassandra/lib/jamm-0.3.0.jar, -XX:+CMSClassUnloadingEnabled,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42, -Xms128m, -Xmx128m,
> -Xmn32m, -XX:+HeapDumpOnOutOfMemoryError, -Xss256k,
> -XX:StringTableSize=103, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC,
> -XX:+CMSParallelRemarkEnabled, -XX:SurvivorRatio=8,
> -XX:MaxTenuringThreshold=1, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly, -XX:+UseTLAB, -XX:+PerfDisableSharedMem,
> -XX:CompileCommandFile=/etc/cassandra/hotspot_compiler,
> -XX:CMSWaitDuration=1, -XX:+CMSParallelInitialMarkEnabled,
> -XX:+CMSEdenChunksRecordAlways, -XX:CMSWaitDuration=1,
> -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC,
> -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime,
> -XX:+PrintPromotionFailure, -Xloggc:/opt/cassandra/logs/gc.log,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -Djava.net.preferIPv4Stack=true, -Dcassandra.jmx.local.port=7199,
> -XX:+DisableExplicitGC, -Djava.library.path=/opt/cassandra/lib/sigar-bin,
> -Dcassandra.libjemalloc=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1,
> -XX:OnOutOfMemoryError=kill -9 %p, -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/opt/cassandra/logs,
> -Dcassandra.storagedir=/opt/cassandra/data, -Dcassandra-foreground=yes]
> WARN 20:28:57 Unable to lock JVM memory (ENOMEM). This can result in part of
> the JVM being swapped out, especially with mmapped I/O enabled. Increase
> RLIMIT_MEMLOCK or run Cassandra as root.
> INFO 20:28:57 jemalloc seems to be preloaded from
> /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
> INFO 20:28:57 JMX is enabled to receive remote connections on port: 7199
> WARN 20:28:57 OpenJDK is not recommended. Please upgrade to the newest
> Oracle Java release
> INFO 20:28:57 Initializing SIGAR library
> INFO 20:28:57 Checked OS settings and found them configured for optimal
> performance.
> WARN 20:28:57 Directory /opt/cassandra/data/commitlog doesn't exist
> WARN 20:28:57 Directory /opt/cassandra/data/saved_caches doesn't exist
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:717)
> Caused by: java.lang.IllegalArgumentException: Bad configuration; unable to
> start server: At least one DataFileDirectory must be specified
> at
> org.apache.cassandra.config.DatabaseDescriptor.createAllDirectories(DatabaseDescriptor.java:846)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:66)
> ... 6 more
> ERROR 20:28:58 Exception encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
>
[jira] [Updated] (CASSANDRA-16008) 2.2.17 fails to start up with ExceptionInInitializerError
[
https://issues.apache.org/jira/browse/CASSANDRA-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16008:
--
Test and Documentation Plan: Applied CASSANDRA-7066 fix in C* 3.0/3.11 to
`DatabaseDescriptor.java` broken by commit `257fb03`.
Status: Patch Available (was: Open)
Applied CASSANDRA-7066 fix in C* 3.0/3.11 to `DatabaseDescriptor.java` broken
by commit `257fb03`:
* 2.2 PR - https://github.com/apache/cassandra/pull/757
* 2.2 Patch - [^CASSANDRA-16008-2.2.txt]
This only applies to the 2.2 branch since it's already fixed in C* 3.x/4.0.
> 2.2.17 fails to start up with ExceptionInInitializerError
> -
>
> Key: CASSANDRA-16008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16008
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tianon Gravi
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 2.2.18
>
> Attachments: CASSANDRA-16008-2.2.txt
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After the upgrade to 2.2.17, Cassandra fails to start with the following
> error:
> {noformat}
> INFO 20:28:57 JVM Arguments: [-Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false, -ea,
> -javaagent:/opt/cassandra/lib/jamm-0.3.0.jar, -XX:+CMSClassUnloadingEnabled,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42, -Xms128m, -Xmx128m,
> -Xmn32m, -XX:+HeapDumpOnOutOfMemoryError, -Xss256k,
> -XX:StringTableSize=103, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC,
> -XX:+CMSParallelRemarkEnabled, -XX:SurvivorRatio=8,
> -XX:MaxTenuringThreshold=1, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly, -XX:+UseTLAB, -XX:+PerfDisableSharedMem,
> -XX:CompileCommandFile=/etc/cassandra/hotspot_compiler,
> -XX:CMSWaitDuration=1, -XX:+CMSParallelInitialMarkEnabled,
> -XX:+CMSEdenChunksRecordAlways, -XX:CMSWaitDuration=1,
> -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC,
> -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime,
> -XX:+PrintPromotionFailure, -Xloggc:/opt/cassandra/logs/gc.log,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -Djava.net.preferIPv4Stack=true, -Dcassandra.jmx.local.port=7199,
> -XX:+DisableExplicitGC, -Djava.library.path=/opt/cassandra/lib/sigar-bin,
> -Dcassandra.libjemalloc=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1,
> -XX:OnOutOfMemoryError=kill -9 %p, -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/opt/cassandra/logs,
> -Dcassandra.storagedir=/opt/cassandra/data, -Dcassandra-foreground=yes]
> WARN 20:28:57 Unable to lock JVM memory (ENOMEM). This can result in part of
> the JVM being swapped out, especially with mmapped I/O enabled. Increase
> RLIMIT_MEMLOCK or run Cassandra as root.
> INFO 20:28:57 jemalloc seems to be preloaded from
> /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
> INFO 20:28:57 JMX is enabled to receive remote connections on port: 7199
> WARN 20:28:57 OpenJDK is not recommended. Please upgrade to the newest
> Oracle Java release
> INFO 20:28:57 Initializing SIGAR library
> INFO 20:28:57 Checked OS settings and found them configured for optimal
> performance.
> WARN 20:28:57 Directory /opt/cassandra/data/commitlog doesn't exist
> WARN 20:28:57 Directory /opt/cassandra/data/saved_caches doesn't exist
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:717)
> Caused by: java.lang.IllegalArgumentException: Bad configuration; unable to
> start server: At least one DataFileDirectory must be specified
> at
> org.apache.cassandra.config.DatabaseDescriptor.createAllDirectories(DatabaseDescriptor.java:846)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:66)
> ... 6 more
> ERROR 20:28:58 Exception encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
[jira] [Updated] (CASSANDRA-16008) 2.2.17 fails to start up with ExceptionInInitializerError
[
https://issues.apache.org/jira/browse/CASSANDRA-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16008:
--
Attachment: CASSANDRA-16008-2.2.txt
> 2.2.17 fails to start up with ExceptionInInitializerError
> -
>
> Key: CASSANDRA-16008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16008
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tianon Gravi
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 2.2.18
>
> Attachments: CASSANDRA-16008-2.2.txt
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After the upgrade to 2.2.17, Cassandra fails to start with the following
> error:
> {noformat}
> INFO 20:28:57 JVM Arguments: [-Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false, -ea,
> -javaagent:/opt/cassandra/lib/jamm-0.3.0.jar, -XX:+CMSClassUnloadingEnabled,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42, -Xms128m, -Xmx128m,
> -Xmn32m, -XX:+HeapDumpOnOutOfMemoryError, -Xss256k,
> -XX:StringTableSize=103, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC,
> -XX:+CMSParallelRemarkEnabled, -XX:SurvivorRatio=8,
> -XX:MaxTenuringThreshold=1, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly, -XX:+UseTLAB, -XX:+PerfDisableSharedMem,
> -XX:CompileCommandFile=/etc/cassandra/hotspot_compiler,
> -XX:CMSWaitDuration=1, -XX:+CMSParallelInitialMarkEnabled,
> -XX:+CMSEdenChunksRecordAlways, -XX:CMSWaitDuration=1,
> -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC,
> -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime,
> -XX:+PrintPromotionFailure, -Xloggc:/opt/cassandra/logs/gc.log,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -Djava.net.preferIPv4Stack=true, -Dcassandra.jmx.local.port=7199,
> -XX:+DisableExplicitGC, -Djava.library.path=/opt/cassandra/lib/sigar-bin,
> -Dcassandra.libjemalloc=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1,
> -XX:OnOutOfMemoryError=kill -9 %p, -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/opt/cassandra/logs,
> -Dcassandra.storagedir=/opt/cassandra/data, -Dcassandra-foreground=yes]
> WARN 20:28:57 Unable to lock JVM memory (ENOMEM). This can result in part of
> the JVM being swapped out, especially with mmapped I/O enabled. Increase
> RLIMIT_MEMLOCK or run Cassandra as root.
> INFO 20:28:57 jemalloc seems to be preloaded from
> /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
> INFO 20:28:57 JMX is enabled to receive remote connections on port: 7199
> WARN 20:28:57 OpenJDK is not recommended. Please upgrade to the newest
> Oracle Java release
> INFO 20:28:57 Initializing SIGAR library
> INFO 20:28:57 Checked OS settings and found them configured for optimal
> performance.
> WARN 20:28:57 Directory /opt/cassandra/data/commitlog doesn't exist
> WARN 20:28:57 Directory /opt/cassandra/data/saved_caches doesn't exist
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:717)
> Caused by: java.lang.IllegalArgumentException: Bad configuration; unable to
> start server: At least one DataFileDirectory must be specified
> at
> org.apache.cassandra.config.DatabaseDescriptor.createAllDirectories(DatabaseDescriptor.java:846)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:66)
> ... 6 more
> ERROR 20:28:58 Exception encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
>
[jira] [Commented] (CASSANDRA-16008) 2.2.17 fails to start up with ExceptionInInitializerError
[
https://issues.apache.org/jira/browse/CASSANDRA-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200731#comment-17200731
]
Chris Elsmore commented on CASSANDRA-16008:
---
Would be very helpful to have this addressed as it is currently blocking new
Docker containers of the Cassandra 2.2 tag -
https://github.com/docker-library/cassandra/issues/215
> 2.2.17 fails to start up with ExceptionInInitializerError
> -
>
> Key: CASSANDRA-16008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16008
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tianon Gravi
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 2.2.18
>
>
> After the upgrade to 2.2.17, Cassandra fails to start with the following
> error:
> {noformat}
> INFO 20:28:57 JVM Arguments: [-Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false, -ea,
> -javaagent:/opt/cassandra/lib/jamm-0.3.0.jar, -XX:+CMSClassUnloadingEnabled,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42, -Xms128m, -Xmx128m,
> -Xmn32m, -XX:+HeapDumpOnOutOfMemoryError, -Xss256k,
> -XX:StringTableSize=103, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC,
> -XX:+CMSParallelRemarkEnabled, -XX:SurvivorRatio=8,
> -XX:MaxTenuringThreshold=1, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly, -XX:+UseTLAB, -XX:+PerfDisableSharedMem,
> -XX:CompileCommandFile=/etc/cassandra/hotspot_compiler,
> -XX:CMSWaitDuration=1, -XX:+CMSParallelInitialMarkEnabled,
> -XX:+CMSEdenChunksRecordAlways, -XX:CMSWaitDuration=1,
> -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC,
> -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime,
> -XX:+PrintPromotionFailure, -Xloggc:/opt/cassandra/logs/gc.log,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -Djava.net.preferIPv4Stack=true, -Dcassandra.jmx.local.port=7199,
> -XX:+DisableExplicitGC, -Djava.library.path=/opt/cassandra/lib/sigar-bin,
> -Dcassandra.libjemalloc=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1,
> -XX:OnOutOfMemoryError=kill -9 %p, -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/opt/cassandra/logs,
> -Dcassandra.storagedir=/opt/cassandra/data, -Dcassandra-foreground=yes]
> WARN 20:28:57 Unable to lock JVM memory (ENOMEM). This can result in part of
> the JVM being swapped out, especially with mmapped I/O enabled. Increase
> RLIMIT_MEMLOCK or run Cassandra as root.
> INFO 20:28:57 jemalloc seems to be preloaded from
> /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
> INFO 20:28:57 JMX is enabled to receive remote connections on port: 7199
> WARN 20:28:57 OpenJDK is not recommended. Please upgrade to the newest
> Oracle Java release
> INFO 20:28:57 Initializing SIGAR library
> INFO 20:28:57 Checked OS settings and found them configured for optimal
> performance.
> WARN 20:28:57 Directory /opt/cassandra/data/commitlog doesn't exist
> WARN 20:28:57 Directory /opt/cassandra/data/saved_caches doesn't exist
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:717)
> Caused by: java.lang.IllegalArgumentException: Bad configuration; unable to
> start server: At least one DataFileDirectory must be specified
> at
> org.apache.cassandra.config.DatabaseDescriptor.createAllDirectories(DatabaseDescriptor.java:846)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:66)
> ... 6 more
> ERROR 20:28:58 Exception encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-2.2.17.jar:2.2.17]
> at
>
[jira] [Updated] (CASSANDRA-16008) 2.2.17 fails to start up with ExceptionInInitializerError
[
https://issues.apache.org/jira/browse/CASSANDRA-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16008:
--
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Component/s: Local/Config
Discovered By: User Report
Fix Version/s: 2.2.18
Severity: Normal
Assignee: Erick Ramirez
Status: Open (was: Triage Needed)
> 2.2.17 fails to start up with ExceptionInInitializerError
> -
>
> Key: CASSANDRA-16008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16008
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tianon Gravi
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 2.2.18
>
>
> After the upgrade to 2.2.17, Cassandra fails to start with the following
> error:
> {noformat}
> INFO 20:28:57 JVM Arguments: [-Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false, -ea,
> -javaagent:/opt/cassandra/lib/jamm-0.3.0.jar, -XX:+CMSClassUnloadingEnabled,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42, -Xms128m, -Xmx128m,
> -Xmn32m, -XX:+HeapDumpOnOutOfMemoryError, -Xss256k,
> -XX:StringTableSize=103, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC,
> -XX:+CMSParallelRemarkEnabled, -XX:SurvivorRatio=8,
> -XX:MaxTenuringThreshold=1, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly, -XX:+UseTLAB, -XX:+PerfDisableSharedMem,
> -XX:CompileCommandFile=/etc/cassandra/hotspot_compiler,
> -XX:CMSWaitDuration=1, -XX:+CMSParallelInitialMarkEnabled,
> -XX:+CMSEdenChunksRecordAlways, -XX:CMSWaitDuration=1,
> -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC,
> -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime,
> -XX:+PrintPromotionFailure, -Xloggc:/opt/cassandra/logs/gc.log,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -Djava.net.preferIPv4Stack=true, -Dcassandra.jmx.local.port=7199,
> -XX:+DisableExplicitGC, -Djava.library.path=/opt/cassandra/lib/sigar-bin,
> -Dcassandra.libjemalloc=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1,
> -XX:OnOutOfMemoryError=kill -9 %p, -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/opt/cassandra/logs,
> -Dcassandra.storagedir=/opt/cassandra/data, -Dcassandra-foreground=yes]
> WARN 20:28:57 Unable to lock JVM memory (ENOMEM). This can result in part of
> the JVM being swapped out, especially with mmapped I/O enabled. Increase
> RLIMIT_MEMLOCK or run Cassandra as root.
> INFO 20:28:57 jemalloc seems to be preloaded from
> /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
> INFO 20:28:57 JMX is enabled to receive remote connections on port: 7199
> WARN 20:28:57 OpenJDK is not recommended. Please upgrade to the newest
> Oracle Java release
> INFO 20:28:57 Initializing SIGAR library
> INFO 20:28:57 Checked OS settings and found them configured for optimal
> performance.
> WARN 20:28:57 Directory /opt/cassandra/data/commitlog doesn't exist
> WARN 20:28:57 Directory /opt/cassandra/data/saved_caches doesn't exist
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:607)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:717)
> Caused by: java.lang.IllegalArgumentException: Bad configuration; unable to
> start server: At least one DataFileDirectory must be specified
> at
> org.apache.cassandra.config.DatabaseDescriptor.createAllDirectories(DatabaseDescriptor.java:846)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:66)
> ... 6 more
> ERROR 20:28:58 Exception encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:709)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:351)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:109)
> ~[apache-cassandra-2.2.17.jar:2.2.17]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
>
[jira] [Updated] (CASSANDRA-16135) Separate in-JVM test into smaller packages
[ https://issues.apache.org/jira/browse/CASSANDRA-16135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16135: Status: Ready to Commit (was: Review In Progress) changes lgtm, +1 if ci looks fine > Separate in-JVM test into smaller packages > -- > > Key: CASSANDRA-16135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16135 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > Time Spent: 20m > Remaining Estimate: 0h > > Introduce a structure similar to how tags are organised in Cassandra Jira for > corresponding in-jvm dtests to help people find a right place for their tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16135) Separate in-JVM test into smaller packages
[ https://issues.apache.org/jira/browse/CASSANDRA-16135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16135: Fix Version/s: 4.0-beta 3.11.x 3.0.x 2.2.x > Separate in-JVM test into smaller packages > -- > > Key: CASSANDRA-16135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16135 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > Introduce a structure similar to how tags are organised in Cassandra Jira for > corresponding in-jvm dtests to help people find a right place for their tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16135) Separate in-JVM test into smaller packages
[ https://issues.apache.org/jira/browse/CASSANDRA-16135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16135: Reviewers: Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson) Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson) Status: Review In Progress (was: Patch Available) > Separate in-JVM test into smaller packages > -- > > Key: CASSANDRA-16135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16135 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > Time Spent: 20m > Remaining Estimate: 0h > > Introduce a structure similar to how tags are organised in Cassandra Jira for > corresponding in-jvm dtests to help people find a right place for their tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17199912#comment-17199912 ] Berenguer Blasi edited comment on CASSANDRA-16121 at 9/23/20, 8:52 AM: --- I added that new executor and updated the files. I will now run small, medium and high to make sure the 3 still work and then we should be able to merge. - Small: [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/121/workflows/7d278dce-3f13-46f0-bde2-79dcf61c6ad1] [j8|https://app.circleci.com/pipelines/github/bereng/cassandra/121/workflows/6bba245b-ac4d-426a-9041-c90571070d51]: OOM on the final test report which is a known problem, otherwise lgtm. - Medium [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/123/workflows/16aa4612-4a27-4bea-bebf-97efeef56353] [j8|https://app.circleci.com/pipelines/github/bereng/cassandra/123/workflows/c261dcdb-d878-4d66-afa6-5791d01dc45d] Failures look unrelated or known to fail. LGTM - High was (Author: bereng): I added that new executor and updated the files. I will now run small, medium and high to make sure the 3 still work and then we should be able to merge. - Small: [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/121/workflows/7d278dce-3f13-46f0-bde2-79dcf61c6ad1] [j8|https://app.circleci.com/pipelines/github/bereng/cassandra/121/workflows/6bba245b-ac4d-426a-9041-c90571070d51]: OOM on the final test report which is a known problem, otherwise lgtm. - Medium - High > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- This message was sent by Atlassian Jira (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-15823) Support for networking via identity instead of IP
[ https://issues.apache.org/jira/browse/CASSANDRA-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200662#comment-17200662 ] Stefan Podkowinski commented on CASSANDRA-15823: DNS is not strongly consistent and hard to reason about when making DNS a part of your system. We should not rely on address translation when thinking about consistency invariants. The title of the issue says "Support for networking via identity instead of IP". We should already be able to add some support for identities without using hostnames, in case we enable internode encryption. X509 certificates are issued with a unique identity. If you create an outgoing connection to a host, you should be able to compare the hostname of the peers certificate you're connecting to, with the hostname you've seen before for that IP and fail in case they wouldn't match. But this is really just useful for failing hard on IP swapping situations and not a basis for enabling a more advanced service mesh integration you've been mentioning. > Support for networking via identity instead of IP > - > > Key: CASSANDRA-15823 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15823 > Project: Cassandra > Issue Type: Improvement >Reporter: Christopher Bradford >Priority: Normal > Labels: kubernetes > Attachments: consul-mesh-gateways.png, > istio-multicluster-with-gateways.svg, linkerd-service-mirroring.svg > > > TL;DR: Instead of mapping host ids to IPs, use hostnames. This allows > resolution to different IP addresses per DC that may then be forwarded to > nodes on remote networks without requiring node to node IP connectivity for > cross-dc links. > > This approach should not affect existing deployments as those could continue > to use IPs as the hostname and skip resolution. > > With orchestration platforms like Kubernetes and the usage of ephemeral > containers in environments today we should consider some changes to how we > handle the tracking of nodes and their network location. Currently we > maintain a mapping between host ids and IP addresses. > > With traditional infrastructure, if a node goes down it, usually, comes back > up with the same IP. In some environments this contract may be explicit with > virtual IPs that may move between hosts. In newer deployments, like on > Kubernetes, this contract is not possible. Pods (analogous to nodes) are > assigned an IP address at start time. Should the pod be restarted or > scheduled on a different host there is no guarantee we would have the same > IP. Cassandra is protected here as we already have logic in place to update > peers when we come up with the same host id, but a different IP address. > > There are ways to get Kubernetes to assign a specific IP per Pod. Most > recommendations involve the use of a service per pod. Communication with the > fixed service IP would automatically forward to the associated pod, > regardless of address. We _could_ use this approach, but it seems like this > would needlessly create a number of extra resources in our k8s cluster to get > around the problem. Which, to be fair, doesn't seem like much of a problem > with the aforementioned mitigations built into C*. > > So what is the _actual_ problem? *Cross-region, cross-cloud, > hybrid-deployment connectivity between pods is a pain.* This can be solved > with significant investment by those who want to deploy these types of > topologies. You can definitely configure connectivity between clouds over > dedicated connections, or VPN tunnels. With a big chunk of time insuring that > pod to pod connectivity just works even if those pods are managed by separate > control planes, but that again requires time and talent. There are a number > of edge cases to support between the ever so slight, but very important, > differences in cloud vendor networks. > > Recently there have been a number of innovations that aid in the deployment > and operation of these types of applications on Kubernetes. Service meshes > support distributed microservices running across multiple k8s cluster control > planes in disparate networks. Instead of directly connecting to IP addresses > of remote services instead they use a hostname. With this approach, hostname > traffic may then be routed to a proxy that sends traffic over the WAN > (sometimes with mTLS) to another proxy pod in the remote cluster which then > forwards the data along to the correct pod in that network. (See attached > diagrams) > > Which brings us to the point of this ticket. Instead of mapping host ids to > IPs, use hostnames (and update the underlying address periodically instead of > caching indefinitely). This allows resolution to different IP addresses per > DC (k8s cluster)
[jira] [Comment Edited] (CASSANDRA-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17199912#comment-17199912 ] Berenguer Blasi edited comment on CASSANDRA-16121 at 9/23/20, 7:58 AM: --- I added that new executor and updated the files. I will now run small, medium and high to make sure the 3 still work and then we should be able to merge. - Small: [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/121/workflows/7d278dce-3f13-46f0-bde2-79dcf61c6ad1] [j8|https://app.circleci.com/pipelines/github/bereng/cassandra/121/workflows/6bba245b-ac4d-426a-9041-c90571070d51]: OOM on the final test report which is a known problem, otherwise lgtm. - Medium - High was (Author: bereng): I added that new executor and updated the files. I will now run small, medium and high to make sure the 3 still work and then we should be able to merge. > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- This message was sent by Atlassian Jira (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-15991) 15583 - Add UX tests to intree LHF tooling
[ https://issues.apache.org/jira/browse/CASSANDRA-15991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200633#comment-17200633 ] Berenguer Blasi commented on CASSANDRA-15991: - [~dcapwell] I rebased and put on top that with/out forking API. This is ready to continue review :-) #justfyi > 15583 - Add UX tests to intree LHF tooling > -- > > Key: CASSANDRA-15991 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15991 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > As per CASSANDRA-15583 many in tree tools lack proper UX tooling: mandatory > params are indeed mandatory, 'help' produces an actual help, return codes etc > This ticket is an attempt to add it to those tools that classify as LHF. > Other tools such as nodetool, with many sub-commands, deserve a separate > ticket of their own -- This message was sent by Atlassian Jira (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-16135) Separate in-JVM test into smaller packages
[
https://issues.apache.org/jira/browse/CASSANDRA-16135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200189#comment-17200189
]
Alex Petrov edited comment on CASSANDRA-16135 at 9/23/20, 7:31 AM:
---
Patch: [https://github.com/apache/cassandra/pull/755]
It introduces the following directory structure:
{code:java}
./test
├ consistency # ring movement, replication factor-related
├ coordination # SRP, RR, message forwarding, coordinator/replica code
├ cql # simple CQL-related tests: syntax, basic functionality
├ fql # FQL-related
├ gossip # gossip, propagation
├ hints
├ internal # tests for in-JVM DTest internals
├ nodetool # everything related to nodetool fuctionality
├ repair # everything repair-related
├ streaming# streaming on ring changes, bootstrap, etc
└ upgrade
{code}
was (Author: ifesdjeen):
Patch: https://github.com/apache/cassandra/pull/755
> Separate in-JVM test into smaller packages
> --
>
> Key: CASSANDRA-16135
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16135
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: High
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Introduce a structure similar to how tags are organised in Cassandra Jira for
> corresponding in-jvm dtests to help people find a right place for their tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16135) Separate in-JVM test into smaller packages
[ https://issues.apache.org/jira/browse/CASSANDRA-16135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16135: Reviewers: Marcus Eriksson > Separate in-JVM test into smaller packages > -- > > Key: CASSANDRA-16135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16135 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > Time Spent: 20m > Remaining Estimate: 0h > > Introduce a structure similar to how tags are organised in Cassandra Jira for > corresponding in-jvm dtests to help people find a right place for their tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-harry] branch master updated: Rename .asf.yml to .asf.yaml
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-harry.git The following commit(s) were added to refs/heads/master by this push: new 4fc41eb Rename .asf.yml to .asf.yaml 4fc41eb is described below commit 4fc41ebdd856682ad37fcb0f23f4e30121499611 Author: Alex Petrov AuthorDate: Wed Sep 23 09:22:47 2020 +0200 Rename .asf.yml to .asf.yaml --- .asf.yml | 10 -- 1 file changed, 10 deletions(-) diff --git a/.asf.yml b/.asf.yml deleted file mode 100644 index 91192e9..000 --- a/.asf.yml +++ /dev/null @@ -1,10 +0,0 @@ -notifications: - commits: commits@cassandra.apache.org - issues: commits@cassandra.apache.org - pullrequests: p...@cassandra.apache.org - -github: - enabled_merge_buttons: -squash: false -merge: false -rebase: true \ No newline at end of file - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16136) Provide access to metrics from in-jvm dtests
Alex Petrov created CASSANDRA-16136: --- Summary: Provide access to metrics from in-jvm dtests Key: CASSANDRA-16136 URL: https://issues.apache.org/jira/browse/CASSANDRA-16136 Project: Cassandra Issue Type: New Feature Reporter: Alex Petrov Assignee: Alex Petrov Current implementation requires of in-jvm dtests requires using callOnInstance in order to get metrics out of the in-jvm test node. Since many dtests require to check metrics, we need a version-agnostic mechanism that allows us to query the value of the metric by its published name instead of peeking into internals. -- This message was sent by Atlassian Jira (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-16135) Separate in-JVM test into smaller packages
[ https://issues.apache.org/jira/browse/CASSANDRA-16135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov reassigned CASSANDRA-16135: --- Assignee: Alex Petrov > Separate in-JVM test into smaller packages > -- > > Key: CASSANDRA-16135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16135 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > Time Spent: 20m > Remaining Estimate: 0h > > Introduce a structure similar to how tags are organised in Cassandra Jira for > corresponding in-jvm dtests to help people find a right place for their tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
