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 Threaded View
Zookeeper >> mail # dev >> Input on a change


Copy link to this message
-
Re: Input on a change
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
>>
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