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
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
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