[jira] [Commented] (CASSANDRA-16200) Nodetool ring unit testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243738#comment-17243738 ] Berenguer Blasi commented on CASSANDRA-16200: - Hi [~dcapwell], bq. made the change to no longer touch stdout in nodetool, what are the cases you see touching stdout? This looks more like a bug, so shouldn't try to work around it Sorry not following, can you eli5 please? changes to not touch stdout? What bug? I only added a unit test to test that nodetool command. bq. Also saw that we added the following to src/java/org/apache/cassandra/tools/nodetool/Ring.java Iirc there was either a NPE or some other sort of obvious failure when running the command bc IPs where reaching us here with a '/'. I chased down the code deep and we seem to have code sometimes render them with the '/' and sometimes without it. That gets pushed into data structures across the code where lookups have to match the '/' presence or absence. Here we had to remove the '/' for the lookup to work. It's should be easy to repro by removing that line and running the test. I don't think that affects output as that IP is not printed, just used for a lookup for tokens as per the code. I guess that didn't get picked up by Jon bc the test didn't exist back then? > Nodetool ring unit testing > -- > > Key: CASSANDRA-16200 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16200 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta3 > > Time Spent: 1h > Remaining Estimate: 0h > > Add nodetool ring testing -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [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=17243689#comment-17243689
]
Caleb Rackliffe commented on CASSANDRA-16097:
-
Once the test I've proposed is integrated and we resolve the points
[here|https://github.com/aholmberg/cassandra/pull/17#discussion_r533756487] and
[here|https://github.com/aholmberg/cassandra/pull/17#discussion_r533782186],
I'll be a +1 as well.
> DigestResolver.getData throws AssertionError since dataResponse is null
> ---
>
> Key: CASSANDRA-16097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16097
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Was running a benchmark at LOCAL_ONE and eventually saw the below exception
> {code}
> 2020-09-02 21:08:59,872 ERROR [Native-Transport-Requests-35]
> org.apache.cassandra.transport.Message - Unexpected exception during request;
> channel = [id: 0x13bb89d4, L:/10.14.92.74:9042 - R:/10.14.89.248:47112]
> java.lang.AssertionError
>at
> org.apache.cassandra.service.reads.DigestResolver.getData(DigestResolver.java:77)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:390)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1821)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1711)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1628)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1097)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:294)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:246)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:498)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:476)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
>at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {code}
> This exception was not frequent, out of the whole run (3h) only saw this
> twice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16159) Reduce the Severity of Errors Reported in FailureDetector#isAlive()
[
https://issues.apache.org/jira/browse/CASSANDRA-16159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243618#comment-17243618
]
Jon Meredith commented on CASSANDRA-16159:
--
We've seen this a few more times and I've been investigating the root cause.
The {{isAlive}} failure is followed by
{code}
ERROR 2020-11-20T23:27:53,218 [GossipStage:1]
org.apache.cassandra.service.CassandraDaemon:510 - Exception in thread
Thread[GossipStage:1,5,main]
java.lang.RuntimeException: Node /10.20.30.40:65501 is trying to replace node
/10.20.30.50:65501 with tokens [] with a different set of tokens
[-3074457345618258603].
at
org.apache.cassandra.locator.TokenMetadata.addReplaceTokens(TokenMetadata.java:366)
~[cassandra-4.0.jar:4.0]
at
org.apache.cassandra.service.StorageService.handleStateBootreplacing(StorageService.java:2606)
~[cassandra-4.0.jar:4.0]
at
org.apache.cassandra.service.StorageService.onChange(StorageService.java:2269)
~[cassandra-4.0.jar:4.0]
at
org.apache.cassandra.service.StorageService.onJoin(StorageService.java:3232)
~[cassandra-4.0.jar:4.0]
at
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1268)
~[cassandra-4.0.jar:4.0]
at
org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1395)
~[cassandra-4.0.jar:4.0]
at
org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:50)
~[cassandra-4.0.jar:4.0]
at
org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:77)
~[cassandra-4.0.jar:4.0]
at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:93)
~[cassandra-4.0.jar:4.0]
at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:44)
~[cassandra-4.0.jar:4.0]
at
org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:890)
~[cassandra-4.0.jar:4.0]
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) [?:?]
{code}
At the time multiple nodes are being replaced concurrently and one of the nodes
is included in the seed list for the others.
My current hypothesis is that the replacement for the seed node starts up, goes
through {{prepareForReplacement}} doing a successful shadow gossip round with
an older running node in the cluster so that the check for the replaced address
passes. Then {{prepareToJoin}} starts up the {{Gossiper}} on the empty
replacement, and populates it with just the local state (as it was an empty
replacement node, there was nothing to load from {{SystemKeyspace}}.
The second replacement (which reports the two error messages above) starts up
around the same time as the first node, does it's shadow round too and also
talks to an older running node so that it completes {{prepareForReplacement}}
and starts up gossiper too which happens to pick the other replacement node as
the first seed to gossip to.
The GossipDigestSync/Ack sequence happens, with the replacement seed sending
back the single entry for itself in state BOOTSTRAPPING_REPLACE, which the
non-seed replacement node tries to handle but fails with the exception above
because it can't confirm the tokens.
> Reduce the Severity of Errors Reported in FailureDetector#isAlive()
> ---
>
> Key: CASSANDRA-16159
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16159
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Caleb Rackliffe
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Noticed the following error in the failure detector during a host replacement:
> {noformat}
> java.lang.IllegalArgumentException: Unknown endpoint: 10.38.178.98:7000
> at
> org.apache.cassandra.gms.FailureDetector.isAlive(FailureDetector.java:281)
> at
> org.apache.cassandra.service.StorageService.handleStateBootreplacing(StorageService.java:2502)
> at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:2182)
> at
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:3145)
> at
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1242)
> at
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1368)
> at
>
[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=17243602#comment-17243602
]
Jon Meredith commented on CASSANDRA-16213:
--
Posted a review.
I'm chasing down a second related issue if multiple nodes are starting up with
{{replace_address_first_boot}} at the same time and one of the replacement
nodes is also marked as a seed for the others. Seems to be the root cause of
CASSANDRA-16159 so will handle on that ticket.
> 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] [Assigned] (CASSANDRA-16159) Reduce the Severity of Errors Reported in FailureDetector#isAlive()
[
https://issues.apache.org/jira/browse/CASSANDRA-16159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith reassigned CASSANDRA-16159:
Assignee: Jon Meredith
> Reduce the Severity of Errors Reported in FailureDetector#isAlive()
> ---
>
> Key: CASSANDRA-16159
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16159
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Caleb Rackliffe
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Noticed the following error in the failure detector during a host replacement:
> {noformat}
> java.lang.IllegalArgumentException: Unknown endpoint: 10.38.178.98:7000
> at
> org.apache.cassandra.gms.FailureDetector.isAlive(FailureDetector.java:281)
> at
> org.apache.cassandra.service.StorageService.handleStateBootreplacing(StorageService.java:2502)
> at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:2182)
> at
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:3145)
> at
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1242)
> at
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1368)
> at
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:50)
> at
> org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:77)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:93)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:44)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:884)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> {noformat}
> This particular error looks benign, given that even if it occurs, the node
> continues to handle the {{BOOT_REPLACE}} state. There are two things we might
> be able to do to improve {{FailureDetector#isAlive()}} though:
> 1.) We don’t short circuit in the case that the endpoint in question is in
> quarantine after being removed. It may be useful to check for this so we can
> avoid logging an ERROR when the endpoint is clearly doomed/dead. (Quarantine
> works great when the gossip message is _from_ a quarantined endpoint, but in
> this case, that would be the new/replacing and not the old/replaced one.)
> 2.) We can reduce the severity of the logging from ERROR to WARN and provide
> better context around how to determine whether or not there’s actually a
> problem. (ex. “If this occurs while trying to determine liveness for a node
> that is currently being replaced, it can be safely ignored.”)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16261) Prevent unbounded number of flushing tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-16261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243590#comment-17243590 ] Caleb Rackliffe commented on CASSANDRA-16261: - [~e.dimitrova] [~adelapena] I've wrapped up my first pass at review. Most of my feedback (inline in the PR) is around pretty minor stuff, but there is one thread of discussion I'd like to resolve [here|https://github.com/ekaterinadimitrova2/cassandra/pull/74/files?file-filters%5B%5D=.java%5B%5D=.txt#r535728281]... > Prevent unbounded number of flushing tasks > -- > > Key: CASSANDRA-16261 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16261 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-beta4 > > > The cleaner thread is not prevented from queueing an unbounded number of > flushing tasks for memtables that are almost empty. > This patch adds a mechanism to track the number of pending flushing > tasks in the memtable cleaner. Above the maximum number (2x the flushing > threads by default), only memtables using at least MCT memory will be > flushed, where MCT stands for Memory Cleanup Threshold. > This patch also fixes a possible problem tracking the memory marked as > "reclaiming" in the memtable allocators and pool. Writes that complete > only after a memtable has been scheduled for flushing, did not report > their memory as reclaiming. Normally this should be a small value of no > consequence, but if the flushing tasks are blocked for a long period, > and there is a sufficient number of writes, or these writes use > a sufficiently large quantity of memory, this would cause the memtable > cleaning algorithm to schedule repeated flushing tasks because the used > memory is always > reclaiming memory + MCT. -- This message was sent by Atlassian Jira (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-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:comment-tabpanel=17243587#comment-17243587
]
Yakir Gibraltar commented on CASSANDRA-16296:
-
I just change the following keyspace from RF 3 to 2 on the DC that i tried to
join and it's solved the issue:
{code}
CREATE KEYSPACE ks WITH replication = {'class': 'NetworkTopologyStrategy',
'V4C': '3', 'V4N': '3'} AND durable_writes = true;
{code}
> 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
>Assignee: Benjamin Lerer
>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]
[jira] [Commented] (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:comment-tabpanel=17243571#comment-17243571
]
David Capwell commented on CASSANDRA-16296:
---
Thanks for the details!
> 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
>Assignee: Benjamin Lerer
>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 - Node
> /7.7.7.7:7000 is now part of the cluster
> INFO [GossipStage:1] 2020-11-22 09:26:56,147 Gossiper.java:1206 -
> InetAddress /7.7.7.7:7000 is now UP
> INFO
[jira] [Commented] (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:comment-tabpanel=17243563#comment-17243563
]
Yakir Gibraltar commented on CASSANDRA-16296:
-
Hi [~dcapwell] ,
"have you repeated the process on 3.x line? How did you "join" with the new
node? "
I tried to join few times from different hosts, all join failed, with simple
"systemctl start cassandra"
" Was this upgrading the cluster or creating a new one?"
Fresh cluster of version 4 without any data.
> 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
>Assignee: Benjamin Lerer
>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,
[jira] [Commented] (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:comment-tabpanel=17243560#comment-17243560
]
David Capwell commented on CASSANDRA-16296:
---
have you repeated the process on 3.x line? How did you "join" with the new
node? Was this upgrading the cluster or creating a new one?
> 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
>Assignee: Benjamin Lerer
>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 - Node
> /7.7.7.7:7000 is now part of the cluster
> INFO [GossipStage:1]
[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=17243555#comment-17243555
]
David Capwell commented on CASSANDRA-16097:
---
I am good with Adam's test (once it can pass successfully repeatedly) + Caleb's
test.
> DigestResolver.getData throws AssertionError since dataResponse is null
> ---
>
> Key: CASSANDRA-16097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16097
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Was running a benchmark at LOCAL_ONE and eventually saw the below exception
> {code}
> 2020-09-02 21:08:59,872 ERROR [Native-Transport-Requests-35]
> org.apache.cassandra.transport.Message - Unexpected exception during request;
> channel = [id: 0x13bb89d4, L:/10.14.92.74:9042 - R:/10.14.89.248:47112]
> java.lang.AssertionError
>at
> org.apache.cassandra.service.reads.DigestResolver.getData(DigestResolver.java:77)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:390)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1821)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1711)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1628)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1097)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:294)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:246)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:498)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:476)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> ~[apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
>at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> [apache-cassandra-4.0.0-beta3.jar:4.0.0-beta3]
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.50.Final.jar:4.1.50.Final]
>at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {code}
> This exception was not frequent, out of the whole run (3h) only saw this
> twice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-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=17243552#comment-17243552
]
David Capwell commented on CASSANDRA-16083:
---
bq. I guess you mean the work done in CASSANDRA-15909?
Yeah, that would work. Utilities were added to create alias which map to the
same thing, so just adding the old name should resolve this issue.
bq. a quick check of the code suggests that this is the case
I am ok riding off this as a tooling issue, though I am interested in why 3.0
has it and 4.0 doesn't; wonder what changed? Some stages should be executed as
part of the test, so it might also be better to have a exclude list of stages
known to be flaky with initialization; this would at least make sure the stage
metrics do not regress.
> 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
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=AllMemtablesLiveDataSize
> org.apache.cassandra.metrics:type=Table,keyspace=system,scope=batchlog,name=ViewReadTime
>
[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=17243519#comment-17243519 ] Michael Semb Wever edited comment on CASSANDRA-16079 at 12/3/20, 10:22 PM: --- Now that CASSANDRA-16205 is merged… For just the work in this ticket, here's a run: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/247/pipeline This builds on the following patches: - ccm [mck/16205|https://github.com/riptano/ccm/compare/cassandra-test...thelastpickle:mck/16205] - cassandra-dtest [mck/16079|https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16079] And, for work in this ticket in combination with CASSANDRA-13701, here's a run: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/246/pipeline This builds on the following patches: - cassandra [mck/trunk_13701|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_13701] - ccm [mck/16205|https://github.com/riptano/ccm/compare/cassandra-test...thelastpickle:mck/16205] - cassandra-dtest [mck/16079|https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16079] was (Author: michaelsembwever): Now that CASSANDRA-16205 is merged… For just the work in this ticket, here's a run: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/245/pipeline This builds on the following patches: - ccm [mck/16205|https://github.com/riptano/ccm/compare/cassandra-test...thelastpickle:mck/16205] - cassandra-dtest [mck/16079|https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16079] And, for work in this ticket in combination with CASSANDRA-13701, here's a run: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/246/pipeline This builds on the following patches: - cassandra [mck/trunk_13701|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_13701] - ccm [mck/16205|https://github.com/riptano/ccm/compare/cassandra-test...thelastpickle:mck/16205] - cassandra-dtest [mck/16079|https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16079] > 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-15580) 4.0 quality testing: Repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243538#comment-17243538
]
Vinay Chella commented on CASSANDRA-15580:
--
[Alexander
Dejanovski|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=adejanovski],
the detailed repair test plan that you outlined looks like a great start to
me. I want to share a few techniques and methodologies that we use internally
to validate the repair functionality though many are not in an open source-able
state.
One of the things that are not covered in dtest repair test coverage is the
repair validation with dense nodes, which is often the pain point. We have
built an infrastructure and automation that helps us build large scale clusters
with dense nodes, running NdBench traffic while repairing the cluster with
continuous node restarts and terminations. This tooling and infra certainly
helped us discover a few critical repair issues and tweaks in the past (e.g.,
CASSANDRA-14096). This infra also helps generate the data in one region and
reading, validating in another region while node terminations and hints
dropping are in place. Looking at the approach you are taking, I am glad that
we are marching in a similar direction for 4.0 repair validation, which is a
positive signal.
Regarding mixed version upgrade tests, the similar approach that I outlined
above certainly works to an extent. However, in-jvm upgrade dtests might be
more feasible at this time.
{quote}Which testing framework to use?
I personally like using Gherkin syntax based frameworks such as Cucumber, but
we'd need to get a feel for the community's appetite to introduce such a
framework.
Otherwise we'd probably fallback to JUnit but my take on this is that while
it's really good for unit tests, it's no fit for integration tests.
Any input/opinion on testing framework is appreciated.{color:#172b4d} {color}
{quote}
I see a place where it makes integration tests more readable and easy to
contribute to with something like Gherkin syntax based frameworks, so I don't
see any downside and am optimistic on this unless someone has substantial
concerns.
I am happy to help with the review of these efforts. Please loop me in these
tickets as you make progress.
Thank you for taking this up.
> 4.0 quality testing: Repair
> ---
>
> Key: CASSANDRA-15580
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15580
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Alexander Dejanovski
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Reference [doc from
> NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#]
> for context.
> *Shepherd: Alexander Dejanovski*
> We aim for 4.0 to have the first fully functioning incremental repair
> solution (CASSANDRA-9143)! Furthermore we aim to verify that all types of
> repair: (full range, sub range, incremental) function as expected as well as
> ensuring community tools such as Reaper work. CASSANDRA-3200 adds an
> experimental option to reduce the amount of data streamed during repair, we
> should write more tests and see how it works with big nodes.
--
This message was sent by Atlassian Jira
(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-16277) 'SSLEngine closed already' exception on failed outbound connection
[
https://issues.apache.org/jira/browse/CASSANDRA-16277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243530#comment-17243530
]
Jon Meredith commented on CASSANDRA-16277:
--
[~aleksey] should the
cefe43b06bb1c0dd3bd362638cc56e0fc1f78ddb have also updated the Netty Version
numbers in build.xml?
> 'SSLEngine closed already' exception on failed outbound connection
> --
>
> Key: CASSANDRA-16277
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16277
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 4.0-beta4
>
>
> Occasionally Netty will invoke
> {{OutboundConnectionInitiator#exceptionCaught()}} handler to process an
> exception of the following kind:
> {code}
> io.netty.channel.unix.Errors$NativeIoException: readAddress(..) failed:
> Connection reset by peer
> {code}
> When we invoke {{ctx.close()}} later in that method, the listener, set up in
> {{channelActive()}}, might be
> failed with an {{SSLException("SSLEngine closed already”)}} by Netty, and
> {{exceptionCaught()}} will be invoked
> once again, this time to handle the {{SSLException}} triggered by
> {{ctx.close()}}.
> The exception at this stage is benign, and we shouldn't be double-logging the
> failure to connect.
--
This message was sent by Atlassian Jira
(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-16079) Improve dtest runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-16079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243519#comment-17243519 ] Michael Semb Wever edited comment on CASSANDRA-16079 at 12/3/20, 9:20 PM: -- Now that CASSANDRA-16205 is merged… For just the work in this ticket, here's a run: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/245/pipeline This builds on the following patches: - ccm [mck/16205|https://github.com/riptano/ccm/compare/cassandra-test...thelastpickle:mck/16205] - cassandra-dtest [mck/16079|https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16079] And, for work in this ticket in combination with CASSANDRA-13701, here's a run: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/246/pipeline This builds on the following patches: - cassandra [mck/trunk_13701|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_13701] - ccm [mck/16205|https://github.com/riptano/ccm/compare/cassandra-test...thelastpickle:mck/16205] - cassandra-dtest [mck/16079|https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16079] was (Author: michaelsembwever): Now that CASSANDRA-16205 is merged… For just the work in this ticket, here's a run: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/245/pipeline This builds on the following patches: - 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] And, for work in this ticket in combination with CASSANDRA-13701, here's a run: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/246/pipeline This builds on the following patches: - cassandra [mck/trunk_13701|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_13701] - 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] > 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=17243519#comment-17243519 ] Michael Semb Wever commented on CASSANDRA-16079: Now that CASSANDRA-16205 is merged… For just the work in this ticket, here's a run: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/245/pipeline This builds on the following patches: - 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] And, for work in this ticket in combination with CASSANDRA-13701, here's a run: https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/246/pipeline This builds on the following patches: - cassandra [mck/trunk_13701|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_13701] - 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] > 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] [Updated] (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:all-tabpanel ] Jon Meredith updated CASSANDRA-16213: - Reviewers: Brandon Williams, Jon Meredith, Paulo Motta, Sam Tunnicliffe (was: Brandon Williams, Paulo Motta, Sam Tunnicliffe) > 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=17243453#comment-17243453 ] David Capwell commented on CASSANDRA-16213: --- rebased to trunk, which fixed some of the test failures. ATM the build is clean (minus the streaming test, but that is known) > 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-16200) Nodetool ring unit testing
[
https://issues.apache.org/jira/browse/CASSANDRA-16200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243449#comment-17243449
]
David Capwell commented on CASSANDRA-16200:
---
just saw this, had a few questions
[~Bereng], [~yifanc]made the change to no longer touch stdout in nodetool, what
are the cases you see touching stdout? This looks more like a bug, so
shouldn't try to work around it.
Also saw that we added the following to
src/java/org/apache/cassandra/tools/nodetool/Ring.java
{code}
String addressNPort = stat.endpointWithPort.toString().replaceAll("^/", "");
{code}
Can you explain why? [~jmeredithco] went through and standardized our output
and requested the breaking changes on the dev list, this change moves away from
that, so wondering what the motivation was.
> Nodetool ring unit testing
> --
>
> Key: CASSANDRA-16200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16200
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta3
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Add nodetool ring testing
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15588) 4.0 quality testing: Cluster Upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-15588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243438#comment-17243438 ] David Capwell commented on CASSANDRA-15588: --- I have not started this work but allocated this as my topic focus starting Monday; should start breaking down sub-tasks starting then. > 4.0 quality testing: Cluster Upgrade > > > Key: CASSANDRA-15588 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15588 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python >Reporter: Josh McKenzie >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-beta > > > We've historically had numerous bugs concerning upgrading clusters from one > version to the other. Let's establish the supported upgrade path and ensure > that users can safely perform the upgrades in production. -- This message was sent by Atlassian Jira (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=17243433#comment-17243433
]
David Capwell commented on CASSANDRA-16143:
---
I can pick up review Monday unless enough committers +1 by then.
> 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: 1.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)
> [?:?]
[jira] [Updated] (CASSANDRA-16205) Offline token allocation strategy generator tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16205:
---
Fix Version/s: 4.0-beta4
4.0
Source Control Link:
https://github.com/apache/cassandra/commit/2346ed8241022882e77433e283ab8ce3004d12b0
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[2346ed8241022882e77433e283ab8ce3004d12b0|https://github.com/apache/cassandra/commit/2346ed8241022882e77433e283ab8ce3004d12b0].
Thanks [~paulo], [~e.dimitrova], and [~blambov].
> Offline token allocation strategy generator tool
>
>
> Key: CASSANDRA-16205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16205
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Local/Scripts
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0, 4.0-beta4
>
>
> A command line tool to generate tokens (using the
> allocate_tokens_for_local_replication_factor algorithm) for pre-configuration
> of {{initial_tokens}} in cassandra.yaml.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Offline token allocation strategy generator tool
This is an automated email from the ASF dual-hosted git repository. mck 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 2346ed8 Offline token allocation strategy generator tool 2346ed8 is described below commit 2346ed8241022882e77433e283ab8ce3004d12b0 Author: Mick Semb Wever AuthorDate: Wed Dec 2 09:34:28 2020 +0100 Offline token allocation strategy generator tool Provides the tools/bin/generate-tokens script that can be used to pregenerate allocation strategy tokens. Refactors TokenAllocation for extensibility (and better re-use between strategies), and adds OfflineTokenAllocator. TokenMetadata now has a configurable snitch (instead of hardcoded to DatabaseDescriptor.getEndpointSnitch()) for testability. Adds logging of growth and stddev changes to allocate_tokens_for_local_replication_factor usages. patch by Mick Semb Wever; reviewed by Paul Motta, Ekaterina Dimitrova for CASSANDRA-16205 --- CHANGES.txt| 1 + debian/cassandra-tools.install | 3 +- doc/source/tools/generatetokens.rst| 56 +++ doc/source/tools/index.rst | 1 + redhat/cassandra.spec | 2 + .../dht/tokenallocator/OfflineTokenAllocator.java | 190 +++ .../dht/tokenallocator/TokenAllocation.java| 379 ++--- .../locator/AbstractReplicationStrategy.java | 10 - .../org/apache/cassandra/locator/SimpleSnitch.java | 4 +- .../apache/cassandra/locator/TokenMetadata.java| 33 +- .../org/apache/cassandra/tools/GenerateTokens.java | 157 + .../org/apache/cassandra/utils/OutputHandler.java | 13 +- .../org/apache/cassandra/dht/BootStrapperTest.java | 213 +--- .../tokenallocator/OfflineTokenAllocatorTest.java | 222 .../TokenAllocationTest.java} | 306 +++-- .../apache/cassandra/tools/GenerateTokensTest.java | 56 +++ tools/bin/generatetokens | 54 +++ 17 files changed, 1089 insertions(+), 611 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 172ebcc..52d2526 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0-beta4 + * Add generatetokens script for offline token allocation strategy generation (CASSANDRA-16205) * Remove Windows scripts (CASSANDRA-16171) * Improve checksumming and compression in protocol V5 (CASSANDRA-15299) * Optimised repair streaming improvements (CASSANDRA-16274) diff --git a/debian/cassandra-tools.install b/debian/cassandra-tools.install index 8806344..7cebbef 100644 --- a/debian/cassandra-tools.install +++ b/debian/cassandra-tools.install @@ -1,7 +1,8 @@ +tools/bin/generatetokens usr/bin +tools/bin/sstabledump usr/bin tools/bin/sstableexpiredblockers usr/bin tools/bin/sstablelevelreset usr/bin tools/bin/sstablemetadata usr/bin tools/bin/sstableofflinerelevel usr/bin tools/bin/sstablerepairedset usr/bin tools/bin/sstablesplit usr/bin -tools/bin/sstabledump usr/bin diff --git a/doc/source/tools/generatetokens.rst b/doc/source/tools/generatetokens.rst new file mode 100644 index 000..24448d0 --- /dev/null +++ b/doc/source/tools/generatetokens.rst @@ -0,0 +1,56 @@ +.. Licensed to the Apache Software Foundation (ASF) under one +.. or more contributor license agreements. See the NOTICE file +.. distributed with this work for additional information +.. regarding copyright ownership. The ASF licenses this file +.. to you under the Apache License, Version 2.0 (the +.. "License"); you may not use this file except in compliance +.. with the License. You may obtain a copy of the License at +.. +.. http://www.apache.org/licenses/LICENSE-2.0 +.. +.. Unless required by applicable law or agreed to in writing, software +.. distributed under the License is distributed on an "AS IS" BASIS, +.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +.. See the License for the specific language governing permissions and +.. limitations under the License. + +generatetokens + + +Pre-generates tokens for a datacenter with the given number of nodes using the token allocation algorithm. Useful in edge-cases when generated tokens needs to be known in advance of bootstrapping nodes. In nearly all cases it is best to just let the bootstrapping nodes automatically generate their own tokens. +ref: https://issues.apache.org/jira/browse/CASSANDRA-16205 + + +Usage +^ +generatetokens -n NODES -t TOKENS --rf REPLICATION_FACTOR [--partitioner PARTITIONER] [--racks RACK_NODE_COUNTS] + + +=== +-n,--nodes Number of nodes. +-t,--tokens Number
[jira] [Commented] (CASSANDRA-16300) Cassandra 2.2 doesn't satisfy Java 1.7 language level
[ https://issues.apache.org/jira/browse/CASSANDRA-16300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243401#comment-17243401 ] Ekaterina Dimitrova commented on CASSANDRA-16300: - I know we don't have Java 7 CI infrastructure, but were unit tests run at least locally? > Cassandra 2.2 doesn't satisfy Java 1.7 language level > - > > Key: CASSANDRA-16300 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16300 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 2.2.x > > Time Spent: 10m > Remaining Estimate: 0h > > I think that 2.2 needs to satisfy Java 1.7 language level. However, there are > a few places where newer syntax is used: > * > [MessagingService|https://github.com/apache/cassandra/blob/cassandra-2.2/src/java/org/apache/cassandra/net/MessagingService.java#L779] > * > [ExecutorUtils|https://github.com/apache/cassandra/blob/cassandra-2.2/src/java/org/apache/cassandra/utils/ExecutorUtils.java#L36-L47] > * > [Throwables|https://github.com/apache/cassandra/blob/cassandra-2.2/src/java/org/apache/cassandra/utils/Throwables.java#L36] > * > [YamlConfigurationLoader|https://github.com/apache/cassandra/blob/cassandra-2.2/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L142] > * > [YamlConfigurationLoaderTest|https://github.com/apache/cassandra/blob/cassandra-2.2/test/unit/org/apache/cassandra/config/YamlConfigurationLoaderTest.java#L38] > If I'm right and we really need 1.7 language level we should fix those, which > seems quite straightforward. -- This message was sent by Atlassian Jira (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-16300) Cassandra 2.2 doesn't satisfy Java 1.7 language level
[ https://issues.apache.org/jira/browse/CASSANDRA-16300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16300: Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina Dimitrova) Ekaterina Dimitrova, Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > Cassandra 2.2 doesn't satisfy Java 1.7 language level > - > > Key: CASSANDRA-16300 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16300 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 2.2.x > > Time Spent: 10m > Remaining Estimate: 0h > > I think that 2.2 needs to satisfy Java 1.7 language level. However, there are > a few places where newer syntax is used: > * > [MessagingService|https://github.com/apache/cassandra/blob/cassandra-2.2/src/java/org/apache/cassandra/net/MessagingService.java#L779] > * > [ExecutorUtils|https://github.com/apache/cassandra/blob/cassandra-2.2/src/java/org/apache/cassandra/utils/ExecutorUtils.java#L36-L47] > * > [Throwables|https://github.com/apache/cassandra/blob/cassandra-2.2/src/java/org/apache/cassandra/utils/Throwables.java#L36] > * > [YamlConfigurationLoader|https://github.com/apache/cassandra/blob/cassandra-2.2/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L142] > * > [YamlConfigurationLoaderTest|https://github.com/apache/cassandra/blob/cassandra-2.2/test/unit/org/apache/cassandra/config/YamlConfigurationLoaderTest.java#L38] > If I'm right and we really need 1.7 language level we should fix those, which > seems quite straightforward. -- This message was sent by Atlassian Jira (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-16309) Send back client warnings when creating a new keyspace/table and the existing keyspace/table count is already above a configurable threshold
[ https://issues.apache.org/jira/browse/CASSANDRA-16309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243350#comment-17243350 ] Brandon Williams commented on CASSANDRA-16309: -- I really like this, but I think documenting the thresholds in the yaml will save a lot of trouble later (just commented out), as I know there's quite a wide variance between users here and choosing defaults that won't annoy some people is impossible. > Send back client warnings when creating a new keyspace/table and the existing > keyspace/table count is already above a configurable threshold > > > Key: CASSANDRA-16309 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16309 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta4 > > > We should warn clients when there are dangerously many keyspaces/tables in > the cluster -- This message was sent by Atlassian Jira (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-16309) Send back client warnings when creating a new keyspace/table and the existing keyspace/table count is already above a configurable threshold
[ https://issues.apache.org/jira/browse/CASSANDRA-16309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243350#comment-17243350 ] Brandon Williams edited comment on CASSANDRA-16309 at 12/3/20, 4:57 PM: I really like this, but I think documenting the thresholds in the yaml will save a lot of trouble later (just commented out), as I know there's quite a wide variance between users here and choosing defaults that won't annoy some people is impossible. Strong +1 otherwise. was (Author: brandon.williams): I really like this, but I think documenting the thresholds in the yaml will save a lot of trouble later (just commented out), as I know there's quite a wide variance between users here and choosing defaults that won't annoy some people is impossible. > Send back client warnings when creating a new keyspace/table and the existing > keyspace/table count is already above a configurable threshold > > > Key: CASSANDRA-16309 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16309 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta4 > > > We should warn clients when there are dangerously many keyspaces/tables in > the cluster -- This message was sent by Atlassian Jira (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=17243316#comment-17243316
]
Benjamin Lerer commented on CASSANDRA-16143:
That sound like a good compromise to me.
> 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: 1.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] [Updated] (CASSANDRA-16311) Extend the exclusion of replica filtering protection to other indices instead of just SASI
[ https://issues.apache.org/jira/browse/CASSANDRA-16311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16311: -- Description: There was a check introduced in CASSANDRA-8272 telling if an index is a SASI index and if it is, replica filtering protection was not triggered. There might be other custom index implementations which also do not support filtering protection and they do not have to be SASI indices neccessarily, however it is not possible exclude to them. was: There was a check introduced in CASSANDRA-8272 telling if an index is a SASI index and if it is, replica filtering protection was not triggered. There might be other custom index implementations which also do not support filtering protection and they do not have to be SASI indices neccessarily, however it is not possible exclude them. > Extend the exclusion of replica filtering protection to other indices instead > of just SASI > -- > > Key: CASSANDRA-16311 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16311 > Project: Cassandra > Issue Type: Task > Components: Feature/2i Index, Feature/SASI >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > > There was a check introduced in CASSANDRA-8272 telling if an index is a SASI > index and if it is, replica filtering protection was not triggered. > There might be other custom index implementations which also do not support > filtering protection and they do not have to be SASI indices neccessarily, > however it is not possible exclude to them. -- This message was sent by Atlassian Jira (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-16311) Extend the exclusion of replica filtering protection to other indices instead of just SASI
[ https://issues.apache.org/jira/browse/CASSANDRA-16311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-16311: - Assignee: Stefan Miklosovic > Extend the exclusion of replica filtering protection to other indices instead > of just SASI > -- > > Key: CASSANDRA-16311 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16311 > Project: Cassandra > Issue Type: Task > Components: Feature/2i Index, Feature/SASI >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > > There was a check introduced in CASSANDRA-8272 telling if an index is a SASI > index and if it is, replica filtering protection was not triggered. > There might be other custom index implementations which also do not support > filtering protection and they do not have to be SASI indices neccessarily, > however it is not possible exclude them. -- This message was sent by Atlassian Jira (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-13607) InvalidRequestException: Key may not be empty
[ https://issues.apache.org/jira/browse/CASSANDRA-13607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor updated CASSANDRA-13607: - Severity: Critical (was: Normal) > InvalidRequestException: Key may not be empty > - > > Key: CASSANDRA-13607 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13607 > Project: Cassandra > Issue Type: Bug >Reporter: anuragh >Priority: Urgent > Fix For: 2.1.x > > > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- AddressLoad Tokens OwnsHost ID > Rack > UN 10.146.80.71 175.01 GB 256 ? > 2a926f37-9b37-4915-9739-d04befec4f6b rack1 > UN 10.146.81.149 105.71 GB 256 ? > 79b06413-fad7-4d23-aafa-28e8f2b54400 rack1 > UN 10.146.80.56 180.43 GB 256 ? > b5eb237f-9edf-4963-9f2c-4e39d6af0f0a rack1 > UN 10.146.80.62 174.89 GB 256 ? > a7ba177f-0f21-4f24-b6fe-77937d005498 rack1 > Here adding this node(10.146.81.149) to the ring and the seed node is > 10.146.80.56. > This new node is not JMX enabled but all the other 3 are JMX enabled. > Is the below error is due to JMX? > RROR [SharedPool-Worker-11] 2017-06-15 07:15:46,939 Message.java:538 - > Unexpected exception during request; channel = [id: 0x57764a3b, > /10.146.144.86:47336 => /10.146.81.149:9042] > java.lang.AssertionError: > org.apache.cassandra.exceptions.InvalidRequestException: Key may not be empty > at > org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:125) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.auth.PasswordAuthenticator$PlainTextSaslAuthenticator.getAuthenticatedUser(PasswordAuthenticator.java:291) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:81) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439) > [apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335) > [apache-cassandra-2.1.7.jar:2.1.7] > at > io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) > [netty-all-4.0.23.Final.jar:4.0.23.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-all-4.0.23.Final.jar:4.0.23.Final] > at > io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32) > [netty-all-4.0.23.Final.jar:4.0.23.Final] > at > io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324) > [netty-all-4.0.23.Final.jar:4.0.23.Final] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_60] > at > org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164) > [apache-cassandra-2.1.7.jar:2.1.7] > at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) > [apache-cassandra-2.1.7.jar:2.1.7] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60] > Caused by: org.apache.cassandra.exceptions.InvalidRequestException: Key may > not be empty > at > org.apache.cassandra.cql3.QueryProcessor.validateKey(QueryProcessor.java:197) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:360) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:253) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:213) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:118) > ~[apache-cassandra-2.1.7.jar:2.1.7] > ... 12 common frames omitted -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16311) Extend the exclusion of replica filtering protection to other indices instead of just SASI
Stefan Miklosovic created CASSANDRA-16311: - Summary: Extend the exclusion of replica filtering protection to other indices instead of just SASI Key: CASSANDRA-16311 URL: https://issues.apache.org/jira/browse/CASSANDRA-16311 Project: Cassandra Issue Type: Task Components: Feature/2i Index, Feature/SASI Reporter: Stefan Miklosovic There was a check introduced in CASSANDRA-8272 telling if an index is a SASI index and if it is, replica filtering protection was not triggered. There might be other custom index implementations which also do not support filtering protection and they do not have to be SASI indices neccessarily, however it is not possible exclude them. -- This message was sent by Atlassian Jira (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-13607) InvalidRequestException: Key may not be empty
[
https://issues.apache.org/jira/browse/CASSANDRA-13607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243307#comment-17243307
]
Igor edited comment on CASSANDRA-13607 at 12/3/20, 4:09 PM:
I have the same issue after upgrading my kubernetes envs to 6.8.x
{code:java}
// 03-Dec-2020 16:08:58.325 WARNING [mainIOThread-4]
com.github.benmanes.caffeine.cache.LocalAsyncLoadingCache.lambda$get$3
Exception thrown during asynchronous load03-Dec-2020 16:08:58.325 WARNING
[mainIOThread-4]
com.github.benmanes.caffeine.cache.LocalAsyncLoadingCache.lambda$get$3
Exception thrown during asynchronous load
java.util.concurrent.CompletionException:
org.apache.cassandra.exceptions.InvalidRequestException: Key may not be empty
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
at
java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
at
java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1606)
at org.apache.cassandra.concurrent.TPCRunnable.run(TPCRunnable.java:101) at
org.apache.cassandra.concurrent.IOScheduler$PooledTaskWorker.run(IOScheduler.java:319)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at
java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748) at
org.apache.cassandra.utils.concurrent.InlinedThreadLocalThread.run(InlinedThreadLocalThread.java:251)
at org.apache.cassandra.concurrent.IOThread.run(IOThread.java:46)Caused by:
org.apache.cassandra.exceptions.InvalidRequestException: Key may not be empty
at
org.apache.cassandra.cql3.QueryProcessor.validateKey(QueryProcessor.java:234)
at
org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:1047)
at
org.apache.cassandra.cql3.statements.SelectStatement.getQuery(SelectStatement.java:397)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:610)WARN
[mainIOThread-1] 2020-12-03 16:08:58,325 DseAuthenticator.java:666 - Failed
to check permissionsorg.apache.cassandra.exceptions.InvalidRequestException:
Key may not be empty at
org.apache.cassandra.cql3.QueryProcessor.validateKey(QueryProcessor.java:234)
at
org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:1047)
at
org.apache.cassandra.cql3.statements.SelectStatement.getQuery(SelectStatement.java:397)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:610)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:348)
at
org.apache.cassandra.auth.CassandraRoleManager.getRole(CassandraRoleManager.java:526)
at
org.apache.cassandra.auth.CassandraRoleManager.getRoleData(CassandraRoleManager.java:347)
at
com.datastax.bdp.cassandra.auth.DseRoleManager.getRoleData(DseRoleManager.java:407)
at
org.apache.cassandra.auth.AuthCache$AsyncLoader.lambda$asyncLoad$0(AuthCache.java:317)
at
java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1604)
at org.apache.cassandra.concurrent.TPCRunnable.run(TPCRunnable.java:101) at
org.apache.cassandra.concurrent.IOScheduler$PooledTaskWorker.run(IOScheduler.java:319)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at
java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748) at
org.apache.cassandra.utils.concurrent.InlinedThreadLocalThread.run(InlinedThreadLocalThread.java:251)
at org.apache.cassandra.concurrent.IOThread.run(IOThread.java:46) at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:348)
at
org.apache.cassandra.auth.CassandraRoleManager.getRole(CassandraRoleManager.java:526)
at
org.apache.cassandra.auth.CassandraRoleManager.getRoleData(CassandraRoleManager.java:347)
at
[jira] [Commented] (CASSANDRA-13607) InvalidRequestException: Key may not be empty
[ https://issues.apache.org/jira/browse/CASSANDRA-13607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243307#comment-17243307 ] Igor commented on CASSANDRA-13607: -- I have the same issue after upgrading my kubernetes envs to 6.8.x > InvalidRequestException: Key may not be empty > - > > Key: CASSANDRA-13607 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13607 > Project: Cassandra > Issue Type: Bug >Reporter: anuragh >Priority: Normal > Fix For: 2.1.x > > > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- AddressLoad Tokens OwnsHost ID > Rack > UN 10.146.80.71 175.01 GB 256 ? > 2a926f37-9b37-4915-9739-d04befec4f6b rack1 > UN 10.146.81.149 105.71 GB 256 ? > 79b06413-fad7-4d23-aafa-28e8f2b54400 rack1 > UN 10.146.80.56 180.43 GB 256 ? > b5eb237f-9edf-4963-9f2c-4e39d6af0f0a rack1 > UN 10.146.80.62 174.89 GB 256 ? > a7ba177f-0f21-4f24-b6fe-77937d005498 rack1 > Here adding this node(10.146.81.149) to the ring and the seed node is > 10.146.80.56. > This new node is not JMX enabled but all the other 3 are JMX enabled. > Is the below error is due to JMX? > RROR [SharedPool-Worker-11] 2017-06-15 07:15:46,939 Message.java:538 - > Unexpected exception during request; channel = [id: 0x57764a3b, > /10.146.144.86:47336 => /10.146.81.149:9042] > java.lang.AssertionError: > org.apache.cassandra.exceptions.InvalidRequestException: Key may not be empty > at > org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:125) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.auth.PasswordAuthenticator$PlainTextSaslAuthenticator.getAuthenticatedUser(PasswordAuthenticator.java:291) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:81) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439) > [apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335) > [apache-cassandra-2.1.7.jar:2.1.7] > at > io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) > [netty-all-4.0.23.Final.jar:4.0.23.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-all-4.0.23.Final.jar:4.0.23.Final] > at > io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32) > [netty-all-4.0.23.Final.jar:4.0.23.Final] > at > io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324) > [netty-all-4.0.23.Final.jar:4.0.23.Final] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_60] > at > org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164) > [apache-cassandra-2.1.7.jar:2.1.7] > at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) > [apache-cassandra-2.1.7.jar:2.1.7] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60] > Caused by: org.apache.cassandra.exceptions.InvalidRequestException: Key may > not be empty > at > org.apache.cassandra.cql3.QueryProcessor.validateKey(QueryProcessor.java:197) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:360) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:253) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:213) > ~[apache-cassandra-2.1.7.jar:2.1.7] > at > org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:118) > ~[apache-cassandra-2.1.7.jar:2.1.7] > ... 12 common frames omitted -- This message was sent by Atlassian Jira (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-14834) Avoid keeping StreamingTombstoneHistogramBuilder.Spool in memory during the whole compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-14834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243272#comment-17243272
]
Adam Holmberg edited comment on CASSANDRA-14834 at 12/3/20, 4:02 PM:
-
I looked at it for a few minutes yesterday and at first blush it looked like it
should be a simple solution to release the large buffer when metadata is
"finalized". However, this
[comment|https://github.com/apache/cassandra/blob/00fb6d76d0a97af06ba27c1180d6dcddfa337fea/src/java/org/apache/cassandra/utils/streamhist/StreamingTombstoneHistogramBuilder.java#L138-L140]
gives me pause.
{quote}
* Creates a 'finished' snapshot of the current state of the historgram,
but leaves this builder instance
* open for subsequent additions to the histograms. Basically, this allows
us to have some degree of sanity
* wrt sstable early open.
{quote}
It seems to suggest that we have instances being updated after finalization.
Will have to dig into that a bit more. It might still be possible to update the
histogram without the large buffers, but I need to understand how impactful
that would be (or indeed, if the comment is still valid).
Not moving this ticket yet due to a handful of other things in-flight.
was (Author: aholmber):
I looked at it for a few minutes yesterday and at first blush it looked like it
should be a simple solution to release the large buffer when metadata is
"finalized". However, this
[comment|https://github.com/apache/cassandra/blob/00fb6d76d0a97af06ba27c1180d6dcddfa337fea/src/java/org/apache/cassandra/utils/streamhist/StreamingTombstoneHistogramBuilder.java#L138-L140]
gives me pause.
{quote}
* Creates a 'finished' snapshot of the current state of the historgram,
but leaves this builder instance
* open for subsequent additions to the histograms. Basically, this allows
us to have some degree of sanity
* wrt sstable early open.
{quote}
It seems to suggest that we have instances being updated after finalization.
Will have to dig into that a bit more. Not moving this ticket yet due to a
handful of other things in-flight.
> Avoid keeping StreamingTombstoneHistogramBuilder.Spool in memory during the
> whole compaction
>
>
> Key: CASSANDRA-14834
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14834
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Marcus Eriksson
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> Since CASSANDRA-13444 {{StreamingTombstoneHistogramBuilder.Spool}} is
> allocated to keep around an array with 131072 * 2 * 2 integers *per written
> sstable* during the whole compaction. With LCS at times creating 1000s of
> sstables during a compaction it kills the node.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14834) Avoid keeping StreamingTombstoneHistogramBuilder.Spool in memory during the whole compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-14834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243272#comment-17243272
]
Adam Holmberg commented on CASSANDRA-14834:
---
I looked at it for a few minutes yesterday and at first blush it looked like it
should be a simple solution to release the large buffer when metadata is
"finalized". However, this
[comment|https://github.com/apache/cassandra/blob/00fb6d76d0a97af06ba27c1180d6dcddfa337fea/src/java/org/apache/cassandra/utils/streamhist/StreamingTombstoneHistogramBuilder.java#L138-L140]
gives me pause.
{quote}
* Creates a 'finished' snapshot of the current state of the historgram,
but leaves this builder instance
* open for subsequent additions to the histograms. Basically, this allows
us to have some degree of sanity
* wrt sstable early open.
{quote}
It seems to suggest that we have instances being updated after finalization.
Will have to dig into that a bit more. Not moving this ticket yet due to a
handful of other things in-flight.
> Avoid keeping StreamingTombstoneHistogramBuilder.Spool in memory during the
> whole compaction
>
>
> Key: CASSANDRA-14834
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14834
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Marcus Eriksson
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> Since CASSANDRA-13444 {{StreamingTombstoneHistogramBuilder.Spool}} is
> allocated to keep around an array with 131072 * 2 * 2 integers *per written
> sstable* during the whole compaction. With LCS at times creating 1000s of
> sstables during a compaction it kills the node.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [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=17243251#comment-17243251
]
Jon Meredith commented on CASSANDRA-16143:
--
Bringing the discussion on what the default should be set to back here.
I'm fine with zero, however given Yifan added the log message to explain to
operators why streaming failed I think they have a fighting chance of tracking
down failures and think something like 5 minutes would provide for faster
failure than system default TCP timeouts while tolerating the majority of messy
server tuning like the cluster I found this on.
> 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: 1.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
>
[jira] [Commented] (CASSANDRA-16205) Offline token allocation strategy generator tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243244#comment-17243244
]
Ekaterina Dimitrova commented on CASSANDRA-16205:
-
I see there was a collision between our comments. :-) I meant the previous CI
run. I don't expect the last one to introduce any new failures but let's say +1
on its clean completion :-)
> Offline token allocation strategy generator tool
>
>
> Key: CASSANDRA-16205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16205
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Local/Scripts
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> A command line tool to generate tokens (using the
> allocate_tokens_for_local_replication_factor algorithm) for pre-configuration
> of {{initial_tokens}} in cassandra.yaml.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16205) Offline token allocation strategy generator tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243239#comment-17243239
]
Ekaterina Dimitrova edited comment on CASSANDRA-16205 at 12/3/20, 3:00 PM:
---
I trust your experienced committers' judgement on the solution design so I
checked the implementation:
- CI run looks good
- I went through the refactoring to ensure there are no changes to the product.
Looks good. I like how you rearranged the tests!
- Output, docs look good.
Except the very few nits you already addressed, I didn't find any issues. +1
Thank you for all the hard work!
was (Author: e.dimitrova):
I trust your experienced committers' judgement on the solution design so I
checked the implementation:
- CI run looks good
- I went through the refactoring to ensure there are no changes to the product.
Looks good. I like how you rearranged the tests!
- Output, docs look good.
Except the very few nits you addressed, I didn't find any issues. +1
Thank you for all the hard work!
> Offline token allocation strategy generator tool
>
>
> Key: CASSANDRA-16205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16205
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Local/Scripts
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> A command line tool to generate tokens (using the
> allocate_tokens_for_local_replication_factor algorithm) for pre-configuration
> of {{initial_tokens}} in cassandra.yaml.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16205) Offline token allocation strategy generator tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243239#comment-17243239
]
Ekaterina Dimitrova commented on CASSANDRA-16205:
-
I trust your experienced committers' judgement on the solution design so I
checked the implementation:
- CI run looks good
- I went through the refactoring to ensure there are no changes to the product.
Looks good. I like how you rearranged the tests!
- Output, docs look good.
Except the very few nits you addressed, I didn't find any issues. +1
Thank you for all the hard work!
> Offline token allocation strategy generator tool
>
>
> Key: CASSANDRA-16205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16205
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Local/Scripts
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> A command line tool to generate tokens (using the
> allocate_tokens_for_local_replication_factor algorithm) for pre-configuration
> of {{initial_tokens}} in cassandra.yaml.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16205) Offline token allocation strategy generator tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243236#comment-17243236
]
Michael Semb Wever commented on CASSANDRA-16205:
Some additions added from [~e.dimitrova]'s review.
Link to patch the same:
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_16205
CI run for it is here:
https://ci-cassandra.apache.org/job/Cassandra-devbranch/243
> Offline token allocation strategy generator tool
>
>
> Key: CASSANDRA-16205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16205
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Local/Scripts
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> A command line tool to generate tokens (using the
> allocate_tokens_for_local_replication_factor algorithm) for pre-configuration
> of {{initial_tokens}} in cassandra.yaml.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13325) Bring back the accepted encryption protocols list as configurable option
[
https://issues.apache.org/jira/browse/CASSANDRA-13325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-13325:
---
Fix Version/s: 4.0
> 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, 4.0-beta4
>
> Attachments: trunk.diff
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> With CASSANDRA-10508, the hard coded list of accepted encryption protocols
> was eliminated. For some use cases, it is necessary to restrict the
> encryption protocols used for communication between client and server.
> Default JVM way of negotiations allows the best encryption protocol that
> client can use.
> e.g. I have set Cassandra to use encryption. Ideally client and server
> negotiate to use best protocol (TLSv1.2). But a malicious client might force
> TLSv1.0 which is susceptible to POODLE attacks.
> At the moment only way to restrict the encryption protocol is using the
> {{jdk.tls.client.protocols}} systems property. If I dont have enough access
> to modify this property, I dont have any way of restricting the encryption
> protocols.
> I am proposing bring back the accepted_protocols property but make it
> configurable. If not specified, let the JVM take care of the TLS negotiations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-16310:
Fix Version/s: (was: 4.0-beta4)
4.x
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(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-16309) Send back client warnings when creating a new keyspace/table and the existing keyspace/table count is already above a configurable threshold
[ https://issues.apache.org/jira/browse/CASSANDRA-16309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16309: Test and Documentation Plan: tests added Status: Patch Available (was: Open) > Send back client warnings when creating a new keyspace/table and the existing > keyspace/table count is already above a configurable threshold > > > Key: CASSANDRA-16309 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16309 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta4 > > > We should warn clients when there are dangerously many keyspaces/tables in > the cluster -- This message was sent by Atlassian Jira (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-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-16310:
Test and Documentation Plan: new tests + cci runs
Status: Patch Available (was: Open)
patch: https://github.com/krummas/cassandra/commits/marcuse/16310
cci:
https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F16310
tracks size + counts during full repair (or preview (-vd) repair), outputs the
top partitions in tablestats or jmx:
{code}
$ bin/nodetool -p 7100 tablestats tlp_stress
Total number of tables: 42
Keyspace : tlp_stress
Read Count: 0
Read Latency: NaN ms
Write Count: 0
Write Latency: NaN ms
Pending Flushes: 0
Table: random_access
SSTable count: 1
[]
Dropped Mutations: 0
Top partitions by size:
Key Size
001.0.5984293134
001.0.5094242986
001.0.4574552964
001.0.4997582886
001.0.25632 2864
001.0.5072062787
001.0.37708 2784
001.0.1318302753
001.0.4313102738
001.0.28517 2729
Top partitions by tombstone count:
Key Count
001.0.5503709
001.0.7668489
001.0.5186288
001.0.928950
[jira] [Updated] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-16310:
Change Category: Operability
Complexity: Normal
Component/s: Local/Other
Fix Version/s: 4.0-beta4
Status: Open (was: Triage Needed)
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-beta4
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
Marcus Eriksson created CASSANDRA-16310:
---
Summary: Track top partitions (by size and tombstone count) and
display in nodetool tablestats
Key: CASSANDRA-16310
URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
Project: Cassandra
Issue Type: Improvement
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
We should track the top partitions by size and tombstone count and display in
{{nodetool tablestats}}
--
This message was sent by Atlassian 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-in-jvm-dtest-api] branch release updated: [maven-release-plugin] prepare for next development iteration
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a commit to branch release in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git The following commit(s) were added to refs/heads/release by this push: new d5174b1 [maven-release-plugin] prepare for next development iteration d5174b1 is described below commit d5174b1f44b7d9cb919d4975b4d437041273c09c Author: Alex Petrov AuthorDate: Thu Dec 3 13:59:24 2020 +0100 [maven-release-plugin] prepare for next development iteration --- pom.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index 0941f19..4e206b4 100644 --- a/pom.xml +++ b/pom.xml @@ -27,7 +27,7 @@ 4.0.0 org.apache.cassandra dtest-api -0.0.7 +0.0.8-SNAPSHOT In JVM Test API In JVM Test API @@ -174,7 +174,7 @@ scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git - 0.0.7 + 0.0.6 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] annotated tag 0.0.7 created (now 520254a)
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a change to annotated tag 0.0.7 in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git. at 520254a (tag) tagging 2b7e2850c2bd2299810e10821aa10fa41bd0e511 (commit) replaces 0.0.6 by Alex Petrov on Thu Dec 3 13:59:19 2020 +0100 - Log - [maven-release-plugin] copy for tag 0.0.7 --- No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] 01/01: [maven-release-plugin] prepare release 0.0.7
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a commit to branch release in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git commit 2b7e2850c2bd2299810e10821aa10fa41bd0e511 Author: Alex Petrov AuthorDate: Thu Dec 3 13:59:12 2020 +0100 [maven-release-plugin] prepare release 0.0.7 --- pom.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index c9f8131..0941f19 100644 --- a/pom.xml +++ b/pom.xml @@ -27,7 +27,7 @@ 4.0.0 org.apache.cassandra dtest-api -0.0.7-SNAPSHOT +0.0.7 In JVM Test API In JVM Test API @@ -174,7 +174,7 @@ scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git - 0.0.6 + 0.0.7 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] branch release updated (9ad1c0f -> 2b7e285)
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a change to branch release in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git. from 9ad1c0f [maven-release-plugin] prepare for next development iteration add 3d36cd1 nodetool assert apis do not include the new stdout and stderr in the failure message (#25) add b466ec8 Add Metrics to instance API new 2b7e285 [maven-release-plugin] prepare release 0.0.7 The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 5 ++ pom.xml| 4 +- .../cassandra/distributed/api/IInstance.java | 4 ++ .../cassandra/distributed/api/NodeToolResult.java | 4 ++ .../cassandra/distributed/shared/Metrics.java | 58 ++ .../distributed/api/NodeToolOutputTest.java| 48 +- 6 files changed, 120 insertions(+), 3 deletions(-) create mode 100644 src/main/java/org/apache/cassandra/distributed/shared/Metrics.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] branch trunk updated: Add Metrics to instance API
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git
The following commit(s) were added to refs/heads/trunk by this push:
new b466ec8 Add Metrics to instance API
b466ec8 is described below
commit b466ec8ad6833a898738e94b592646a3e88df52e
Author: Alex Petrov
AuthorDate: Thu Dec 3 10:29:18 2020 +0100
Add Metrics to instance API
Patch by Alex Petrov; reviewed by Benedict Elliott Smith for CASSANDRA-16136
---
CHANGES.txt| 5 ++
.../cassandra/distributed/api/IInstance.java | 4 ++
.../cassandra/distributed/shared/Metrics.java | 58 ++
3 files changed, 67 insertions(+)
diff --git a/CHANGES.txt b/CHANGES.txt
index 849c787..0e40234 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,8 @@
+# 0.0.7
+
+CASSANDRA-16136: Add Metrics to instance API
+CASSANDRA-16272: Nodetool assert apis do not include the new stdout and stderr
in the failure message
+
# 0.0.6
CASSANDRA-16148: Add IInstance#getReleaseVersionString
diff --git a/src/main/java/org/apache/cassandra/distributed/api/IInstance.java
b/src/main/java/org/apache/cassandra/distributed/api/IInstance.java
index 045ea00..8ac6235 100644
--- a/src/main/java/org/apache/cassandra/distributed/api/IInstance.java
+++ b/src/main/java/org/apache/cassandra/distributed/api/IInstance.java
@@ -23,6 +23,8 @@ import java.util.List;
import java.util.UUID;
import java.util.concurrent.Future;
+import org.apache.cassandra.distributed.shared.Metrics;
+
// The cross-version API requires that an Instance has a constructor signature
of (IInstanceConfig, ClassLoader)
public interface IInstance extends IIsolatedExecutor
{
@@ -55,6 +57,8 @@ public interface IInstance extends IIsolatedExecutor
int liveMemberCount();
+Metrics metrics();
+
NodeToolResult nodetoolResult(boolean withNotifications, String...
commandAndArgs);
default NodeToolResult nodetoolResult(String... commandAndArgs)
diff --git a/src/main/java/org/apache/cassandra/distributed/shared/Metrics.java
b/src/main/java/org/apache/cassandra/distributed/shared/Metrics.java
new file mode 100644
index 000..6a702ad
--- /dev/null
+++ b/src/main/java/org/apache/cassandra/distributed/shared/Metrics.java
@@ -0,0 +1,58 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.distributed.shared;
+
+import java.util.List;
+import java.util.Map;
+import java.util.function.Predicate;
+
+public interface Metrics
+{
+List getNames();
+
+long getCounter(String name);
+Map getCounters(Predicate filter);
+
+double getHistogram(String name, MetricValue value);
+Map getHistograms(Predicate filter, MetricValue
value);
+
+Object getGauge(String name);
+Map getGauges(Predicate filter);
+
+double getMeter(String name, Rate value);
+Map getMeters(Predicate filter, Rate value);
+
+double getTimer(String name, MetricValue value);
+Map getTimers(Predicate filter, MetricValue value);
+
+enum MetricValue
+{
+COUNT,
+MEDIAN, P75, P95, P98, P99, P999,
+MAX, MEAN, MIN, STDDEV
+}
+
+enum Rate
+{
+RATE15_MIN,
+RATE5_MIN,
+RATE1_MIN,
+RATE_MEAN
+}
+}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16136) Provide access to metrics from in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243091#comment-17243091 ] Alex Petrov edited comment on CASSANDRA-16136 at 12/3/20, 12:51 PM: |[API change|https://github.com/apache/cassandra-in-jvm-dtest-api/pull/26]|[trunk patch|https://github.com/apache/cassandra/pull/843]|[tests|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=CASSANDRA-16136-trunk]| was (Author: ifesdjeen): |[API change|https://github.com/apache/cassandra-in-jvm-dtest-api/pull/26]|[trunk patch|https://github.com/ifesdjeen/cassandra/pull/new/CASSANDRA-16136-trunk]|[tests|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=CASSANDRA-16136-trunk]| > Provide access to metrics from in-jvm dtests > > > Key: CASSANDRA-16136 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16136 > Project: Cassandra > Issue Type: New Feature > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Current implementation requires of in-jvm dtests requires using > callOnInstance in order to get metrics out of the in-jvm test node. Since > many dtests require to check metrics, we need a version-agnostic mechanism > that allows us to query the value of the metric by its published name instead > of peeking into internals. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16136) Provide access to metrics from in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-16136: --- Status: Review In Progress (was: Patch Available) > Provide access to metrics from in-jvm dtests > > > Key: CASSANDRA-16136 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16136 > Project: Cassandra > Issue Type: New Feature > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Current implementation requires of in-jvm dtests requires using > callOnInstance in order to get metrics out of the in-jvm test node. Since > many dtests require to check metrics, we need a version-agnostic mechanism > that allows us to query the value of the metric by its published name instead > of peeking into internals. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16136) Provide access to metrics from in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-16136: --- Status: Ready to Commit (was: Review In Progress) +1 > Provide access to metrics from in-jvm dtests > > > Key: CASSANDRA-16136 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16136 > Project: Cassandra > Issue Type: New Feature > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Current implementation requires of in-jvm dtests requires using > callOnInstance in order to get metrics out of the in-jvm test node. Since > many dtests require to check metrics, we need a version-agnostic mechanism > that allows us to query the value of the metric by its published name instead > of peeking into internals. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16136) Provide access to metrics from in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16136: Test and Documentation Plan: Test for a single metric included. Status: Patch Available (was: Open) |[API change|https://github.com/apache/cassandra-in-jvm-dtest-api/pull/26]|[trunk patch|https://github.com/ifesdjeen/cassandra/pull/new/CASSANDRA-16136-trunk]|[tests|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=CASSANDRA-16136-trunk]| > Provide access to metrics from in-jvm dtests > > > Key: CASSANDRA-16136 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16136 > Project: Cassandra > Issue Type: New Feature > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Current implementation requires of in-jvm dtests requires using > callOnInstance in order to get metrics out of the in-jvm test node. Since > many dtests require to check metrics, we need a version-agnostic mechanism > that allows us to query the value of the metric by its published name instead > of peeking into internals. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16192) Add more tests to cover compaction metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16192: --- Reviewers: Benjamin Lerer > Add more tests to cover compaction metrics > -- > > Key: CASSANDRA-16192 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16192 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Benjamin Lerer >Assignee: Adam Holmberg >Priority: Normal > Fix For: 4.0-beta > > > Some compaction metrics do not seems to be tested. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16309) Send back client warnings when creating a new keyspace/table and the existing keyspace/table count is already above a configurable threshold
[
https://issues.apache.org/jira/browse/CASSANDRA-16309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243061#comment-17243061
]
Marcus Eriksson commented on CASSANDRA-16309:
-
patch: https://github.com/krummas/cassandra/commits/marcuse/tablecountwarnings
cci:
https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2Ftablecountwarnings
{code}
cqlsh> create keyspace x with replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
Warnings :
Cluster already contains 45 keyspaces. Having a large number of keyspaces will
significantly slow down schema dependent cluster operations.
cqlsh> create table x.y (id int primary key, x int);
Warnings :
Cluster already contains 200 tables in 45 keyspaces. Having a large number of
tables will significantly slow down schema dependent cluster operations.
{code}
> Send back client warnings when creating a new keyspace/table and the existing
> keyspace/table count is already above a configurable threshold
>
>
> Key: CASSANDRA-16309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16309
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0-beta4
>
>
> We should warn clients when there are dangerously many keyspaces/tables in
> the cluster
--
This message was sent by Atlassian Jira
(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-16309) Send back client warnings when creating a new keyspace/table and the existing keyspace/table count is already above a configurable threshold
[ https://issues.apache.org/jira/browse/CASSANDRA-16309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16309: Change Category: Operability Complexity: Low Hanging Fruit Component/s: Cluster/Schema Fix Version/s: 4.0-beta4 Status: Open (was: Triage Needed) > Send back client warnings when creating a new keyspace/table and the existing > keyspace/table count is already above a configurable threshold > > > Key: CASSANDRA-16309 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16309 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta4 > > > We should warn clients when there are dangerously many keyspaces/tables in > the cluster -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16309) Send back client warnings when creating a new keyspace/table and the existing keyspace/table count is already above a configurable threshold
Marcus Eriksson created CASSANDRA-16309: --- Summary: Send back client warnings when creating a new keyspace/table and the existing keyspace/table count is already above a configurable threshold Key: CASSANDRA-16309 URL: https://issues.apache.org/jira/browse/CASSANDRA-16309 Project: Cassandra Issue Type: Improvement Reporter: Marcus Eriksson Assignee: Marcus Eriksson We should warn clients when there are dangerously many keyspaces/tables in the cluster -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
