Thanx Jeff,
Hmmm… when you say unhealthy system, what would I check to rule that out
And is there an easy way to monitor GC time in a Cassandra cluster, trying to
understand if this is the case
-Tobias
From: Jeff Jirsa
Reply to: "user@cassandra.apache.org"
Date: Tuesday, 1 September 2020 at 17:
Hi Sam
Is there any alternative to avoid this vulnerability? Like upgrade to
specific JVM version.
Regards
Manish
On Tue, Sep 1, 2020 at 8:03 PM Sam Tunnicliffe wrote:
> CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability
>
> Versions Affected:
> All versions prior to: 2.1.22, 2.2.18, 3.0
Yes, it's possible. A typical JVM GC pause for most configs is on the order
of 50-200ms. If you have a host do a small collection/pause, then the read
at #4 is basically racing the write at #1
(or, if you have an unhealthy cluster that's regularly dropping writes due
to much larger problems, then
CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability
Versions Affected:
All versions prior to: 2.1.22, 2.2.18, 3.0.22, 3.11.8 and 4.0-beta2
Description:
It is possible for a local attacker without access to the Apache Cassandra
process or configuration files to manipulate the RMI registry to
Did you mean LOCAL_QUORUM? Because QUORUM will require 4 out of 6 replicas,
not 2 out of 3. :) But it sounds like you are using QUORUM because you said
it syncs to all nodes in DC2.
To answer your question, RR *can* be triggered if you're reading before the
replicas are *eventually* consistent. Ch
Hi
We are seeing READ REPAIRs happening, and my understanding is this
Setup 2 DCs with lots of Nodes, Replication Factor = 3
1. Data written (on INSERT/UPDATE)
2. Data replicated by Cassandra, but will not finish before (4) below
3. Wait 80 ms on average
4. Data read again with QUORU