[ https://issues.apache.org/jira/browse/CASSANDRA-15214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889767#comment-16889767 ]
Tomas Shestakov edited comment on CASSANDRA-15214 at 7/21/19 5:08 PM: ---------------------------------------------------------------------- There is two options to handle *OOM* in java version >= 8u92 [https://www.oracle.com/technetwork/java/javase/8u92-relnotes-2949471.html] -XX:+ExitOnOutOfMemoryError -XX:+CrashOnOutOfMemoryError was (Author: shestakov): There is two options to handle *OOM* in java 8u92 [https://www.oracle.com/technetwork/java/javase/8u92-relnotes-2949471.html] -XX:+ExitOnOutOfMemoryError -XX:+CrashOnOutOfMemoryError > OOMs caught and not rethrown > ---------------------------- > > Key: CASSANDRA-15214 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15214 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode > Reporter: Benedict > Priority: Normal > Fix For: 4.0 > > > Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, > so presently there is no way to ensure that an OOM reaches the JVM handler to > trigger a crash/heapdump. > It may be that the simplest most consistent way to do this would be to have a > single thread spawned at startup that waits for any exceptions we must > propagate to the Runtime. > We could probably submit a patch upstream to Netty, but for a guaranteed > future proof approach, it may be worth paying the cost of a single thread. -- This message was sent by Atlassian JIRA (v7.6.14#76016) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org