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