+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 tp
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 JMX
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:
-XX:+UnlockExperiment
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 f
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 previous
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 r
