I've given it some thought in the past. In the end, I usually talk myself
out of it because I think it increases the surface area for failure. That
is, managing N processes is more difficult that managing one process. But
if the additional failure modes are addressed, there are some interesting

For example, having gossip in its own process would decrease the odds that
a node is marked dead because STW GC is happening in the storage JVM. On
the flipside, you'd need checks to make sure that the gossip process can
recognize when the storage process has died vs just running a long GC.

I don't know that I'd go so far as to have separate processes for
keyspaces, etc.

There is probably some interesting work that could be done to support the
orgs who run multiple cassandra instances on the same node (multiple
gossipers in that case is at least a little wasteful).

I've also played around with using domain sockets for IPC inside of
cassandra. I never ran a proper benchmark, but there were some throughput
advantages to this approach.



On Thu, Feb 22, 2018 at 8:39 PM, Carl Mueller <carl.muel...@smartthings.com>

> GC pauses may have been improved in newer releases, since we are in 2.1.x,
> but I was wondering why cassandra uses one jvm for all tables and
> keyspaces, intermingling the heap for on-JVM objects.
> ... so why doesn't cassandra spin off a jvm per table so each jvm can be
> tuned per table and gc tuned and gc impacts not impact other tables? It
> would probably increase the number of endpoints if we avoid having an
> overarching query router.

Reply via email to