cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tommy Stendahl (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13886) OOM put node in limbo
Date Tue, 26 Sep 2017 11:47:00 GMT


Tommy Stendahl commented on CASSANDRA-13886:

I have done some work on this issue, even if it happens very seldomly its very bad when it
happens. Since the JVM doesn’t die properly our monitoring system doesn’t restart Cassandra
on this node, it requires a manual intervention. The work around with {{-XX:+ExitOnOutOfMemoryError}}
works fine, and you can also use {{-XX:+CrashOnOutOfMemoryError}} if you want core dumps.
But as I understand these options are only available from java 8u92 so they might not be an
option for every one. I think an alternative is to improve {{HeapUtils.generateHeapDump()}}
so we catch {{Throwable}} so we prevent any exceptions from leaking out from {{HeapUtils.generateHeapDump()}},
this would allow execution to continue in {{JVMStabilityInspector.inspectThrowable()}} until
we reach {{killer.killCurrentJVM(t)}} that will properly kill the jvm.
I have prepared a patch for this on the 2.2 branch but it should merge fine to all branches.

> OOM put node in limbo
> ---------------------
>                 Key: CASSANDRA-13886
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra version 2.2.10
>            Reporter: Marcus Olsson
>            Assignee: Tommy Stendahl
>            Priority: Minor
>              Labels: lhf
> In one of our test clusters we have had some issues with OOM. While working on fixing
this it was discovered that one of the nodes that got OOM actually wasn't shut down properly.
Instead it went into a half-up-state where the affected node considered itself up while all
other nodes considered it as down.
> The following stacktrace was observed which seems to be the cause of this:
> {noformat}
> java.lang.NoClassDefFoundError: Could not initialize class java.lang.UNIXProcess
>         at java.lang.ProcessImpl.start( ~[na:1.8.0_131]
>         at java.lang.ProcessBuilder.start( ~[na:1.8.0_131]
>         at java.lang.Runtime.exec( ~[na:1.8.0_131]
>         at java.lang.Runtime.exec( ~[na:1.8.0_131]
>         at org.apache.cassandra.utils.HeapUtils.generateHeapDump( ~[apache-cassandra-2.2.10.jar:2.2.10]
>         at org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(
>         at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$
>         at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$
>         at ~[apache-cassandra-2.2.10.jar:2.2.10]
>         at [na:1.8.0_131]
> {noformat}
> It seems that if an unexpected exception/error is thrown inside JVMStabilityInspector.inspectThrowable
the JVM is not actually shut down but instead keeps on running. My expectation is that the
JVM should shut down in case OOM is thrown.
> Potential workaround is to add:
> {noformat}
> JVM_OPTS="$JVM_OPTS -XX:+ExitOnOutOfMemoryError"
> {noformat}
> to

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message