[
https://issues.apache.org/jira/browse/ZOOKEEPER-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253568#comment-13253568
]
Henry Robinson commented on ZOOKEEPER-1442:
-------------------------------------------
The current method of logging the error seems problematic - if the exception
really is OOME then the string passed to LOG will perhaps fail to be allocated
(since it can't be interned because of the concatenation).
It doesn't seem correct to exit on ThreadDeath either, by a cursory reading of
the documentation.
The advice on java.lang.error appears to be that we should not be trying to
catch it at all. That said, I'm not against failing fast because I've seen java
server processes go OOM and then just keep ticking along like a zombie, causing
strange bugs when some operations appear to take effect and some don't.
> Uncaught exception handler should exit on a java.lang.Error
> -----------------------------------------------------------
>
> Key: ZOOKEEPER-1442
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1442
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client, server
> Affects Versions: 3.4.3, 3.3.5
> Reporter: Jeremy Stribling
> Assignee: Jeremy Stribling
> Priority: Minor
> Attachments: ZOOKEEPER-1442.patch
>
>
> The uncaught exception handler registered in NIOServerCnxnFactory and
> ClientCnxn simply logs exceptions and lets the rest of ZooKeeper go on its
> merry way. However, errors such as OutOfMemoryErrors should really crash the
> program, as they represent unrecoverable errors. If the exception that gets
> to the uncaught exception handler is an instanceof a java.lang.Error, ZK
> should exit with an error code (in addition to logging the error).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
