Home | About | Sematext search-lucene.com search-hadoop.com
 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
Copy link to this message
-
RE: Input on a change
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.

--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
>
+
Jeremy Stribling 2012-04-13, 21:25
+
Michi Mutsuzaki 2012-04-13, 21:31
+
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