Thanks all for your comments and suggestions.
You are absolutely right, an OutOfMemory problem should never occure in a well tuned environment with an application which has no memory leaks.
With this option we would be absolutely sure, that "just in case" of an OutOfMemory event, that the process ends, because we can't longer trust the process. We see sometimes PermGen space OutOfMemory errors in GF when we often redeploy (we tested different PermGen sizes and unfortunately we also need to run on 32bit systems where we have hard memory limits in the JVM). So there is a small possibility that - after installing some application updates via redeploy without restarting GF - to run in this problem. With this "kill on OufOfMemory" I want to sleep better, because our software is a 24h 7day application used in electronic production lines and our support stuff has no problem to restart a died process - but they are overstrained to analyze if a java process is maybe "ill" and behaves wrong in case of a previous OutOfMemory event.
greetings,
Frank
[Message sent by forum member 'fmeili' (fmeili)]
http://forums.java.net/jive/thread.jspa?messageID=346058