You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2009/06/05 17:42:07 UTC
[jira] Commented: (CASSANDRA-218) exit if OOM occurs
[ https://issues.apache.org/jira/browse/CASSANDRA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716646#action_12716646 ]
Jonathan Ellis commented on CASSANDRA-218:
------------------------------------------
public static void main(String[] args) throws Throwable
{
try
{
byte[] b = new byte[1000000000];
}
catch (OutOfMemoryError e)
{
System.exit(1);
}
}
run with -XX:+HeapDumpOnOutOfMemoryError gives
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid29987.hprof ...
Heap dump file created [760128 bytes in 0.012 secs]
Process finished with exit code 1
so this approach looks ok.
> exit if OOM occurs
> ------------------
>
> Key: CASSANDRA-218
> URL: https://issues.apache.org/jira/browse/CASSANDRA-218
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
>
> The drawbacks to continuing running (generating internal errors in strange places) outweigh the benefits (maybe having the thread that OOM'd freed will allow us to serve some other requests successfully).
> I'm guessing that adding if (e instanceof OOME) { system.exit() } in our DefaultUncaughtExceptionHandler would do the trick.
> Only question is, would that happen before or after the XX:+HeapDumpOnOutOfMemoryError gets to fire?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.