On 04/13/2012 01:19 PM, Michi Mutsuzaki wrote:
I agree with both Scott's and Ryan's points. I think it makes to:
1. Make this behavior configurable (with default being "turned off") to
preserve backward compatibility.
2. Re-throw the exception instead of exiting with System.exit(1) so that users
can use flags like -XX:+HeapDumpOnOutOfMemoryError.
I don't think re-throwing exceptions from an uncaught exception handler
is an option:
http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.UncaughtExceptionHandler.html#uncaughtException%28java.lang.Thread,%20java.lang.Throwable%29
" Any exception thrown by this method will be ignored by the Java
Virtual Machine."
--Michi
________________________________________
From: Scott Fines [[email protected]]
Sent: Friday, April 13, 2012 8:15 AM
To: [email protected]
Cc: [email protected]; [email protected]
Subject: Re: Input on a change
On some JVMs (the HotSpot for sure, but maybe others too?) there's a JVM
for performing actions on OutOfMemoryErrors (-XX:OnOutOfMemoryError="<cmd
args>, -XX:+HeapDumpOnOutOfMemoryError and maybe some others that I can't
remember off the top of my head). Will these triggers still be fired, or
will the catch-all prevent them?
I'm still +1 for the change no matter what, but it's probably a good idea
to mention that in the docs if they don't work.
Scott
On Fri, Apr 13, 2012 at 10:09 AM, Camille Fournier<[email protected]>wrote:
Hi everyone,
I'm trying to evaluate a patch that Jeremy Stribling has submitted, and I'd
like some feedback from the user base on it.
https://issues.apache.org/jira/browse/ZOOKEEPER-1442
The current behavior of ZK when we get an uncaught exception is to log it
and try to move on. This is arguably not the right thing to do, and will
possibly cause ZK to limp along with a bad VM (say, in an OOM state) for
longer than it should.
The patch proposes that when we get an instance of java.lang.Error, we
should do a system.exit to fast-fail the process. With the possible
exception of ThreadDeath (which may or may not be an unrecoverable system
state depending on the thread), I think this makes sense, but I would like
to hear from others if they have an opinion. I think it's better to kill
the process and let your monitoring services detect process death (and thus
restart) than possibly linger unresponsive for a while, are there scenarios
that we're missing where this error can occur and you wouldn't want the
process killed?
Thanks for your feedback,
Camille
