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.