Thanks Jeff. CASSANDRA-6434 is exactly the issue. Do we have a plan/ticket
to get rid of GCGS (and make only_purge_repaired_tombstones default)? Will
it be covered in CASSANDRA-14145?
I created a ticket CASSANDRA-14543 for purgeable tombstone hints replaying,
which doesn't fix the root cause but
CVE-2018-8016 describes an issue with the default configuration of
Apache Cassandra releases 3.8 through 3.11.1 which binds an
unauthenticated JMX/RMI interface to all network interfaces allowing
attackers to execute arbitrary Java code via an RMI request. This
issue is a regression of the
The use of Mesos in production for cassandra was a failure due to the
inability to reserve network bandwidth as Mesos can only allocate cpu and
memory profiles to a task. So, assuming you are either running on
dedicated/manually controlled VM's, or are no running a product/meaningful
data storage
Hi,
Regarding the limits in linux cgroups (as used in Kubernetes/Mesos), I
was wondering if there are any recommendation (didn't find anything on
this topic).
In general on Java 8 running instances, it is advised to run those
options to take into account cgroup environment:
I don’t think it’s really necessary. Or at least I’m not seeing why having
individual, specialised virtual tables is not sufficient.
Nor do I think that we should expose everything that nodetool does, so IMO we
shouldn’t aim for that. Even if the goal were to eventually deprecate and
remove
+1 on doing this on a case-by-case basis. The threadpool_metrics looks
reasonable. It's best not to shoehorn all metrics into a single table with all
possible columns.
Dinesh
On Friday, June 22, 2018, 8:11:33 AM PDT, Chris Lohfink
wrote:
I think this can really be case by case. In
