[cassandra] branch trunk updated: CASSANDRA-16274 followup - fix JMXCompatabilityTest
This is an automated email from the ASF dual-hosted git repository.
marcuse 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 8742f3a CASSANDRA-16274 followup - fix JMXCompatabilityTest
8742f3a is described below
commit 8742f3a414226bf93f8b2aff5870eff8badc0604
Author: Marcus Eriksson
AuthorDate: Wed Dec 2 07:42:24 2020 +0100
CASSANDRA-16274 followup - fix JMXCompatabilityTest
---
test/data/jmxdump/cassandra-4.0-jmx.yaml | 93
1 file changed, 93 deletions(-)
diff --git a/test/data/jmxdump/cassandra-4.0-jmx.yaml
b/test/data/jmxdump/cassandra-4.0-jmx.yaml
index 30a25f2..d7ce36d 100644
--- a/test/data/jmxdump/cassandra-4.0-jmx.yaml
+++ b/test/data/jmxdump/cassandra-4.0-jmx.yaml
@@ -48392,72 +48392,6 @@
org.apache.cassandra.metrics:type=Compaction,name=TotalCompactionsCompleted:
- name: objectName
parameters: []
returnType: javax.management.ObjectName
-org.apache.cassandra.metrics:type=DroppedMessage,scope=ASYMMETRIC_SYNC_REQ,name=CrossNodeDroppedLatency:
- attributes:
- - {access: read-only, name: 50thPercentile, type: double}
- - {access: read-only, name: 75thPercentile, type: double}
- - {access: read-only, name: 95thPercentile, type: double}
- - {access: read-only, name: 98thPercentile, type: double}
- - {access: read-only, name: 999thPercentile, type: double}
- - {access: read-only, name: 99thPercentile, type: double}
- - {access: read-only, name: Count, type: long}
- - {access: read-only, name: DurationUnit, type: java.lang.String}
- - {access: read-only, name: FifteenMinuteRate, type: double}
- - {access: read-only, name: FiveMinuteRate, type: double}
- - {access: read-only, name: Max, type: double}
- - {access: read-only, name: Mean, type: double}
- - {access: read-only, name: MeanRate, type: double}
- - {access: read-only, name: Min, type: double}
- - {access: read-only, name: OneMinuteRate, type: double}
- - {access: read-only, name: RateUnit, type: java.lang.String}
- - {access: read-only, name: RecentValues, type: 'long[]'}
- - {access: read-only, name: StdDev, type: double}
- operations:
- - name: objectName
-parameters: []
-returnType: javax.management.ObjectName
- - name: values
-parameters: []
-returnType: long[]
-org.apache.cassandra.metrics:type=DroppedMessage,scope=ASYMMETRIC_SYNC_REQ,name=Dropped:
- attributes:
- - {access: read-only, name: Count, type: long}
- - {access: read-only, name: FifteenMinuteRate, type: double}
- - {access: read-only, name: FiveMinuteRate, type: double}
- - {access: read-only, name: MeanRate, type: double}
- - {access: read-only, name: OneMinuteRate, type: double}
- - {access: read-only, name: RateUnit, type: java.lang.String}
- operations:
- - name: objectName
-parameters: []
-returnType: javax.management.ObjectName
-org.apache.cassandra.metrics:type=DroppedMessage,scope=ASYMMETRIC_SYNC_REQ,name=InternalDroppedLatency:
- attributes:
- - {access: read-only, name: 50thPercentile, type: double}
- - {access: read-only, name: 75thPercentile, type: double}
- - {access: read-only, name: 95thPercentile, type: double}
- - {access: read-only, name: 98thPercentile, type: double}
- - {access: read-only, name: 999thPercentile, type: double}
- - {access: read-only, name: 99thPercentile, type: double}
- - {access: read-only, name: Count, type: long}
- - {access: read-only, name: DurationUnit, type: java.lang.String}
- - {access: read-only, name: FifteenMinuteRate, type: double}
- - {access: read-only, name: FiveMinuteRate, type: double}
- - {access: read-only, name: Max, type: double}
- - {access: read-only, name: Mean, type: double}
- - {access: read-only, name: MeanRate, type: double}
- - {access: read-only, name: Min, type: double}
- - {access: read-only, name: OneMinuteRate, type: double}
- - {access: read-only, name: RateUnit, type: java.lang.String}
- - {access: read-only, name: RecentValues, type: 'long[]'}
- - {access: read-only, name: StdDev, type: double}
- operations:
- - name: objectName
-parameters: []
-returnType: javax.management.ObjectName
- - name: values
-parameters: []
-returnType: long[]
org.apache.cassandra.metrics:type=DroppedMessage,scope=BATCH_REMOVE_REQ,name=CrossNodeDroppedLatency:
attributes:
- {access: read-only, name: 50thPercentile, type: double}
@@ -58427,33 +58361,6 @@
org.apache.cassandra.metrics:type=MemtablePool,name=BlockedOnAllocation:
- name: values
parameters: []
returnType: long[]
-org.apache.cassandra.metrics:type=Messaging,name=ASYMMETRIC_SYNC_REQ-WaitLatency:
- attributes:
- - {access: read-only, name: 50thPercentile, type: double}
- - {access: read-only, name: 75thPercentile, type: double}
- - {access: read-only, name: 95thPercentile, type: double}
- - {access: read-only, name: 98thPercentile, type: double}
- - {access: read-only,
[jira] [Updated] (CASSANDRA-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yang updated CASSANDRA-16259:
--
Reviewers: Berenguer Blasi, Zhao Yang, Zhao Yang (was: Berenguer Blasi,
Zhao Yang)
Berenguer Blasi, Zhao Yang, Zhao Yang (was: Berenguer Blasi,
Zhao Yang)
Status: Review In Progress (was: Patch Available)
LGTM, thanks for the fix.
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-beta
>
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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
]
Berenguer Blasi updated CASSANDRA-16143:
Reviewers: Adam Holmberg, Berenguer Blasi (was: Adam Holmberg)
> 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: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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
>
[jira] [Commented] (CASSANDRA-16097) DigestResolver.getData throws AssertionError since dataResponse is null
[
https://issues.apache.org/jira/browse/CASSANDRA-16097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242052#comment-17242052
]
Caleb Rackliffe commented on CASSANDRA-16097:
-
My first pass at review is complete. Mostly, I've [chimed
in|https://github.com/aholmberg/cassandra/pull/17#discussion_r533782186] on
what appears to be the main outstanding discussion point and [proposed a new
test|https://github.com/aholmberg/cassandra/pull/17#issuecomment-736995647].
> DigestResolver.getData throws AssertionError since dataResponse is null
> ---
>
> Key: CASSANDRA-16097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16097
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Was running a benchmark at LOCAL_ONE and eventually saw the below exception
> {code}
> 2020-09-02 21:08:59,872 ERROR [Native-Transport-Requests-35]
> org.apache.cassandra.transport.Message - Unexpected exception during request;
> channel = [id: 0x13bb89d4, L:/10.14.92.74:9042 - R:/10.14.89.248:47112]
> java.lang.AssertionError
>at
> org.apache.cassandra.service.reads.DigestResolver.getData(DigestResolver.java:77)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:390)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1821)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1711)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1628)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1097)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:294)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:246)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:498)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:476)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
>at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {code}
> This exception was not frequent, out of the whole run (3h) only saw this
> twice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16286) Make TokenMetadata's ring version increments atomic
[
https://issues.apache.org/jira/browse/CASSANDRA-16286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe reassigned CASSANDRA-16286:
---
Assignee: Caleb Rackliffe
> Make TokenMetadata's ring version increments atomic
> ---
>
> Key: CASSANDRA-16286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16286
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> The update semantics of the ring version in {{TokenMetadata}} are not clear.
> The instance variable itself is {{volatile}}, but it is still incremented by
> a non-atomic check-and-set, and not all codepaths do that while holding the
> {{TokenMetadata}} write lock. We could make this more intelligible by forcing
> the external callers to use both the write when invalidating the ring and
> read lock when reading the current ring version. Most of the readers of the
> ring version (ex. compaction) don't need it to be fast, but it shouldn't be a
> problem even if they do. If we do this, we should be able to avoid a
> situation where concurrent invalidations don't produce two distinct version
> increments.
--
This message was sent by Atlassian Jira
(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-16240) Having issues creating a table with name profiles
[ https://issues.apache.org/jira/browse/CASSANDRA-16240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242048#comment-17242048 ] Anuj Kulkarni commented on CASSANDRA-16240: --- That's fine for me. Thanks Adam. > Having issues creating a table with name profiles > - > > Key: CASSANDRA-16240 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16240 > Project: Cassandra > Issue Type: Bug >Reporter: Anuj Kulkarni >Priority: Normal > Attachments: image-2020-11-02-12-13-16-999.png > > > Whenever I try to create a table with name profiles, it always gets created > with additional quotes surrounding it. Attaching the screenshot. > I am on Cassandra 3.7 > I tried creating the table in another keyspace. I also tried creating new > virtual machines with the same AMI and same Cassandra version, but to no > avail. > If I try to create a table with any other name, there are no issues at all. > It's just with the name profiles. > I am on Ubuntu 18.04 by the way. > !image-2020-11-02-12-13-16-999.png! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13325) Bring back the accepted encryption protocols list as configurable option
[
https://issues.apache.org/jira/browse/CASSANDRA-13325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242011#comment-17242011
]
David Capwell commented on CASSANDRA-13325:
---
Left comments in GH, mostly LGTM. The only real comment I had was about ref
counting the ssl engine, so think this can be +1ed tomorrow once addressed.
> Bring back the accepted encryption protocols list as configurable option
>
>
> Key: CASSANDRA-13325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13325
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Nachiket Patil
>Assignee: Jon Meredith
>Priority: Low
> Fix For: 4.0-beta
>
> Attachments: trunk.diff
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> With CASSANDRA-10508, the hard coded list of accepted encryption protocols
> was eliminated. For some use cases, it is necessary to restrict the
> encryption protocols used for communication between client and server.
> Default JVM way of negotiations allows the best encryption protocol that
> client can use.
> e.g. I have set Cassandra to use encryption. Ideally client and server
> negotiate to use best protocol (TLSv1.2). But a malicious client might force
> TLSv1.0 which is susceptible to POODLE attacks.
> At the moment only way to restrict the encryption protocol is using the
> {{jdk.tls.client.protocols}} systems property. If I dont have enough access
> to modify this property, I dont have any way of restricting the encryption
> protocols.
> I am proposing bring back the accepted_protocols property but make it
> configurable. If not specified, let the JVM take care of the TLS negotiations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241994#comment-17241994 ] Yuki Morishita commented on CASSANDRA-16171: Sorry, I appreciate if you can merge the change. > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.html -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16083) Missing JMX objects and attributes upgrading from 3.0 to 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241980#comment-17241980
]
Ekaterina Dimitrova edited comment on CASSANDRA-16083 at 12/2/20, 1:41 AM:
---
??ConditionNotMet looks like a rename regression, we should add an alias to fix
it (like we have for other metrics).??
[~dcapwell], I guess you mean the work done in CASSANDRA-15909? While I haven't
worked on that one, It looks to me from the ticket comments that a nice
framework was created that could help to quickly wrap up? :-) Or you meant
something else - "like we have for other metrics"? :-)
??Since this was seen from scraping metrics it could, but that would imply that
3.x was not lazy and 4.x is? If we validate that they are present on a running
cluster than it can be safe to ride off as tooling issue.??
While I haven't validated this on a running cluster, a quick check of the code
suggests that this is the case.(Thank you [~blerer]!) I can spend more time on
that point later this week. (I was asked to prioritize other tickets)
was (Author: e.dimitrova):
??ConditionNotMet looks like a rename regression, we should add an alias to fix
it (like we have for other metrics).??
I guess you mean the work done in CASSANDRA-15909? While I haven't worked on
that one, It looks to me from the ticket comments that a nice framework was
created that could help to quickly wrap up? :-) Or you meant something else -
"like we have for other metrics"? :-)
??Since this was seen from scraping metrics it could, but that would imply that
3.x was not lazy and 4.x is? If we validate that they are present on a running
cluster than it can be safe to ride off as tooling issue.??
While I haven't validated this on a running cluster, a quick check of the code
suggests that this is the case.(Thank you [~blerer]!) I can spend more time on
that point later this week. (I was asked to prioritize other tickets)
> Missing JMX objects and attributes upgrading from 3.0 to 4.0
>
>
> Key: CASSANDRA-16083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16083
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: David Capwell
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Using the tools added in CASSANDRA-16082, below are the list of metrics
> missing in 4.0 but present in 3.0. The work here is to make sure we had
> proper deprecation for each metric, and if not to add it back.
> {code}
> $ tools/bin/jmxtool diff -f yaml cassandra-3.0-jmx.yaml trunk-jmx.yaml
> --ignore-missing-on-left
> Objects not in right:
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=EstimatedPartitionSizeHistogram
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=BloomFilterFalseRatio
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=ReplicaFilteringProtectionRequests
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=RowCacheHitOutOfRange
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=CounterMutationStage,name=MaxPoolSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=ColUpdateTimeDeltaHistogram
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=TombstoneScannedHistogram
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=ReadStage,name=ActiveTasks
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=WaitingOnFreeMemtableSpace
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasCommitTotalLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=MemtableOnHeapSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_aggregates,name=CasProposeLatency
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=AllMemtablesLiveDataSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=ViewReadTime
> org.apache.cassandra.db:type=HintedHandoffManager
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=BloomFilterDiskSpaceUsed
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=RequestResponseStage,name=PendingTasks
>
[jira] [Comment Edited] (CASSANDRA-16083) Missing JMX objects and attributes upgrading from 3.0 to 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241980#comment-17241980
]
Ekaterina Dimitrova edited comment on CASSANDRA-16083 at 12/2/20, 1:41 AM:
---
??ConditionNotMet looks like a rename regression, we should add an alias to fix
it (like we have for other metrics).??
I guess you mean the work done in CASSANDRA-15909? While I haven't worked on
that one, It looks to me from the ticket comments that a nice framework was
created that could help to quickly wrap up? :-) Or you meant something else -
"like we have for other metrics"? :-)
??Since this was seen from scraping metrics it could, but that would imply that
3.x was not lazy and 4.x is? If we validate that they are present on a running
cluster than it can be safe to ride off as tooling issue.??
While I haven't validated this on a running cluster, a quick check of the code
suggests that this is the case.(Thank you [~blerer]!) I can spend more time on
that point later this week. (I was asked to prioritize other tickets)
was (Author: e.dimitrova):
??ConditionNotMet looks like a rename regression, we should add an alias to fix
it (like we have for other metrics).??
I guess you mean the work done in CASSANDRA-15909? While I haven't worked on
that one, It looks to me from the ticket comments that a nice framework was
created that could help to quickly wrap up? :-) Or you meant something else -
"like we have for other metrics"? :-)
??Since this was seen from scraping metrics it could, but that would imply that
3.x was not lazy and 4.x is? If we validate that they are present on a running
cluster than it can be safe to ride off as tooling issue.??
While I haven't validated this on a running cluster, a quick check of the code
suggests that this is the case. I can spend more time on that point later this
week. (I was asked to prioritize other tickets)
> Missing JMX objects and attributes upgrading from 3.0 to 4.0
>
>
> Key: CASSANDRA-16083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16083
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: David Capwell
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Using the tools added in CASSANDRA-16082, below are the list of metrics
> missing in 4.0 but present in 3.0. The work here is to make sure we had
> proper deprecation for each metric, and if not to add it back.
> {code}
> $ tools/bin/jmxtool diff -f yaml cassandra-3.0-jmx.yaml trunk-jmx.yaml
> --ignore-missing-on-left
> Objects not in right:
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=EstimatedPartitionSizeHistogram
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=BloomFilterFalseRatio
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=ReplicaFilteringProtectionRequests
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=RowCacheHitOutOfRange
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=CounterMutationStage,name=MaxPoolSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=ColUpdateTimeDeltaHistogram
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=TombstoneScannedHistogram
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=ReadStage,name=ActiveTasks
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=WaitingOnFreeMemtableSpace
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasCommitTotalLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=MemtableOnHeapSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_aggregates,name=CasProposeLatency
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=AllMemtablesLiveDataSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=ViewReadTime
> org.apache.cassandra.db:type=HintedHandoffManager
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=BloomFilterDiskSpaceUsed
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=RequestResponseStage,name=PendingTasks
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=MemtableSwitchCount
>
[jira] [Comment Edited] (CASSANDRA-16083) Missing JMX objects and attributes upgrading from 3.0 to 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241980#comment-17241980
]
Ekaterina Dimitrova edited comment on CASSANDRA-16083 at 12/2/20, 1:40 AM:
---
??ConditionNotMet looks like a rename regression, we should add an alias to fix
it (like we have for other metrics).??
I guess you mean the work done in CASSANDRA-15909? While I haven't worked on
that one, It looks to me from the ticket comments that a nice framework was
created that could help to quickly wrap up? :-) Or you meant something else -
"like we have for other metrics"? :-)
??Since this was seen from scraping metrics it could, but that would imply that
3.x was not lazy and 4.x is? If we validate that they are present on a running
cluster than it can be safe to ride off as tooling issue.??
While I haven't validated this on a running cluster, a quick check of the code
suggests that this is the case. I can spend more time on that point later this
week. (I was asked to prioritize other tickets)
was (Author: e.dimitrova):
??ConditionNotMet looks like a rename regression, we should add an alias to fix
it (like we have for other metrics).??
I guess you mean the work done in CASSANDRA-15909? While I haven't worked on
that one, It looks to me from the ticket comments that a nice framework was
created that could help to quickly wrap up? :-)
??Since this was seen from scraping metrics it could, but that would imply that
3.x was not lazy and 4.x is? If we validate that they are present on a running
cluster than it can be safe to ride off as tooling issue.??
While I haven't validated this on a running cluster, a quick check of the code
suggests that this is the case. I can spend more time on that point later this
week. (I was asked to prioritize other tickets)
> Missing JMX objects and attributes upgrading from 3.0 to 4.0
>
>
> Key: CASSANDRA-16083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16083
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: David Capwell
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Using the tools added in CASSANDRA-16082, below are the list of metrics
> missing in 4.0 but present in 3.0. The work here is to make sure we had
> proper deprecation for each metric, and if not to add it back.
> {code}
> $ tools/bin/jmxtool diff -f yaml cassandra-3.0-jmx.yaml trunk-jmx.yaml
> --ignore-missing-on-left
> Objects not in right:
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=EstimatedPartitionSizeHistogram
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=BloomFilterFalseRatio
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=ReplicaFilteringProtectionRequests
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=RowCacheHitOutOfRange
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=CounterMutationStage,name=MaxPoolSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=ColUpdateTimeDeltaHistogram
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=TombstoneScannedHistogram
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=ReadStage,name=ActiveTasks
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=WaitingOnFreeMemtableSpace
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasCommitTotalLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=MemtableOnHeapSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_aggregates,name=CasProposeLatency
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=AllMemtablesLiveDataSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=ViewReadTime
> org.apache.cassandra.db:type=HintedHandoffManager
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=BloomFilterDiskSpaceUsed
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=RequestResponseStage,name=PendingTasks
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=MemtableSwitchCount
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=MemtableOnHeapSize
>
[jira] [Comment Edited] (CASSANDRA-16083) Missing JMX objects and attributes upgrading from 3.0 to 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241980#comment-17241980
]
Ekaterina Dimitrova edited comment on CASSANDRA-16083 at 12/2/20, 1:39 AM:
---
??ConditionNotMet looks like a rename regression, we should add an alias to fix
it (like we have for other metrics).??
I guess you mean the work done in CASSANDRA-15909? While I haven't worked on
that one, It looks to me from the ticket comments that a nice framework was
created that could help to quickly wrap up? :-)
??Since this was seen from scraping metrics it could, but that would imply that
3.x was not lazy and 4.x is? If we validate that they are present on a running
cluster than it can be safe to ride off as tooling issue.??
While I haven't validated this on a running cluster, a quick check of the code
suggests that this is the case. I can spend more time on that point later this
week. (I was asked to prioritize other tickets)
was (Author: e.dimitrova):
??ConditionNotMet looks like a rename regression, we should add an alias to fix
it (like we have for other metrics).??
I guess you mean the work done in CASSANDRA-15909? While I haven't worked on
that one, It looks to me from the ticket comments that a nice framework was
created that could help to quickly wrap up? :-)
??Since this was seen from scraping metrics it could, but that would imply that
3.x was not lazy and 4.x is? If we validate that they are present on a running
cluster than it can be safe to ride off as tooling issue.??
While I haven't validate on a running cluster, a quick check of the code
suggests that this is the case. I can spend more time on that point later this
week. (I was asked to prioritize other tickets)
> Missing JMX objects and attributes upgrading from 3.0 to 4.0
>
>
> Key: CASSANDRA-16083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16083
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: David Capwell
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Using the tools added in CASSANDRA-16082, below are the list of metrics
> missing in 4.0 but present in 3.0. The work here is to make sure we had
> proper deprecation for each metric, and if not to add it back.
> {code}
> $ tools/bin/jmxtool diff -f yaml cassandra-3.0-jmx.yaml trunk-jmx.yaml
> --ignore-missing-on-left
> Objects not in right:
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=EstimatedPartitionSizeHistogram
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=BloomFilterFalseRatio
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=ReplicaFilteringProtectionRequests
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=RowCacheHitOutOfRange
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=CounterMutationStage,name=MaxPoolSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=ColUpdateTimeDeltaHistogram
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=TombstoneScannedHistogram
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=ReadStage,name=ActiveTasks
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=WaitingOnFreeMemtableSpace
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasCommitTotalLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=MemtableOnHeapSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_aggregates,name=CasProposeLatency
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=AllMemtablesLiveDataSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=ViewReadTime
> org.apache.cassandra.db:type=HintedHandoffManager
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=BloomFilterDiskSpaceUsed
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=RequestResponseStage,name=PendingTasks
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=MemtableSwitchCount
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=MemtableOnHeapSize
>
[jira] [Commented] (CASSANDRA-16083) Missing JMX objects and attributes upgrading from 3.0 to 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241980#comment-17241980
]
Ekaterina Dimitrova commented on CASSANDRA-16083:
-
??ConditionNotMet looks like a rename regression, we should add an alias to fix
it (like we have for other metrics).??
I guess you mean the work done in CASSANDRA-15909? While I haven't worked on
that one, It looks to me from the ticket comments that a nice framework was
created that could help to quickly wrap up? :-)
??Since this was seen from scraping metrics it could, but that would imply that
3.x was not lazy and 4.x is? If we validate that they are present on a running
cluster than it can be safe to ride off as tooling issue.??
While I haven't validate on a running cluster, a quick check of the code
suggests that this is the case. I can spend more time on that point later this
week. (I was asked to prioritize other tickets)
> Missing JMX objects and attributes upgrading from 3.0 to 4.0
>
>
> Key: CASSANDRA-16083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16083
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: David Capwell
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Using the tools added in CASSANDRA-16082, below are the list of metrics
> missing in 4.0 but present in 3.0. The work here is to make sure we had
> proper deprecation for each metric, and if not to add it back.
> {code}
> $ tools/bin/jmxtool diff -f yaml cassandra-3.0-jmx.yaml trunk-jmx.yaml
> --ignore-missing-on-left
> Objects not in right:
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=EstimatedPartitionSizeHistogram
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=BloomFilterFalseRatio
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=ReplicaFilteringProtectionRequests
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=RowCacheHitOutOfRange
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=CasPrepareLatency
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=CounterMutationStage,name=MaxPoolSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=ColUpdateTimeDeltaHistogram
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=TombstoneScannedHistogram
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=ReadStage,name=ActiveTasks
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=WaitingOnFreeMemtableSpace
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_columnfamilies,name=CasCommitTotalLatency
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=hints,name=MemtableOnHeapSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=schema_aggregates,name=CasProposeLatency
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=batchlog,name=AllMemtablesLiveDataSize
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=ViewReadTime
> org.apache.cassandra.db:type=HintedHandoffManager
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=BloomFilterDiskSpaceUsed
> org.apache.cassandra.metrics:type=ThreadPools,path=request,scope=RequestResponseStage,name=PendingTasks
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=MemtableSwitchCount
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=hints,name=MemtableOnHeapSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=range_xfers,name=ReplicaFilteringProtectionRowsCachedPerQuery
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=views_builds_in_progress,name=SnapshotsSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=RecentBloomFilterFalsePositives
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=ColUpdateTimeDeltaHistogram
> org.apache.cassandra.metrics:type=ColumnFamily,keyspace=system,scope=range_xfers,name=SpeculativeRetries
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=LiveDiskSpaceUsed
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=views_builds_in_progress,name=ViewReadTime
> org.apache.cassandra.metrics:type=ThreadPools,path=internal,scope=MigrationStage,name=CompletedTasks
>
[jira] [Comment Edited] (CASSANDRA-15897) Dropping compact storage with 2.1-sstables on disk make them unreadable
[ https://issues.apache.org/jira/browse/CASSANDRA-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241928#comment-17241928 ] Ekaterina Dimitrova edited comment on CASSANDRA-15897 at 12/2/20, 12:42 AM: Patch rebased [here|https://github.com/ekaterinadimitrova2/cassandra/pull/79]. CI run can be found [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152]. There was a collision between this patch and CASSANDRA-16228 in [Tracker.java |#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28L184] To solve It I added a new flag [updatingSize|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28R209]. There are a few tests failing (same were failing before and after the rebase and they are not known failures) The only failing unit test is testDropSSTables which I [changed|https://github.com/apache/cassandra/commit/dba4a86306bc13f1b421c500570deb3a3f06414f] a bit to show what is the current sequence of messages to have it in mind while debugging. (That's why it is green in CircleCI) These are the other failures: _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ not sure about this timeout whether it is related; have to check *EDIT:* _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ I ran it locally a few times and it passes successfully so I think it was circle ci timeout. Also, it doesn't seem related jvm upgrade test [CompactStorage2to3UpgradeTest|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2942] Also 1 dtest [TestGossipingPropertyFileSnitch|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2940] I will try to do a more detailed review and try to work out the failures but I guess also 2 committers for review will be needed. Also, I haven't dealt with our Gossip implementation up to now. was (Author: e.dimitrova): Patch rebased [here|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0]. CI run can be found [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152]. There was a collision between this patch and CASSANDRA-16228 in [Tracker.java |#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28L184] To solve It I added a new flag [updatingSize|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28R209]. There are a few tests failing (same were failing before and after the rebase and they are not known failures) The only failing unit test is testDropSSTables which I [changed|https://github.com/apache/cassandra/commit/dba4a86306bc13f1b421c500570deb3a3f06414f] a bit to show what is the current sequence of messages to have it in mind while debugging. (That's why it is green in CircleCI) These are the other failures: _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ not sure about this timeout whether it is related; have to check *EDIT:* _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ I ran it locally a few times and it passes successfully so I think it was circle ci timeout. Also, it doesn't seem related jvm upgrade test [CompactStorage2to3UpgradeTest|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2942] Also 1 dtest [TestGossipingPropertyFileSnitch|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2940] I will try to do a more detailed review and try to work out the failures but I guess also 2 committers for review will be needed. Also, I haven't dealt with our Gossip implementation up to now. > Dropping compact storage with 2.1-sstables on disk make them unreadable > --- > > Key: CASSANDRA-15897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15897 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Marcus Eriksson >Assignee: Sylvain Lebresne >Priority: Normal > Fix For: 3.0.x, 4.0-beta > > > Test reproducing: > https://github.com/krummas/cassandra/commits/marcuse/dropcompactstorage -- This message was sent by Atlassian Jira
[jira] [Comment Edited] (CASSANDRA-15897) Dropping compact storage with 2.1-sstables on disk make them unreadable
[ https://issues.apache.org/jira/browse/CASSANDRA-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241928#comment-17241928 ] Ekaterina Dimitrova edited comment on CASSANDRA-15897 at 12/1/20, 11:41 PM: Patch rebased [here|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0]. CI run can be found [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152]. There was a collision between this patch and CASSANDRA-16228 in [Tracker.java |#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28L184] To solve It I added a new flag [updatingSize|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28R209]. There are a few tests failing (same were failing before and after the rebase and they are not known failures) The only failing unit test is testDropSSTables which I [changed|https://github.com/apache/cassandra/commit/dba4a86306bc13f1b421c500570deb3a3f06414f] a bit to show what is the current sequence of messages to have it in mind while debugging. (That's why it is green in CircleCI) These are the other failures: _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ not sure about this timeout whether it is related; have to check *EDIT:* _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ I ran it locally a few times and it passes successfully so I think it was circle ci timeout. Also, it doesn't seam related jvm upgrade test [CompactStorage2to3UpgradeTest|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2942] Also 1 dtest [TestGossipingPropertyFileSnitch|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2940] I will try to do a more detailed review and try to work out the failures but I guess also 2 committers for review will be needed. Also, I haven't dealt with our Gossip implementation up to now. was (Author: e.dimitrova): Patch rebased [here| https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0]. CI run can be found [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152]. There was a collision between this patch and CASSANDRA-16228 in [Tracker.java |#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28L184] To solve It I added a new flag [updatingSize|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28R209]. There are a few tests failing (same were failing before and after the rebase and they are not known failures) The only failing unit test is testDropSSTables which I [changed|https://github.com/apache/cassandra/commit/dba4a86306bc13f1b421c500570deb3a3f06414f] a bit to show what is the current sequence of messages to have it in mind while debugging. (That's why it is green in CircleCI) These are the other failures: _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ not sure about this timeout whether it is related; have to check jvm upgrade test [CompactStorage2to3UpgradeTest|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2942] Also 1 dtest [TestGossipingPropertyFileSnitch|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2940] I will try to do a more detailed review and try to work out the failures but I guess also 2 committers for review will be needed. Also, I haven't dealt with our Gossip implementation up to now. > Dropping compact storage with 2.1-sstables on disk make them unreadable > --- > > Key: CASSANDRA-15897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15897 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Marcus Eriksson >Assignee: Sylvain Lebresne >Priority: Normal > Fix For: 3.0.x, 4.0-beta > > > Test reproducing: > https://github.com/krummas/cassandra/commits/marcuse/dropcompactstorage -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail:
[jira] [Comment Edited] (CASSANDRA-15897) Dropping compact storage with 2.1-sstables on disk make them unreadable
[ https://issues.apache.org/jira/browse/CASSANDRA-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241928#comment-17241928 ] Ekaterina Dimitrova edited comment on CASSANDRA-15897 at 12/1/20, 11:41 PM: Patch rebased [here|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0]. CI run can be found [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152]. There was a collision between this patch and CASSANDRA-16228 in [Tracker.java |#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28L184] To solve It I added a new flag [updatingSize|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28R209]. There are a few tests failing (same were failing before and after the rebase and they are not known failures) The only failing unit test is testDropSSTables which I [changed|https://github.com/apache/cassandra/commit/dba4a86306bc13f1b421c500570deb3a3f06414f] a bit to show what is the current sequence of messages to have it in mind while debugging. (That's why it is green in CircleCI) These are the other failures: _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ not sure about this timeout whether it is related; have to check *EDIT:* _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ I ran it locally a few times and it passes successfully so I think it was circle ci timeout. Also, it doesn't seem related jvm upgrade test [CompactStorage2to3UpgradeTest|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2942] Also 1 dtest [TestGossipingPropertyFileSnitch|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2940] I will try to do a more detailed review and try to work out the failures but I guess also 2 committers for review will be needed. Also, I haven't dealt with our Gossip implementation up to now. was (Author: e.dimitrova): Patch rebased [here|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0]. CI run can be found [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152]. There was a collision between this patch and CASSANDRA-16228 in [Tracker.java |#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28L184] To solve It I added a new flag [updatingSize|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28R209]. There are a few tests failing (same were failing before and after the rebase and they are not known failures) The only failing unit test is testDropSSTables which I [changed|https://github.com/apache/cassandra/commit/dba4a86306bc13f1b421c500570deb3a3f06414f] a bit to show what is the current sequence of messages to have it in mind while debugging. (That's why it is green in CircleCI) These are the other failures: _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ not sure about this timeout whether it is related; have to check *EDIT:* _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ I ran it locally a few times and it passes successfully so I think it was circle ci timeout. Also, it doesn't seam related jvm upgrade test [CompactStorage2to3UpgradeTest|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2942] Also 1 dtest [TestGossipingPropertyFileSnitch|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2940] I will try to do a more detailed review and try to work out the failures but I guess also 2 committers for review will be needed. Also, I haven't dealt with our Gossip implementation up to now. > Dropping compact storage with 2.1-sstables on disk make them unreadable > --- > > Key: CASSANDRA-15897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15897 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Marcus Eriksson >Assignee: Sylvain Lebresne >Priority: Normal > Fix For: 3.0.x, 4.0-beta > > > Test reproducing: > https://github.com/krummas/cassandra/commits/marcuse/dropcompactstorage -- This message was
[jira] [Comment Edited] (CASSANDRA-16079) Improve dtest runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-16079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241931#comment-17241931 ] Michael Semb Wever edited comment on CASSANDRA-16079 at 12/1/20, 11:14 PM: --- Here's a clean run: https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest/249/ This builds on the following patches: - cassandra [mck/trunk_13701|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_13701] - cassandra [thelastpickle:paulo/trunk_16205|https://github.com/apache/cassandra/compare/trunk...thelastpickle:paulo/trunk_16205] - ccm [mck/16205|https://github.com/riptano/ccm/compare/trunk...thelastpickle:mck/16205] - cassandra-dtest [mck/16079|https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16079] 16205 looks to be in final review, once that's merged, then this ticket is open for review. was (Author: michaelsembwever): Here's a clean run: https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest/249/ This builds on the following patches: - cassandra [mck/trunk_13701||https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_13701] - cassandra [thelastpickle:paulo/trunk_16205||https://github.com/apache/cassandra/compare/trunk...thelastpickle:paulo/trunk_16205] - ccm [mck/16205|https://github.com/riptano/ccm/compare/trunk...thelastpickle:mck/16205] - cassandra-dtest [mck/16079|https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16079] 16205 looks to be in final review, once that's merged, then this ticket is open for review. > Improve dtest runtime > - > > Key: CASSANDRA-16079 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16079 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Adam Holmberg >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0-beta > > Attachments: Screenshot 2020-09-19 at 12.32.21.png > > > A recent ticket, CASSANDRA-13701, changed the way dtests run, resulting in a > [30% increase in run > time|https://www.mail-archive.com/dev@cassandra.apache.org/msg15606.html]. > While that change was accepted, we wanted to spin out a ticket to optimize > dtests in an attempt to gain back some of that runtime. > At this time we don't have concrete improvements in mind, so the first order > of this ticket will be to analyze the state of things currently, and try to > ascertain some valuable optimizations. Once the problems are understood, we > will break down subtasks to divide the work. > Some areas to consider: > * cluster reuse > * C* startup optimizations > * Tests that should be ported to in-JVM dtest or even unit 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] [Commented] (CASSANDRA-16079) Improve dtest runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-16079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241931#comment-17241931 ] Michael Semb Wever commented on CASSANDRA-16079: Here's a clean run: https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest/249/ This builds on the following patches: - cassandra [mck/trunk_13701||https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_13701] - cassandra [thelastpickle:paulo/trunk_16205||https://github.com/apache/cassandra/compare/trunk...thelastpickle:paulo/trunk_16205] - ccm [mck/16205|https://github.com/riptano/ccm/compare/trunk...thelastpickle:mck/16205] - cassandra-dtest [mck/16079|https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16079] 16205 looks to be in final review, once that's merged, then this ticket is open for review. > Improve dtest runtime > - > > Key: CASSANDRA-16079 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16079 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Adam Holmberg >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0-beta > > Attachments: Screenshot 2020-09-19 at 12.32.21.png > > > A recent ticket, CASSANDRA-13701, changed the way dtests run, resulting in a > [30% increase in run > time|https://www.mail-archive.com/dev@cassandra.apache.org/msg15606.html]. > While that change was accepted, we wanted to spin out a ticket to optimize > dtests in an attempt to gain back some of that runtime. > At this time we don't have concrete improvements in mind, so the first order > of this ticket will be to analyze the state of things currently, and try to > ascertain some valuable optimizations. Once the problems are understood, we > will break down subtasks to divide the work. > Some areas to consider: > * cluster reuse > * C* startup optimizations > * Tests that should be ported to in-JVM dtest or even unit 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-15897) Dropping compact storage with 2.1-sstables on disk make them unreadable
[ https://issues.apache.org/jira/browse/CASSANDRA-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241928#comment-17241928 ] Ekaterina Dimitrova edited comment on CASSANDRA-15897 at 12/1/20, 11:06 PM: Patch rebased [here| https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0]. CI run can be found [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152]. There was a collision between this patch and CASSANDRA-16228 in [Tracker.java |#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28L184] To solve It I added a new flag [updatingSize|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28R209]. There are a few tests failing (same were failing before and after the rebase and they are not known failures) The only failing unit test is testDropSSTables which I [changed|https://github.com/apache/cassandra/commit/dba4a86306bc13f1b421c500570deb3a3f06414f] a bit to show what is the current sequence of messages to have it in mind while debugging. (That's why it is green in CircleCI) These are the other failures: _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ not sure about this timeout whether it is related; have to check jvm upgrade test [CompactStorage2to3UpgradeTest|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2942] Also 1 dtest [TestGossipingPropertyFileSnitch|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2940] I will try to do a more detailed review and try to work out the failures but I guess also 2 committers for review will be needed. Also, I haven't dealt with our Gossip implementation up to now. was (Author: e.dimitrova): Patch rebased [here|]. CI run can be found [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152]. There was a collision between this patch and CASSANDRA-16228 in [Tracker.java |#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28L184] To solve It I added a new flag [updatingSize|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28R209]. There are a few tests failing (same were failing before and after the rebase and they are not known failures) The only failing unit test is testDropSSTables which I [changed|https://github.com/apache/cassandra/commit/dba4a86306bc13f1b421c500570deb3a3f06414f] a bit to show what is the current sequence of messages to have it in mind while debugging. (That's why it is green in CircleCI) These are the other failures: _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ not sure about this timeout whether it is related; have to check jvm upgrade test [CompactStorage2to3UpgradeTest|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2942] Also 1 dtest [TestGossipingPropertyFileSnitch|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2940] I will try to do a more detailed review and try to work out the failures but I guess also 2 committers for review will be needed. Also, I haven't dealt with our Gossip implementation up to now. > Dropping compact storage with 2.1-sstables on disk make them unreadable > --- > > Key: CASSANDRA-15897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15897 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Marcus Eriksson >Assignee: Sylvain Lebresne >Priority: Normal > Fix For: 3.0.x, 4.0-beta > > > Test reproducing: > https://github.com/krummas/cassandra/commits/marcuse/dropcompactstorage -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15897) Dropping compact storage with 2.1-sstables on disk make them unreadable
[ https://issues.apache.org/jira/browse/CASSANDRA-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241928#comment-17241928 ] Ekaterina Dimitrova commented on CASSANDRA-15897: - Patch rebased [here|]. CI run can be found [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152]. There was a collision between this patch and CASSANDRA-16228 in [Tracker.java |#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28L184] To solve It I added a new flag [updatingSize|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:15897-3.0#diff-9baecde49b36a386d6200cb163d482dd70a816019ba2b45f0ff25c3ca4eabf28R209]. There are a few tests failing (same were failing before and after the rebase and they are not known failures) The only failing unit test is testDropSSTables which I [changed|https://github.com/apache/cassandra/commit/dba4a86306bc13f1b421c500570deb3a3f06414f] a bit to show what is the current sequence of messages to have it in mind while debugging. (That's why it is green in CircleCI) These are the other failures: _repairUnreplicatedKStest - org.apache.cassandra.distributed.test.RepairOperationalTest -_ not sure about this timeout whether it is related; have to check jvm upgrade test [CompactStorage2to3UpgradeTest|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2942] Also 1 dtest [TestGossipingPropertyFileSnitch|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/529/workflows/7101b314-681a-40b9-a266-6286c4f27152/jobs/2940] I will try to do a more detailed review and try to work out the failures but I guess also 2 committers for review will be needed. Also, I haven't dealt with our Gossip implementation up to now. > Dropping compact storage with 2.1-sstables on disk make them unreadable > --- > > Key: CASSANDRA-15897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15897 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Marcus Eriksson >Assignee: Sylvain Lebresne >Priority: Normal > Fix For: 3.0.x, 4.0-beta > > > Test reproducing: > https://github.com/krummas/cassandra/commits/marcuse/dropcompactstorage -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-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:comment-tabpanel=17241918#comment-17241918
]
Yifan Cai commented on CASSANDRA-16143:
---
Thanks [~aholmber]. So the bot links the PR, if its title starts with the
ticket number.
> 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: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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
>
[jira] [Comment Edited] (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:comment-tabpanel=17241905#comment-17241905
]
Adam Holmberg edited comment on CASSANDRA-16143 at 12/1/20, 10:20 PM:
--
Added a few comments and questions to the PR.
I just noticed the PR is somehow linked and updating the Work Log section of
this ticket. Is that new?
was (Author: aholmber):
Added a few comments and questions to the PR.
> 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: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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)
> [?:?]
>
[jira] [Commented] (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:comment-tabpanel=17241905#comment-17241905
]
Adam Holmberg commented on CASSANDRA-16143:
---
Added a few comments and questions to the PR.
> 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: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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
[jira] [Updated] (CASSANDRA-16296) Join new node to cluster failing on C* version 4
[
https://issues.apache.org/jira/browse/CASSANDRA-16296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16296:
--
Bug Category: Parent values: Availability(12983)Level 1 values: Process
Crash(12992)
Complexity: Normal
Component/s: Local/Startup and Shutdown
Discovered By: User Report
Fix Version/s: 4.0-beta
Severity: Normal
Status: Open (was: Triage Needed)
> Join new node to cluster failing on C* version 4
>
>
> Key: CASSANDRA-16296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16296
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Yakir Gibraltar
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Hi, i'm using cassandra 4.0-beta3,
> Join new node failing,
> Current status:
> {code}
> [root@rc801 ~]# nodetool status
> Datacenter: V4CH
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address LoadTokens Owns (effective) Host ID
>Rack
> UN 1.1.1.1 356.55 KiB 128 ?
> 92ae4c39-edb3-4e67-8623-b49fd8301b66 RAC1
> UN 2.2.2.2 424.36 KiB 128 ?
> d80647a8-32b2-4a8f-8022-f5ae3ce8fbb2 RAC1
> Datacenter: V4NJ
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address LoadTokens Owns (effective) Host ID
>Rack
> UN 3.3.3.3 322.97 KiB 128 ?
> 0106ce0b-18be-4321-8247-843076ff42e6 RAC1
> UN 4.4.4.4 297.6 KiB 128 ?
> d81e2b7d-9221-4b1b-86c8-e8956e3eec07 RAC1
> UN 5.5.5.5 324.75 KiB 128 ?
> 5dfbaf14-8310-4d64-b61a-9da0a7a8a620 RAC1
> {code}
> Error on new host (7.7.7.7):
> {code}
> INFO [main] 2020-11-22 09:27:36,592 RangeStreamer.java:323 - Bootstrap:
> range Full(/7.7.7.7:7000,(-7734271291904743823,-7725025391901227341]) exists
> on Full(/1.1.1.1:7000,(-7734271291904743823,-7725025391901227341]) for
> keyspace system_traces
> ERROR [main] 2020-11-22 09:27:36,609 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Multiple strict sources found for
> Full(/7.7.7.7:7000,(9208454697546654053,-9212763148842799409]), sources:
> [Full(/2.2.2.2:7000,(9189373804905478622,-9212763148842799409]),
> Full(/1.1.1.1:7000,(9189373804905478622,-9212763148842799409])]
> at
> org.apache.cassandra.dht.RangeStreamer.calculateRangesToFetchWithPreferredEndpoints(RangeStreamer.java:517)
> at
> org.apache.cassandra.dht.RangeStreamer.calculateRangesToFetchWithPreferredEndpoints(RangeStreamer.java:383)
> at
> org.apache.cassandra.dht.RangeStreamer.addRanges(RangeStreamer.java:320)
> at
> org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:81)
> at
> org.apache.cassandra.service.StorageService.startBootstrap(StorageService.java:1635)
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1612)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)
> INFO [StorageServiceShutdownHook] 2020-11-22 09:27:36,616
> HintsService.java:220 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2020-11-22 09:27:36,617 Gossiper.java:1849
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2020-11-22 09:27:36,617
> MessagingService.java:441 - Waiting for messaging service to quiesce
> {code}
> Errors on seed node:
> {code}
> INFO [Messaging-EventLoop-3-37] 2020-11-22 09:26:54,121
> InboundConnectionInitiator.java:459 -
> /7.7.7.7:7000(/7.7.7.7:45490)->/1.1.1.1:7000-URGENT_MESSAGES-f412b9ba
> messaging connection established, version = 12, framing = LZ4, encryption =
> disabled
> INFO [Messaging-EventLoop-3-40] 2020-11-22 09:26:54,157
> OutboundConnection.java:1151 -
> /1.1.1.1:7000(/1.1.1.1:38678)->/7.7.7.7:7000-URGENT_MESSAGES-3b23f639
> successfully connected, version = 12, framing = LZ4, encryption = disabled
> INFO [GossipStage:1] 2020-11-22 09:26:56,109 Gossiper.java:1248
[jira] [Updated] (CASSANDRA-16303) ClassNotFoundException: com.googlecode.concurrenttrees.radix.node.NodeFactory
[ https://issues.apache.org/jira/browse/CASSANDRA-16303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16303: -- Bug Category: Parent values: Correctness(12982)Level 1 values: API / Semantic Implementation(12988) Complexity: Low Hanging Fruit Discovered By: User Report Fix Version/s: 4.0-beta Severity: Normal Status: Open (was: Triage Needed) marking as 4.0 beta to make sure its loaded properly fore the release. > ClassNotFoundException: com.googlecode.concurrenttrees.radix.node.NodeFactory > - > > Key: CASSANDRA-16303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16303 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Adrian Cole >Priority: Normal > Fix For: 4.0-beta > > > If you look at the pom for cassandra-all 4.0.0-beta-3, you'll notice that > concurrent-trees is in dependencyManagement, but not dependencies. This might > be going unnoticed as sasi is disabled by default now, but it can lead to a > ClassNotFoundException. I presume this was accidental -- This message was sent by Atlassian Jira (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-16213) Cannot replace_address /X because it doesn't exist in gossip
[ https://issues.apache.org/jira/browse/CASSANDRA-16213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241860#comment-17241860 ] David Capwell commented on CASSANDRA-16213: --- To keep history clear for review, I split each change into different commits * removed blocking replace on state: https://github.com/apache/cassandra/pull/780/commits/ebc844428d928789835f2a839ebbe1230aed68fd * load token/host_id lazy during shadow round rather than startup: https://github.com/apache/cassandra/pull/780/commits/748d437028843de50b0e271cdacec4dfd27af2df * host replacement no longer injects a "normal" state transition, but updates token metadata and gossip state explicitly: https://github.com/apache/cassandra/pull/780/commits/650a3541da65a367cbce8a623e040c2f4776f23f > Cannot replace_address /X because it doesn't exist in gossip > > > Key: CASSANDRA-16213 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16213 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Membership >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-beta > > > We see this exception around nodes crashing and trying to do a host > replacement; this error appears to be correlated around multiple node > failures. > A simplified case to trigger this is the following > *) Have a N node cluster > *) Shutdown all N nodes > *) Bring up N-1 nodes (at least 1 seed, else replace seed) > *) Host replace the N-1th node -> this will fail with the above > The reason this happens is that the N-1th node isn’t gossiping anymore, and > the existing nodes do not have its details in gossip (but have the details in > the peers table), so the host replacement fails as the node isn’t known in > gossip. > This affects all versions (tested 3.0 and trunk, assume 2.2 as well) -- This message was sent by Atlassian Jira (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-16213) Cannot replace_address /X because it doesn't exist in gossip
[ https://issues.apache.org/jira/browse/CASSANDRA-16213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241853#comment-17241853 ] David Capwell commented on CASSANDRA-16213: --- [~samt] pushed changes based off your version. I made a few changes (we spoke in slack about them) 1) rather than modify the block which checks the downed host is "old enough", we inject the node while doing prepare; this keeps the logic centralized 2) keep the isEmpty logic and flag to enable/disable this feature. If feature is disabled then this patch has no affect (outside of shadow round sending empty). [~paulo] would be good to get your eyes as well! > Cannot replace_address /X because it doesn't exist in gossip > > > Key: CASSANDRA-16213 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16213 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Membership >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-beta > > > We see this exception around nodes crashing and trying to do a host > replacement; this error appears to be correlated around multiple node > failures. > A simplified case to trigger this is the following > *) Have a N node cluster > *) Shutdown all N nodes > *) Bring up N-1 nodes (at least 1 seed, else replace seed) > *) Host replace the N-1th node -> this will fail with the above > The reason this happens is that the N-1th node isn’t gossiping anymore, and > the existing nodes do not have its details in gossip (but have the details in > the peers table), so the host replacement fails as the node isn’t known in > gossip. > This affects all versions (tested 3.0 and trunk, assume 2.2 as well) -- This message was sent by Atlassian Jira (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-16275) Update python driver used by cassandra-dtest
[
https://issues.apache.org/jira/browse/CASSANDRA-16275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-16275:
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/192b70607a0c4a96f524bd5dc0c19c3a28f938f0
https://github.com/apache/cassandra/commit/466c65a6c21d6c74a6a20eafbbf18a2267e83e7f
https://github.com/apache/cassandra-builds/commit/acbf6d5b0396f62f0545d673e3fcd
(was:
https://github.com/apache/cassandra-dtest/commit/192b70607a0c4a96f524bd5dc0c19c3a28f938f0)
> Update python driver used by cassandra-dtest
>
>
> Key: CASSANDRA-16275
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16275
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: NA
>
>
> In order to commit CASSANDRA-15299, the python driver used by the dtests
> needs to include PYTHON-1258, support for V5 framing.
> Updating the python driver's cassandra-test branch to latest trunk causes 1
> additional dtest failure in
> {{auth_test.py::TestAuth::test_handle_corrupt_role_data}} because the
> {{ServerError}} response is now subject to the configured {{retry_policy}}.
> This means the error ultimately returned from the driver is
> {{NoHostAvailable}}, rather than {{ServerError}}.
> I'll open a dtest pr to change the expectation in the test and we can commit
> that when the cassandra-test branch is updated.
> cc [~aholmber] [~aboudreault]
--
This message was sent by Atlassian Jira
(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-16275) Update python driver used by cassandra-dtest
[
https://issues.apache.org/jira/browse/CASSANDRA-16275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-16275:
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks [~mck]. Committed the changes to {{cassandra-builds}} in
{{acbf6d5b0396f62f0545d673e3fcd498535aa9f6}} and the Circle CI config changes
to {{cassandra}} in {{466c65a6c21d6c74a6a20eafbbf18a2267e83e7f}}
> Update python driver used by cassandra-dtest
>
>
> Key: CASSANDRA-16275
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16275
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: NA
>
>
> In order to commit CASSANDRA-15299, the python driver used by the dtests
> needs to include PYTHON-1258, support for V5 framing.
> Updating the python driver's cassandra-test branch to latest trunk causes 1
> additional dtest failure in
> {{auth_test.py::TestAuth::test_handle_corrupt_role_data}} because the
> {{ServerError}} response is now subject to the configured {{retry_policy}}.
> This means the error ultimately returned from the driver is
> {{NoHostAvailable}}, rather than {{ServerError}}.
> I'll open a dtest pr to change the expectation in the test and we can commit
> that when the cassandra-test branch is updated.
> cc [~aholmber] [~aboudreault]
--
This message was sent by Atlassian Jira
(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-16275) Update python driver used by cassandra-dtest
[
https://issues.apache.org/jira/browse/CASSANDRA-16275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-16275:
Status: Ready to Commit (was: Review In Progress)
> Update python driver used by cassandra-dtest
>
>
> Key: CASSANDRA-16275
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16275
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: NA
>
>
> In order to commit CASSANDRA-15299, the python driver used by the dtests
> needs to include PYTHON-1258, support for V5 framing.
> Updating the python driver's cassandra-test branch to latest trunk causes 1
> additional dtest failure in
> {{auth_test.py::TestAuth::test_handle_corrupt_role_data}} because the
> {{ServerError}} response is now subject to the configured {{retry_policy}}.
> This means the error ultimately returned from the driver is
> {{NoHostAvailable}}, rather than {{ServerError}}.
> I'll open a dtest pr to change the expectation in the test and we can commit
> that when the cassandra-test branch is updated.
> cc [~aholmber] [~aboudreault]
--
This message was sent by Atlassian Jira
(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-16275) Update python driver used by cassandra-dtest
[
https://issues.apache.org/jira/browse/CASSANDRA-16275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-16275:
Status: Review In Progress (was: Patch Available)
> Update python driver used by cassandra-dtest
>
>
> Key: CASSANDRA-16275
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16275
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: NA
>
>
> In order to commit CASSANDRA-15299, the python driver used by the dtests
> needs to include PYTHON-1258, support for V5 framing.
> Updating the python driver's cassandra-test branch to latest trunk causes 1
> additional dtest failure in
> {{auth_test.py::TestAuth::test_handle_corrupt_role_data}} because the
> {{ServerError}} response is now subject to the configured {{retry_policy}}.
> This means the error ultimately returned from the driver is
> {{NoHostAvailable}}, rather than {{ServerError}}.
> I'll open a dtest pr to change the expectation in the test and we can commit
> that when the cassandra-test branch is updated.
> cc [~aholmber] [~aboudreault]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch trunk updated: Rebuilding image to include updated python driver (via cassandra-dtest)
This is an automated email from the ASF dual-hosted git repository.
samt pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/trunk by this push:
new acbf6d5 Rebuilding image to include updated python driver (via
cassandra-dtest)
acbf6d5 is described below
commit acbf6d5b0396f62f0545d673e3fcd498535aa9f6
Author: Sam Tunnicliffe
AuthorDate: Mon Nov 30 15:17:38 2020 +
Rebuilding image to include updated python driver (via cassandra-dtest)
Patch by Sam Tunnicliffe; reviewed by Mick Semb Wever for CASSANDRA-16275
---
docker/testing/ubuntu1910_j11.docker| 2 +-
docker/testing/ubuntu1910_j11_w_dependencies.docker | 4 ++--
jenkins-dsl/cassandra_job_dsl_seed.groovy | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/docker/testing/ubuntu1910_j11.docker
b/docker/testing/ubuntu1910_j11.docker
index e56ac5c..5351b1e 100644
--- a/docker/testing/ubuntu1910_j11.docker
+++ b/docker/testing/ubuntu1910_j11.docker
@@ -11,7 +11,7 @@
# limitations under the License.
FROM ubuntu:19.10
-MAINTAINER Eduard Tudenhoefner
+MAINTAINER Sam Tunnicliffe
# install our python dependencies and some other stuff we need
# libev4 libev-dev are for the python driver / libssl-dev is for python3.6
diff --git a/docker/testing/ubuntu1910_j11_w_dependencies.docker
b/docker/testing/ubuntu1910_j11_w_dependencies.docker
index ac8a541..4ea6fb5 100644
--- a/docker/testing/ubuntu1910_j11_w_dependencies.docker
+++ b/docker/testing/ubuntu1910_j11_w_dependencies.docker
@@ -11,8 +11,8 @@
# limitations under the License.
# base things off the testing image without dependencies warmed up
-FROM nastra/cassandra-testing-ubuntu1910-java11
-MAINTAINER Eduard Tudenhoefner
+FROM beobal/cassandra-testing-ubuntu1910-java11
+MAINTAINER Sam Tunnicliffe
USER cassandra
ENV HOME /home/cassandra
diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index 1e0adb6..828acb7 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -59,7 +59,7 @@ def dtestTargets = ['dtest', 'dtest-novnode',
'dtest-offheap', 'dtest-large', 'd
if(binding.hasVariable("CASSANDRA_DTEST_TEST_TARGETS")) {
dtestTargets = "${CASSANDRA_DTEST_TEST_TARGETS}".split(",")
}
-def dtestDockerImage = 'nastra/cassandra-testing-ubuntu1910-java11'
+def dtestDockerImage = 'beobal/cassandra-testing-ubuntu1910-java11'
if(binding.hasVariable("CASSANDRA_DOCKER_IMAGE")) {
dtestDockerImage = "${CASSANDRA_DOCKER_IMAGE}"
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15299:
Fix Version/s: (was: 4.0-alpha)
4.0-beta4
Source Control Link:
https://github.com/apache/cassandra/commit/a7c4ba9eeecb365e7c4753d8eaab747edd9a632a
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks everybody for the input, feedback, reviews, help and not to mention the
python and java driver patches.
committed to trunk in {{a7c4ba9eeecb365e7c4753d8eaab747edd9a632a}}
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-beta4
>
> Attachments: Process CQL Frame.png, V5 Flow Chart.png
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> particular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15299:
Status: Ready to Commit (was: Review In Progress)
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-alpha
>
> Attachments: Process CQL Frame.png, V5 Flow Chart.png
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> particular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15299:
Status: Review In Progress (was: Patch Available)
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-alpha
>
> Attachments: Process CQL Frame.png, V5 Flow Chart.png
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> particular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository.
samt pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 3f1126195aafb4a0142a1a2158dec39583e73c11
Merge: a7f50c9 de85f43
Author: Sam Tunnicliffe
AuthorDate: Tue Dec 1 18:53:59 2020 +
Merge branch 'cassandra-3.0' into cassandra-3.11
.circleci/config-2_1.yml | 8
.circleci/config.yml | 40
.circleci/config.yml.HIGHRES | 40
.circleci/config.yml.LOWRES | 40
4 files changed, 64 insertions(+), 64 deletions(-)
diff --cc .circleci/config.yml
index b0db851,dda7046..c45f384
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@@ -2,7 -2,7 +2,7 @@@ version:
jobs:
j8_jvm_upgrade_dtests:
docker:
- - image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306
-- image:
beobal/cassandra-testing-ubuntu1810-java11-w-dependencies:20201130
++- image:
beobal/cassandra-testing-ubuntu1910-java11-w-dependencies:20201130
resource_class: medium
working_directory: ~/
shell: /bin/bash -eo pipefail -l
@@@ -330,55 -330,9 +330,55 @@@
- CCM_HEAP_NEWSIZE: 256M
- JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64
- JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64
+ utests_stress:
+docker:
- - image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306
++- image:
beobal/cassandra-testing-ubuntu1810-java11-w-dependencies:20201130
+resource_class: medium
+working_directory: ~/
+shell: /bin/bash -eo pipefail -l
+parallelism: 1
+steps:
+- attach_workspace:
+at: /home/cassandra
+- run:
+name: Run Unit Tests (stress-test)
+command: |
+ export PATH=$JAVA_HOME/bin:$PATH
+ time mv ~/cassandra /tmp
+ cd /tmp/cassandra
+ if [ -d ~/dtest_jars ]; then
+cp ~/dtest_jars/dtest* /tmp/cassandra/build/
+ fi
+ ant stress-test
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=unit
+no_output_timeout: 15m
+- store_test_results:
+path: /tmp/cassandra/build/test/output/
+- store_artifacts:
+path: /tmp/cassandra/build/test/output
+destination: junitxml
+- store_artifacts:
+path: /tmp/cassandra/build/test/logs
+destination: logs
+environment:
+- JAVA8_HOME: /usr/lib/jvm/java-8-openjdk-amd64
+- ANT_HOME: /usr/share/ant
+- LANG: en_US.UTF-8
+- KEEP_TEST_DIR: true
+- DEFAULT_DIR: /home/cassandra/cassandra-dtest
+- PYTHONIOENCODING: utf-8
+- PYTHONUNBUFFERED: true
+- CASS_DRIVER_NO_EXTENSIONS: true
+- CASS_DRIVER_NO_CYTHON: true
+- CASSANDRA_SKIP_SYNC: true
+- DTEST_REPO: git://github.com/apache/cassandra-dtest.git
+- DTEST_BRANCH: trunk
+- CCM_MAX_HEAP_SIZE: 1024M
+- CCM_HEAP_NEWSIZE: 256M
+- JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64
+- JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64
j8_unit_tests:
docker:
- - image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306
+ - image:
beobal/cassandra-testing-ubuntu1810-java11-w-dependencies:20201130
resource_class: medium
working_directory: ~/
shell: /bin/bash -eo pipefail -l
diff --cc .circleci/config.yml.HIGHRES
index 834f046,cd52b72..cf18b13
--- a/.circleci/config.yml.HIGHRES
+++ b/.circleci/config.yml.HIGHRES
@@@ -330,55 -330,9 +330,55 @@@ jobs
- CCM_HEAP_NEWSIZE: 512M
- JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64
- JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64
+ utests_stress:
+docker:
- - image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306
++- image:
beobal/cassandra-testing-ubuntu1910-java11-w-dependencies:20201130
+resource_class: xlarge
+working_directory: ~/
+shell: /bin/bash -eo pipefail -l
+parallelism: 1
+steps:
+- attach_workspace:
+at: /home/cassandra
+- run:
+name: Run Unit Tests (stress-test)
+command: |
+ export PATH=$JAVA_HOME/bin:$PATH
+ time mv ~/cassandra /tmp
+ cd /tmp/cassandra
+ if [ -d ~/dtest_jars ]; then
+cp ~/dtest_jars/dtest* /tmp/cassandra/build/
+ fi
+ ant stress-test
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=unit
+no_output_timeout: 15m
+- store_test_results:
+path: /tmp/cassandra/build/test/output/
+- store_artifacts:
+path: /tmp/cassandra/build/test/output
+destination: junitxml
+- store_artifacts:
+path: /tmp/cassandra/build/test/logs
+destination: logs
+environment:
+- JAVA8_HOME: /usr/lib/jvm/java-8-openjdk-amd64
+
[cassandra] branch cassandra-2.2 updated: Update to latest docker image for CircleCI
This is an automated email from the ASF dual-hosted git repository. samt 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 466c65a Update to latest docker image for CircleCI 466c65a is described below commit 466c65a6c21d6c74a6a20eafbbf18a2267e83e7f Author: Sam Tunnicliffe AuthorDate: Tue Dec 1 18:52:13 2020 + Update to latest docker image for CircleCI Patch by Sam Tunnicliffe; reviewed by Mick Semb Wever for CASSANDRA-16275 --- .circleci/config-2_1.yml | 8 .circleci/config.yml | 34 +- .circleci/config.yml.HIGHRES | 34 +- .circleci/config.yml.LOWRES | 34 +- 4 files changed, 55 insertions(+), 55 deletions(-) diff --git a/.circleci/config-2_1.yml b/.circleci/config-2_1.yml index 79332a8..44bf4ca 100644 --- a/.circleci/config-2_1.yml +++ b/.circleci/config-2_1.yml @@ -102,7 +102,7 @@ executors: type: string default: medium docker: - - image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306 + - image: beobal/cassandra-testing-ubuntu1910-java11-w-dependencies:20201130 resource_class: << parameters.exec_resource_class >> working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -382,7 +382,7 @@ commands: # if additional dependencies were added to requirmeents.txt and the docker image hasn't been updated # we'd have to install it here at runtime -- which will make things slow, so do yourself a favor and # rebuild the docker image! (it automatically pulls the latest requirements.txt on build) - source ~/env/bin/activate + source ~/env3.6/bin/activate export PATH=$JAVA_HOME/bin:$PATH pip3 install --upgrade -r ~/cassandra-dtest/requirements.txt pip3 freeze @@ -410,7 +410,7 @@ commands: # which we do via the `circleci` cli tool. cd cassandra-dtest - source ~/env/bin/activate + source ~/env3.6/bin/activate export PATH=$JAVA_HOME/bin:$PATH if [ -n '<>' ]; then @@ -446,7 +446,7 @@ commands: echo "cat /tmp/split_dtest_tests_<>_final.txt" cat /tmp/split_dtest_tests_<>_final.txt -source ~/env/bin/activate +source ~/env3.6/bin/activate export PATH=$JAVA_HOME/bin:$PATH if [ -n '<>' ]; then export <> diff --git a/.circleci/config.yml b/.circleci/config.yml index 0997d8a..862d4a1 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -2,7 +2,7 @@ version: 2 jobs: build: docker: -- image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306 +- image: beobal/cassandra-testing-ubuntu1910-java11-w-dependencies:20201130 resource_class: medium working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -77,7 +77,7 @@ jobs: - JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64 j8_unit_tests: docker: -- image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306 +- image: beobal/cassandra-testing-ubuntu1910-java11-w-dependencies:20201130 resource_class: medium working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -166,7 +166,7 @@ jobs: - JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64 j8_jvm_dtests: docker: -- image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306 +- image: beobal/cassandra-testing-ubuntu1910-java11-w-dependencies:20201130 resource_class: medium working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -255,7 +255,7 @@ jobs: - JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64 utests_long: docker: -- image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306 +- image: beobal/cassandra-testing-ubuntu1910-java11-w-dependencies:20201130 resource_class: medium working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -298,7 +298,7 @@ jobs: - JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64 utests_compression: docker: -- image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306 +- image: beobal/cassandra-testing-ubuntu1910-java11-w-dependencies:20201130 resource_class: medium working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -387,7 +387,7 @@ jobs: - JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64 j8_dtests-with-vnodes: docker: -- image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306 +- image: beobal/cassandra-testing-ubuntu1910-java11-w-dependencies:20201130 resource_class: medium working_directory: ~/ shell: /bin/bash -eo pipefail -l @@ -406,18 +406,18 @@ jobs: # if additional dependencies were added to requirmeents.txt and the docker
[cassandra] branch trunk updated (a7c4ba9 -> df40153)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from a7c4ba9 Improve checksumming and compression in protocol V5 new 466c65a Update to latest docker image for CircleCI new de85f43 Merge branch 'cassandra-2.2' into cassandra-3.0 new 3f11261 Merge branch 'cassandra-3.0' into cassandra-3.11 new df40153 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: .circleci/config-2_1.yml | 4 +-- .circleci/config.yml | 62 ++-- .circleci/config.yml.HIGHRES | 62 ++-- .circleci/config.yml.LOWRES | 62 ++-- .circleci/config.yml.MIDRES | 62 ++-- 5 files changed, 126 insertions(+), 126 deletions(-) - 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 (a7f50c9 -> 3f11261)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from a7f50c9 Fix HintsWriteThenReadTest and LongStreamingTest new 466c65a Update to latest docker image for CircleCI new de85f43 Merge branch 'cassandra-2.2' into cassandra-3.0 new 3f11261 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: .circleci/config-2_1.yml | 8 .circleci/config.yml | 40 .circleci/config.yml.HIGHRES | 40 .circleci/config.yml.LOWRES | 40 4 files changed, 64 insertions(+), 64 deletions(-) - 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.
samt pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit de85f43ddadcf29aefd27b86bcbc0f47b2664aa8
Merge: 2d0b168 466c65a
Author: Sam Tunnicliffe
AuthorDate: Tue Dec 1 18:53:12 2020 +
Merge branch 'cassandra-2.2' into cassandra-3.0
.circleci/config-2_1.yml | 8
.circleci/config.yml | 38 +++---
.circleci/config.yml.HIGHRES | 38 +++---
.circleci/config.yml.LOWRES | 38 +++---
4 files changed, 61 insertions(+), 61 deletions(-)
diff --cc .circleci/config.yml
index b8aa6ea,862d4a1..dda7046
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@@ -1,100 -1,8 +1,100 @@@
version: 2
jobs:
+ j8_jvm_upgrade_dtests:
+docker:
- - image: spod/cassandra-testing-ubuntu1810-java11-w-dependencies:20190306
++- image:
beobal/cassandra-testing-ubuntu1810-java11-w-dependencies:20201130
+resource_class: medium
+working_directory: ~/
+shell: /bin/bash -eo pipefail -l
+parallelism: 1
+steps:
+- attach_workspace:
+at: /home/cassandra
+- run:
+name: Determine distributed Tests to Run
+command: |
+ # reminder: this code (along with all the steps) is independently
executed on every circle container
+ # so the goal here is to get the circleci script to return the
tests *this* container will run
+ # which we do via the `circleci` cli tool.
+
+ rm -fr ~/cassandra-dtest/upgrade_tests
+ echo "***java tests***"
+
+ # get all of our unit test filenames
+ set -eo pipefail && circleci tests glob
"$HOME/cassandra/test/distributed/**/*.java" > /tmp/all_java_unit_tests.txt
+
+ # split up the unit tests into groups based on the number of
containers we have
+ set -eo pipefail && circleci tests split --split-by=timings
--timings-type=filename --index=${CIRCLE_NODE_INDEX}
--total=${CIRCLE_NODE_TOTAL} /tmp/all_java_unit_tests.txt >
/tmp/java_tests_${CIRCLE_NODE_INDEX}.txt
+ set -eo pipefail && cat /tmp/java_tests_${CIRCLE_NODE_INDEX}.txt |
sed "s;^/home/cassandra/cassandra/test/distributed/;;g" | grep "Test\.java$" |
grep upgrade > /tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
+ echo "** /tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt"
+ cat /tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
+no_output_timeout: 15m
+- run:
+name: Log Environment Information
+command: |
+ echo '*** id ***'
+ id
+ echo '*** cat /proc/cpuinfo ***'
+ cat /proc/cpuinfo
+ echo '*** free -m ***'
+ free -m
+ echo '*** df -m ***'
+ df -m
+ echo '*** ifconfig -a ***'
+ ifconfig -a
+ echo '*** uname -a ***'
+ uname -a
+ echo '*** mount ***'
+ mount
+ echo '*** env ***'
+ env
+ echo '*** java ***'
+ which java
+ java -version
+- run:
+name: Run Unit Tests (testclasslist)
+command: |
+ set -x
+ export PATH=$JAVA_HOME/bin:$PATH
+ time mv ~/cassandra /tmp
+ cd /tmp/cassandra
+ if [ -d ~/dtest_jars ]; then
+cp ~/dtest_jars/dtest* /tmp/cassandra/build/
+ fi
+ test_timeout=$(grep 'name="test.distributed.timeout"' build.xml |
awk -F'"' '{print $4}' || true)
+ if [ -z "$test_timeout" ]; then
+test_timeout=$(grep 'name="test.timeout"' build.xml | awk -F'"'
'{print $4}')
+ fi
+ ant testclasslist -Dtest.timeout="$test_timeout"
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=distributed
+no_output_timeout: 15m
+- store_test_results:
+path: /tmp/cassandra/build/test/output/
+- store_artifacts:
+path: /tmp/cassandra/build/test/output
+destination: junitxml
+- store_artifacts:
+path: /tmp/cassandra/build/test/logs
+destination: logs
+environment:
+- JAVA8_HOME: /usr/lib/jvm/java-8-openjdk-amd64
+- ANT_HOME: /usr/share/ant
+- LANG: en_US.UTF-8
+- KEEP_TEST_DIR: true
+- DEFAULT_DIR: /home/cassandra/cassandra-dtest
+- PYTHONIOENCODING: utf-8
+- PYTHONUNBUFFERED: true
+- CASS_DRIVER_NO_EXTENSIONS: true
+- CASS_DRIVER_NO_CYTHON: true
+- CASSANDRA_SKIP_SYNC: true
+- DTEST_REPO: git://github.com/apache/cassandra-dtest.git
+- DTEST_BRANCH: trunk
+- CCM_MAX_HEAP_SIZE: 1024M
+- CCM_HEAP_NEWSIZE: 256M
+- JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64
+- JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64
build:
docker:
- - image:
[cassandra] branch cassandra-3.0 updated (2d0b168 -> de85f43)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 2d0b168 Fix serial read/non-applying CAS linearizability new 466c65a Update to latest docker image for CircleCI new de85f43 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: .circleci/config-2_1.yml | 8 .circleci/config.yml | 38 +++--- .circleci/config.yml.HIGHRES | 38 +++--- .circleci/config.yml.LOWRES | 38 +++--- 4 files changed, 61 insertions(+), 61 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16217) Minimal 4.0 COMPACT STORAGE backport
[ https://issues.apache.org/jira/browse/CASSANDRA-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241783#comment-17241783 ] Ekaterina Dimitrova commented on CASSANDRA-16217: - Hey [~ifesdjeen], I am sorry, I am not a committer but removing those three tests makes sense as they were testing inability to start after upgrade to 4.0 without removing the COMPACT STORAGE and the downgrade after unsuccessful upgrade. > Minimal 4.0 COMPACT STORAGE backport > > > Key: CASSANDRA-16217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16217 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-beta4 > > Time Spent: 20m > Remaining Estimate: 0h > > There are several behavioural changes related to compact storage, and these > differences are larger than most of us have anticipated: we first thought > there’ll be that “appearing column”, but there’s implicit nulls in > clusterings thing, and row vs column deletion. > Some of the recent issues on the subject are: CASSANDRA-16048, which allows > to ignore these differences. The other one was trying to improve user > experience of anyone still using compact storage: CASSANDRA-15811. > Easily reproducible differernces are: > (1) hidden columns show up, which breaks SELECT * queries > (2) DELETE v and UPDATE v WITH TTL would result into row removals in > non-dense compact tables (CASSANDRA-16069) > (3) INSERT allows skipping clusterings, which are filled with nulls by > default. > Some of these are tricky to support, as 15811 has shown. Anyone on OSS side > who might want to upgrade to 4.0 while still using compact storage might be > affected by being forced into one of these behaviours. > Possible solutions are to document these behaviours, or to bring back a > minimal set of COMPACT STORAGE to keep supporting these. > It looks like it is possible to leave some of the functionality related to > DENSE flag and allow it to be present in 4.0, but only for these three (and > potential related, however not direrclty visible) cases. > [~e.dimitrova] since you were working on removal on compact storage, wanted > to reassure that this is not a revert of your patch. On contrary: your patch > was instrumental in identifying the right places. > cc [~slebresne] [~aleksey] [~benedict] [~marcuse] > |[patch|https://github.com/apache/cassandra/pull/785]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=13994-followup]| -- This message was sent by Atlassian Jira (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-16213) Cannot replace_address /X because it doesn't exist in gossip
[
https://issues.apache.org/jira/browse/CASSANDRA-16213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241760#comment-17241760
]
David Capwell commented on CASSANDRA-16213:
---
booo... rebased and now getting
{code}
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "node2_COMMIT-LOG-WRITER"
{code}
Looks like CASSANDRA-16212 isn't fixed yet so will need to disable metaspace
cleaning when running the test (CI does this but not IntelliJ)
> Cannot replace_address /X because it doesn't exist in gossip
>
>
> Key: CASSANDRA-16213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16213
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Cluster/Membership
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> We see this exception around nodes crashing and trying to do a host
> replacement; this error appears to be correlated around multiple node
> failures.
> A simplified case to trigger this is the following
> *) Have a N node cluster
> *) Shutdown all N nodes
> *) Bring up N-1 nodes (at least 1 seed, else replace seed)
> *) Host replace the N-1th node -> this will fail with the above
> The reason this happens is that the N-1th node isn’t gossiping anymore, and
> the existing nodes do not have its details in gossip (but have the details in
> the peers table), so the host replacement fails as the node isn’t known in
> gossip.
> This affects all versions (tested 3.0 and trunk, assume 2.2 as well)
--
This message was sent by Atlassian Jira
(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=17241734#comment-17241734
]
Caleb Rackliffe commented on CASSANDRA-15997:
-
Thanks [~mck]!
> 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: Brandon Williams
>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] [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
]
Adam Holmberg updated CASSANDRA-16143:
--
Reviewers: Adam Holmberg
I'm taking a look today as a non-committer reviewer. Meanwhile leaving in
"Ready for Review" to invite other reviewers.
> 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: Yifan Cai
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
>
[jira] [Commented] (CASSANDRA-16275) Update python driver used by cassandra-dtest
[
https://issues.apache.org/jira/browse/CASSANDRA-16275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241731#comment-17241731
]
Michael Semb Wever commented on CASSANDRA-16275:
+1 from me on all patches.
> Update python driver used by cassandra-dtest
>
>
> Key: CASSANDRA-16275
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16275
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: NA
>
>
> In order to commit CASSANDRA-15299, the python driver used by the dtests
> needs to include PYTHON-1258, support for V5 framing.
> Updating the python driver's cassandra-test branch to latest trunk causes 1
> additional dtest failure in
> {{auth_test.py::TestAuth::test_handle_corrupt_role_data}} because the
> {{ServerError}} response is now subject to the configured {{retry_policy}}.
> This means the error ultimately returned from the driver is
> {{NoHostAvailable}}, rather than {{ServerError}}.
> I'll open a dtest pr to change the expectation in the test and we can commit
> that when the cassandra-test branch is updated.
> cc [~aholmber] [~aboudreault]
--
This message was sent by Atlassian Jira
(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-16275) Update python driver used by cassandra-dtest
[
https://issues.apache.org/jira/browse/CASSANDRA-16275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241719#comment-17241719
]
Sam Tunnicliffe commented on CASSANDRA-16275:
-
Changes to cassandra-builds are pretty minimal:
[16275|https://github.com/beobal/cassandra-builds/tree/16275]
> Update python driver used by cassandra-dtest
>
>
> Key: CASSANDRA-16275
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16275
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: NA
>
>
> In order to commit CASSANDRA-15299, the python driver used by the dtests
> needs to include PYTHON-1258, support for V5 framing.
> Updating the python driver's cassandra-test branch to latest trunk causes 1
> additional dtest failure in
> {{auth_test.py::TestAuth::test_handle_corrupt_role_data}} because the
> {{ServerError}} response is now subject to the configured {{retry_policy}}.
> This means the error ultimately returned from the driver is
> {{NoHostAvailable}}, rather than {{ServerError}}.
> I'll open a dtest pr to change the expectation in the test and we can commit
> that when the cassandra-test branch is updated.
> cc [~aholmber] [~aboudreault]
--
This message was sent by Atlassian Jira
(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-16305) Remove duplicate code used by CQLTester and SchemaLoader
[
https://issues.apache.org/jira/browse/CASSANDRA-16305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16305:
---
Status: Ready to Commit (was: Review In Progress)
> Remove duplicate code used by CQLTester and SchemaLoader
>
>
> Key: CASSANDRA-16305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16305
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> While digging into the cause behind CASSANDRA-16302, we discovered that there
> is some duplicate code in {{SchemaLoader}} and {{CQLTester}}. Over time that
> code has evolved slightly differently in both classes leading to some
> different behavior.
> Having the same code being used by both class will ensure that if the code
> needs to be change the behavior will be correct same one for both classes.
--
This message was sent by Atlassian Jira
(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-16305) Remove duplicate code used by CQLTester and SchemaLoader
[
https://issues.apache.org/jira/browse/CASSANDRA-16305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16305:
---
Status: Review In Progress (was: Patch Available)
> Remove duplicate code used by CQLTester and SchemaLoader
>
>
> Key: CASSANDRA-16305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16305
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> While digging into the cause behind CASSANDRA-16302, we discovered that there
> is some duplicate code in {{SchemaLoader}} and {{CQLTester}}. Over time that
> code has evolved slightly differently in both classes leading to some
> different behavior.
> Having the same code being used by both class will ensure that if the code
> needs to be change the behavior will be correct same one for both classes.
--
This message was sent by Atlassian Jira
(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-16240) Having issues creating a table with name profiles
[ https://issues.apache.org/jira/browse/CASSANDRA-16240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241638#comment-17241638 ] Adam Holmberg commented on CASSANDRA-16240: --- Then I remain mildly confused. I still don't see much cause for concern, though. Would it be alright with you if we resolve this, and create a ticket for the Python driver? > Having issues creating a table with name profiles > - > > Key: CASSANDRA-16240 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16240 > Project: Cassandra > Issue Type: Bug >Reporter: Anuj Kulkarni >Priority: Normal > Attachments: image-2020-11-02-12-13-16-999.png > > > Whenever I try to create a table with name profiles, it always gets created > with additional quotes surrounding it. Attaching the screenshot. > I am on Cassandra 3.7 > I tried creating the table in another keyspace. I also tried creating new > virtual machines with the same AMI and same Cassandra version, but to no > avail. > If I try to create a table with any other name, there are no issues at all. > It's just with the name profiles. > I am on Ubuntu 18.04 by the way. > !image-2020-11-02-12-13-16-999.png! -- This message was sent by Atlassian Jira (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-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yang updated CASSANDRA-16259:
--
Reviewers: Berenguer Blasi, Zhao Yang (was: Berenguer Blasi)
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-beta
>
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:276)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
>
[jira] [Commented] (CASSANDRA-16275) Update python driver used by cassandra-dtest
[
https://issues.apache.org/jira/browse/CASSANDRA-16275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241564#comment-17241564
]
Sam Tunnicliffe commented on CASSANDRA-16275:
-
||Branch||CircleCI Workflow||Cassandra-devbranch||
|[16275-2.2|https://github.com/beobal/cassandra/tree/16275-2.2]|[link|https://app.circleci.com/pipelines/github/beobal/cassandra/181/workflows/c9f34cff-3e5a-487b-b05b-0e54fd269728]|[link|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/233/]|
|[16275-3.0|https://github.com/beobal/cassandra/tree/16275-3.0]|[link|https://app.circleci.com/pipelines/github/beobal/cassandra/179/workflows/00ea860c-0fdf-43df-a893-e15b66d4b7bc]|[link|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/232/]|
|[16275-3.11|https://github.com/beobal/cassandra/tree/16275-3.11]|[link|https://app.circleci.com/pipelines/github/beobal/cassandra/178/workflows/5e04eac5-5334-4659-879c-be208f48bfe5]|[link|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/231/]|
|[16275-trunk|https://github.com/beobal/cassandra/tree/16275-trunk]|[link|https://app.circleci.com/pipelines/github/beobal/cassandra/172/workflows/f03d166f-950d-4d06-8297-65ee2083fdfe]|[link|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/229]|
> Update python driver used by cassandra-dtest
>
>
> Key: CASSANDRA-16275
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16275
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: NA
>
>
> In order to commit CASSANDRA-15299, the python driver used by the dtests
> needs to include PYTHON-1258, support for V5 framing.
> Updating the python driver's cassandra-test branch to latest trunk causes 1
> additional dtest failure in
> {{auth_test.py::TestAuth::test_handle_corrupt_role_data}} because the
> {{ServerError}} response is now subject to the configured {{retry_policy}}.
> This means the error ultimately returned from the driver is
> {{NoHostAvailable}}, rather than {{ServerError}}.
> I'll open a dtest pr to change the expectation in the test and we can commit
> that when the cassandra-test branch is updated.
> cc [~aholmber] [~aboudreault]
--
This message was sent by Atlassian Jira
(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-16307) GROUP BY queries with paging can return deleted data
[
https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16307:
--
Reviewers: Andres de la Peña
> GROUP BY queries with paging can return deleted data
>
>
> Key: CASSANDRA-16307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16307
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Andres de la Peña
>Assignee: Benjamin Lerer
>Priority: Normal
>
> {{GROUP BY}} queries using paging and CL>ONE/LOCAL_ONE. This dtest reproduces
> the problem:
> {code:java}
> try (Cluster cluster = init(Cluster.create(2)))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (pk int, ck int,
> PRIMARY KEY (pk, ck))"));
> ICoordinator coordinator = cluster.coordinator(1);
> coordinator.execute(withKeyspace("INSERT INTO %s.t (pk, ck) VALUES (0,
> 0)"), ConsistencyLevel.ALL);
> coordinator.execute(withKeyspace("INSERT INTO %s.t (pk, ck) VALUES (1,
> 1)"), ConsistencyLevel.ALL);
>
> cluster.get(1).executeInternal(withKeyspace("DELETE FROM %s.t WHERE pk=0
> AND ck=0"));
> cluster.get(2).executeInternal(withKeyspace("DELETE FROM %s.t WHERE pk=1
> AND ck=1"));
> String query = withKeyspace("SELECT * FROM %s.t GROUP BY pk");
> Iterator rows = coordinator.executeWithPaging(query,
> ConsistencyLevel.ALL, 1);
> assertRows(Iterators.toArray(rows, Object[].class));
> }
> {code}
> Using a 2-node cluster and RF=2, the test inserts two partitions in both
> nodes. Then it locally deletes each row in a separate node, so each node sees
> a different partition alive, but reconciliation should produce no alive
> partitions. However, a {{GROUP BY}} query using a page size of 1 wrongly
> returns one of the rows.
> This has been detected during CASSANDRA-16180, and it is probably related to
> CASSANDRA-15459, which solved a similar problem for group-by queries with
> limit, instead of paging.
--
This message was sent by Atlassian Jira
(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-16307) GROUP BY queries with paging can return deleted data
[
https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-16307:
--
Assignee: Benjamin Lerer
> GROUP BY queries with paging can return deleted data
>
>
> Key: CASSANDRA-16307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16307
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Andres de la Peña
>Assignee: Benjamin Lerer
>Priority: Normal
>
> {{GROUP BY}} queries using paging and CL>ONE/LOCAL_ONE. This dtest reproduces
> the problem:
> {code:java}
> try (Cluster cluster = init(Cluster.create(2)))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (pk int, ck int,
> PRIMARY KEY (pk, ck))"));
> ICoordinator coordinator = cluster.coordinator(1);
> coordinator.execute(withKeyspace("INSERT INTO %s.t (pk, ck) VALUES (0,
> 0)"), ConsistencyLevel.ALL);
> coordinator.execute(withKeyspace("INSERT INTO %s.t (pk, ck) VALUES (1,
> 1)"), ConsistencyLevel.ALL);
>
> cluster.get(1).executeInternal(withKeyspace("DELETE FROM %s.t WHERE pk=0
> AND ck=0"));
> cluster.get(2).executeInternal(withKeyspace("DELETE FROM %s.t WHERE pk=1
> AND ck=1"));
> String query = withKeyspace("SELECT * FROM %s.t GROUP BY pk");
> Iterator rows = coordinator.executeWithPaging(query,
> ConsistencyLevel.ALL, 1);
> assertRows(Iterators.toArray(rows, Object[].class));
> }
> {code}
> Using a 2-node cluster and RF=2, the test inserts two partitions in both
> nodes. Then it locally deletes each row in a separate node, so each node sees
> a different partition alive, but reconciliation should produce no alive
> partitions. However, a {{GROUP BY}} query using a page size of 1 wrongly
> returns one of the rows.
> This has been detected during CASSANDRA-16180, and it is probably related to
> CASSANDRA-15459, which solved a similar problem for group-by queries with
> limit, instead of paging.
--
This message was sent by Atlassian Jira
(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-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241468#comment-17241468 ] Andres de la Peña commented on CASSANDRA-16171: --- [~yukim] Great, would you have time to merge it, or would you prefer I do it? > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.html -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16171: -- Status: Review In Progress (was: Patch Available) > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.html -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16171: -- Status: Ready to Commit (was: Review In Progress) > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.html -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16274) Improve performance when calculating StreamTasks with optimised streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-16274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16274: Source Control Link: https://github.com/apache/cassandra/commit/22abff779df097e0ef38180442e9c680b3d41187 Resolution: Fixed Status: Resolved (was: Ready to Commit) and committed, thanks! > Improve performance when calculating StreamTasks with optimised streaming > - > > Key: CASSANDRA-16274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16274 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta4 > > > The way stream tasks are calculated currently is quite inefficient, improve > that. > Also, we currently try to distribute the streaming nodes evenly, this creates > many more sstables than necessary - instead we should try to stream > everything from a single peer, this should reduce the number of sstables > created on the out-of-sync node. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Optimised repair streaming improvements
This is an automated email from the ASF dual-hosted git repository.
marcuse 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 22abff7 Optimised repair streaming improvements
22abff7 is described below
commit 22abff779df097e0ef38180442e9c680b3d41187
Author: Marcus Eriksson
AuthorDate: Fri Nov 13 09:47:38 2020 +0100
Optimised repair streaming improvements
Patch by marcuse; reviewed by Sam Tunnicliffe for CASSANDRA-16274
---
CHANGES.txt| 1 +
src/java/org/apache/cassandra/config/Config.java | 5 +
.../cassandra/config/DatabaseDescriptor.java | 38 +++
src/java/org/apache/cassandra/net/Verb.java| 2 -
.../cassandra/repair/AsymmetricRemoteSyncTask.java | 12 +-
.../org/apache/cassandra/repair/RepairJob.java | 3 +-
.../cassandra/repair/RepairMessageVerbHandler.java | 17 +-
.../cassandra/repair/StreamingRepairTask.java | 2 +-
.../cassandra/repair/SymmetricRemoteSyncTask.java | 2 +-
.../repair/asymmetric/HostDifferences.java | 45 +++-
.../asymmetric/IncomingRepairStreamTracker.java| 6 +-
.../repair/asymmetric/RangeDenormalizer.java | 74 +++---
.../cassandra/repair/asymmetric/RangeMap.java | 269 +
.../cassandra/repair/asymmetric/ReduceHelper.java | 67 ++---
.../repair/messages/AsymmetricSyncRequest.java | 133 --
.../cassandra/repair/messages/RepairOption.java| 19 +-
.../cassandra/repair/messages/SyncRequest.java | 19 +-
.../apache/cassandra/service/StorageService.java | 30 +++
.../cassandra/service/StorageServiceMBean.java | 8 +
.../data/serialization/4.0/service.SyncRequest.bin | Bin 110 -> 111 bytes
.../test/OptimiseStreamsRepairTest.java| 195 +++
.../org/apache/cassandra/repair/RepairJobTest.java | 55 +++--
.../cassandra/repair/StreamingRepairTaskTest.java | 4 +-
.../repair/asymmetric/RangeDenormalizerTest.java | 8 +-
.../cassandra/repair/asymmetric/RangeMapTest.java | 106
.../repair/asymmetric/ReduceHelperTest.java| 44 +++-
.../messages/RepairMessageSerializationsTest.java | 2 +-
.../cassandra/service/SerializationsTest.java | 3 +-
28 files changed, 872 insertions(+), 297 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 56843d7..8e19522 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-beta4
+ * Optimised repair streaming improvements (CASSANDRA-16274)
* Update jctools dependency to 3.1.0 (CASSANDRA-16255)
* 'SSLEngine closed already' exception on failed outbound connection
(CASSANDRA-16277)
* Drain and/or shutdown might throw because of slow messaging service
shutdown (CASSANDRA-16276)
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index 464f8ad..fbc7f98 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -533,6 +533,11 @@ public class Config
public boolean autocompaction_on_startup_enabled =
Boolean.parseBoolean(System.getProperty("cassandra.autocompaction_on_startup_enabled",
"true"));
+// see CASSANDRA-3200 / CASSANDRA-16274
+public volatile boolean auto_optimise_inc_repair_streams = false;
+public volatile boolean auto_optimise_full_repair_streams = false;
+public volatile boolean auto_optimise_preview_repair_streams = false;
+
/**
* Client mode means that the process is a pure client, that uses C* code
base but does
* not read or write local C* database files.
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 30a30e5..d559d63 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -3222,4 +3222,42 @@ public class DatabaseDescriptor
{
return conf.autocompaction_on_startup_enabled;
}
+
+public static boolean autoOptimiseIncRepairStreams()
+{
+return conf.auto_optimise_inc_repair_streams;
+}
+
+public static void setAutoOptimiseIncRepairStreams(boolean enabled)
+{
+if (enabled != conf.auto_optimise_inc_repair_streams)
+logger.info("Changing auto_optimise_inc_repair_streams from {} to
{}", conf.auto_optimise_inc_repair_streams, enabled);
+conf.auto_optimise_inc_repair_streams = enabled;
+}
+
+public static boolean autoOptimiseFullRepairStreams()
+{
+return conf.auto_optimise_full_repair_streams;
+}
+
+public static void setAutoOptimiseFullRepairStreams(boolean enabled)
+{
+if (enabled != conf.auto_optimise_full_repair_streams)
+logger.info("Changing auto_optimise_full_repair_streams from {} to
{}",
[jira] [Commented] (CASSANDRA-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241448#comment-17241448 ] Yuki Morishita commented on CASSANDRA-16171: [~Bereng] Sure, I'm fine with this gets merged. Thanks! > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.html -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16301) upgrade from C* 3.11.9 to 4.0-beta3 fails if 3.11.9 is configured with OldNetworkTopologyStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-16301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16301:
---
Complexity: Low Hanging Fruit
> upgrade from C* 3.11.9 to 4.0-beta3 fails if 3.11.9 is configured with
> OldNetworkTopologyStrategy
> -
>
> Key: CASSANDRA-16301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16301
> Project: Cassandra
> Issue Type: Bug
>Reporter: Yongle Zhang
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-beta4
>
>
> When we upgrade Cassandra from 3.11.9 to 4.0-beta3, if the old cluster
> (3.11.9) is configured with OldNetworkTopologyStrategy, 4.0-beta3 Cassandra
> fails to start with the following exception:
>
> {code:java}
> ERROR [main] 2020-11-24 22:49:33,423 CassandraDaemon.java:278 - Error while
> loading schema:
> org.apache.cassandra.exceptions.ConfigurationException: Unable to find
> replication strategy class
> 'org.apache.cassandra.locator.OldNetworkTopologyStrategy'
> at
> org.apache.cassandra.utils.FBUtilities.classForName(FBUtilities.java:720)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getClass(AbstractReplicationStrategy.java:422)
> at
> org.apache.cassandra.schema.ReplicationParams.fromMapWithDefaults(ReplicationParams.java:90)
> at
> org.apache.cassandra.schema.ReplicationParams.fromMap(ReplicationParams.java:82)
> at
> org.apache.cassandra.schema.KeyspaceParams.create(KeyspaceParams.java:64)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspaceParams(SchemaKeyspace.java:971)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:956)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:949)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:859)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:100)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:89)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:274)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.cassandra.locator.OldNetworkTopologyStrategy
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at
> org.apache.cassandra.utils.FBUtilities.classForName(FBUtilities.java:716)
> ... 13 common frames omitted
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Unable to find replication strategy class
> 'org.apache.cassandra.locator.OldNetworkTopologyStrategy'{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-12126) CAS Reads Inconsistencies
[ https://issues.apache.org/jira/browse/CASSANDRA-12126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241347#comment-17241347 ] Benjamin Lerer commented on CASSANDRA-12126: [~feeblefakie] C can be unreachable for different reasons. > CAS Reads Inconsistencies > -- > > Key: CASSANDRA-12126 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12126 > Project: Cassandra > Issue Type: Bug > Components: Feature/Lightweight Transactions, Legacy/Coordination >Reporter: Sankalp Kohli >Assignee: Sylvain Lebresne >Priority: Normal > Labels: LWT, pull-request-available > Fix For: 4.0-beta4, 3.0.24, 3.11.10 > > Time Spent: 10m > Remaining Estimate: 0h > > While looking at the CAS code in Cassandra, I found a potential issue with > CAS Reads. Here is how it can happen with RF=3 > 1) You issue a CAS Write and it fails in the propose phase. A machine replies > true to a propose and saves the commit in accepted filed. The other two > machines B and C does not get to the accept phase. > Current state is that machine A has this commit in paxos table as accepted > but not committed and B and C does not. > 2) Issue a CAS Read and it goes to only B and C. You wont be able to read the > value written in step 1. This step is as if nothing is inflight. > 3) Issue another CAS Read and it goes to A and B. Now we will discover that > there is something inflight from A and will propose and commit it with the > current ballot. Now we can read the value written in step 1 as part of this > CAS read. > If we skip step 3 and instead run step 4, we will never learn about value > written in step 1. > 4. Issue a CAS Write and it involves only B and C. This will succeed and > commit a different value than step 1. Step 1 value will never be seen again > and was never seen before. > If you read the Lamport “paxos made simple” paper and read section 2.3. It > talks about this issue which is how learners can find out if majority of the > acceptors have accepted the proposal. > In step 3, it is correct that we propose the value again since we dont know > if it was accepted by majority of acceptors. When we ask majority of > acceptors, and more than one acceptors but not majority has something in > flight, we have no way of knowing if it is accepted by majority of acceptors. > So this behavior is correct. > However we need to fix step 2, since it caused reads to not be linearizable > with respect to writes and other reads. In this case, we know that majority > of acceptors have no inflight commit which means we have majority that > nothing was accepted by majority. I think we should run a propose step here > with empty commit and that will cause write written in step 1 to not be > visible ever after. > With this fix, we will either see data written in step 1 on next serial read > or will never see it which is what we want. -- This message was sent by Atlassian Jira (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-16217) Minimal 4.0 COMPACT STORAGE backport
[ https://issues.apache.org/jira/browse/CASSANDRA-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241335#comment-17241335 ] Alex Petrov commented on CASSANDRA-16217: - Follow-up is committed as [caeecf6456b87886a79f47a2954788e6c856697c|https://github.com/apache/cassandra/commit/caeecf6456b87886a79f47a2954788e6c856697c] and [79ea1e373614c21fd1aa294fb52d693767b91819|https://github.com/apache/cassandra/commit/79ea1e373614c21fd1aa294fb52d693767b91819]. I was waiting for to merge https://github.com/apache/cassandra-dtest/pull/104 to close this ticket, [~e.dimitrova] would you be able to take a look at it? > Minimal 4.0 COMPACT STORAGE backport > > > Key: CASSANDRA-16217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16217 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-beta4 > > Time Spent: 20m > Remaining Estimate: 0h > > There are several behavioural changes related to compact storage, and these > differences are larger than most of us have anticipated: we first thought > there’ll be that “appearing column”, but there’s implicit nulls in > clusterings thing, and row vs column deletion. > Some of the recent issues on the subject are: CASSANDRA-16048, which allows > to ignore these differences. The other one was trying to improve user > experience of anyone still using compact storage: CASSANDRA-15811. > Easily reproducible differernces are: > (1) hidden columns show up, which breaks SELECT * queries > (2) DELETE v and UPDATE v WITH TTL would result into row removals in > non-dense compact tables (CASSANDRA-16069) > (3) INSERT allows skipping clusterings, which are filled with nulls by > default. > Some of these are tricky to support, as 15811 has shown. Anyone on OSS side > who might want to upgrade to 4.0 while still using compact storage might be > affected by being forced into one of these behaviours. > Possible solutions are to document these behaviours, or to bring back a > minimal set of COMPACT STORAGE to keep supporting these. > It looks like it is possible to leave some of the functionality related to > DENSE flag and allow it to be present in 4.0, but only for these three (and > potential related, however not direrclty visible) cases. > [~e.dimitrova] since you were working on removal on compact storage, wanted > to reassure that this is not a revert of your patch. On contrary: your patch > was instrumental in identifying the right places. > cc [~slebresne] [~aleksey] [~benedict] [~marcuse] > |[patch|https://github.com/apache/cassandra/pull/785]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=13994-followup]| -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
