Re: How to interpret uninterpreted `nodetool compact` java stack trace in 3.11.0

Ok thanks for your reply. I do believe this one is already in JIRA: https://issues.apache.org/jira/browse/CASSANDRA-13897?jql=text%20~%20%22nodetool%20flush%20compact%22 Regards, Ridley NB: The debug.log provides only minimal extra information above what is in that JIRA ticket. The name of the

Re: How to interpret uninterpreted `nodetool compact` java stack trace in 3.11.0

Likely failed but you’d need to check the full logs to be positive Assertion errors typically should be reported on the JIRA - you’ve encountered a situation the developer didn’t think was possible so it’s aborted, but we need to know that you encountered it so we can fix it Please open the ji

How to interpret uninterpreted `nodetool compact` java stack trace in 3.11.0

Hi Everyone, I wonder how do we interpret this error message? Does it mean that the compaction failed? Is this an error I should be concerned about? Thanks, Ridley cassandra@server:$ nodetool compact error: null -- StackTrace -- java.lang.AssertionError at org.apache.cassandra.cache.ChunkCache

Re: Got error, removing parent repair session - When doing multiple repair -pr — Cassandra 3.x

Nvm forgot about that ticket and that full repairs do anti-compactions now. For anyone else who doesn't already know, what I said above is true but full repairs won't help the multiple concurrent repair issue because they do anti-compactions a

Re: DataStax Spark driver performance for analytics workload

spark-cassandra-connector will provide the best way to achieve what you want, however under the hood it's still going to result in reading all the data, and because of the way Cassandra works it will essentially read the same SSTables multiple times from random points. You might be able to tune to

Re: Ip restriction for username

No this functionality doesn't exist in Apache Cassandra. You could add it though...​

Re: Got error, removing parent repair session - When doing multiple repair -pr — Cassandra 3.x

Note 3.11 uses incremental repair by default. If you were using full repairs previously you'll need to specify -full as well when repairing in 3.11. Incremental repair won't work if you run it on multiple nodes at the same time that have replica overlap in the token ring. ​