zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michi Mutsuzaki <mi...@cs.stanford.edu>
Subject Re: Input on a change
Date Fri, 13 Apr 2012 21:31:16 GMT
Ah I see. I guess log and System.exit(1) is the best we can do then.


On Fri, Apr 13, 2012 at 2:25 PM, Jeremy Stribling <strib@nicira.com> wrote:
> 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 [scottfines@gmail.com]
>> Sent: Friday, April 13, 2012 8:15 AM
>> To: user@zookeeper.apache.org
>> Cc: zookeeper-user@hadoop.apache.org; zookeeper-dev@hadoop.apache.org
>> 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<camille@apache.org>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

View raw message