zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shelley, Ryan" <Ryan.Shel...@disney.com>
Subject Re: Input on a change
Date Fri, 13 Apr 2012 22:00:58 GMT
System.exit(int) is developer specific. Traditionally, it should be
non-zero for abnormal operation (so really it should be System.exit(-1)).

Maybe it could just be parameterized entirely. Apply the
UncaughtExceptionHandler only if the option is enabled.

--failfast=true/false (defaults to false, until a future major release)

Ryan

On 4/13/12 2:38 PM, "Michi Mutsuzaki" <michi@cs.stanford.edu> wrote:

>By the way, grepping the source code, I see we use various exit codes.
>Does anybody know what they all mean?
>
>--Michi
>
>On Fri, Apr 13, 2012 at 2:31 PM, Michi Mutsuzaki <michi@cs.stanford.edu>
>wrote:
>> Ah I see. I guess log and System.exit(1) is the best we can do then.
>>
>> --Michi
>>
>> 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.UncaughtExcept
>>>ionHandler.html#uncaughtException%28java.lang.Thread,%20java.lang.Throwa
>>>ble%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
>>>>>
>>>


Mime
View raw message