On Fri, Apr 20, 2012 at 5:09 PM, Oleksiy Stashok
<oleksiy.stashok_at_oracle.com> wrote:
> Hi,
>
> pls. see comments bellow...
>
> On 04/20/2012 03:19 AM, gonfidentschal_at_gmail.com wrote:
>>
>> what works fine:
>> if just one request/thread requires a lot of memory and then throws the
>> OutOfMemoryError the vm may recover and continue as if nothing
>> happened.
>> i can log the error, and a sysadmin may look at it later on and assign
>> more memory if he wishes to, or pass the case on to a developer to
>> lower memory requirements per thread .
>> there is no immediate action required since other requests will work
>> fine.
>>
>> what doesn't work:
>> when the situation is caused by the main application and not just one
>> thread, the vm will try to handle it and keep running. the performance
>> will be totally inacceptable and many requests will either time out or
>> get the same OutOfMemoryError.
>> this needs immediate action by the sysadmin to restart the application.
>> it might then run fine for a while or long time until memory fills up
>> again. he may also assign more ram to the vm.
>> this is my situation, and i would like to make the application exit.
>> the exit will cause the error to be logged, the sysadmin to be
>> informed, and the application to be automatically restarted (using a
>> wrapper around my application). the downtime will be short, and the
>> sysadmin has some time to analyze the situation and assign more memory
>> for next time.
>>
>> how do i achieve this?
>> is there anything built in that can be enabled for acting based on
>> OutOfMemoryError in a single thread? a strategy to implement, for
>> example exit on first occurrence, or on 3rd within a certain amount of
>> time? or should i listen to it with
>> Thread.setUncaughtExceptionHandler()?
>
> IMO when it comes to OOM which you described in "what doesn't work", it's
> very difficult to handle this situation properly. Cause the actual OOM
> handler logic may lead just to another OOM. For example if you try to stop
> the server - it will fail due to OOM.
>
> Probably what you can do is to monitor actual JVM memory consumption
> statistics and try to prevent OOM earlier rather than handle it when it
> happens.
We always generate heap dump on OOM to at least fix them.
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=.....
Tigran.
> You can use standard Java MBeans [1].
>
> Thanks.
>
> WBR,
> Alexey.
>
> [1] http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
>
>