Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper, mail # dev - Input on a change


Copy link to this message
-
Re: Input on a change
Michi Mutsuzaki 2012-04-13, 21:38
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [[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
>>>>
>>