Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Zookeeper >> mail # dev >> Input on a change


+
Camille Fournier 2012-04-13, 15:09
+
Scott Fines 2012-04-13, 15:15
+
Michi Mutsuzaki 2012-04-13, 20:19
+
Jeremy Stribling 2012-04-13, 21:25
Copy link to this message
-
Re: Input on a change
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
>>>
>
+
Michi Mutsuzaki 2012-04-13, 21:38
+
Camille Fournier 2012-04-15, 18:28
+
Ishaaq Chandy 2012-04-16, 03:20
+
Camille Fournier 2012-04-16, 12:55
+
Ishaaq Chandy 2012-04-16, 16:52
+
Camille Fournier 2012-04-16, 17:13
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB