[
https://issues.apache.org/jira/browse/HBASE-12376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14188986#comment-14188986
]
Sean Busbey commented on HBASE-12376:
-------------------------------------
{quote}
So, you say RuntimeException in case an unexpected Exception (OOME or
something?). The stop does pretty good job at catching all other crap. This a
style you think we should institute throughout?
{quote}
Yeah, something like that. It's a general code hygiene thing to guard against
exceptions in finally blocks because of how it hides root causes. I'd be in
favor of fixing it where we can.
{code}
+ try {
+ ct.stop();
+ } catch (RuntimeException re) {
+ LOG.error("In cleanup", re);
+ }
{code}
Since this is client side code, something with a stronger statement of action
maybe something like:
{code}
LOG.error("Failed to clean up HBase's internal catalog tracker after a failed
initialization. " +
"We may have leaked network connections to ZooKeeper; they won't be
cleaned up until " +
"the JVM exits. If you see a large number of stale connections to
ZooKeeper this is likely " +
"the cause. The following exception details will be needed for assistance
from the " +
"HBase community.", re);
{code}
Actually now that I'm reading it, that's a bit long. :) Maybe an additional
section for the ref guide section on troubleshooting related to ZooKeeper
(currently 15.11) and then a link to it in the log message?
Otherwise, +1 LGTM (I'm presuming you'll squash before pushing)
> HBaseAdmin leaks ZK connections if failure starting watchers
> (ConnectionLossException)
> --------------------------------------------------------------------------------------
>
> Key: HBASE-12376
> URL: https://issues.apache.org/jira/browse/HBASE-12376
> Project: HBase
> Issue Type: Bug
> Components: Zookeeper
> Affects Versions: 0.98.7, 0.94.24
> Reporter: stack
> Assignee: stack
> Priority: Critical
> Attachments:
> 0001-12376-HBaseAdmin-leaks-ZK-connections-if-failure-sta.patch,
> 0001-12376-HBaseAdmin-leaks-ZK-connections-if-failure-sta.version2.patch
>
>
> This is a 0.98 issue that some users have been running into mostly running
> Canary and for whatever reason, setup of zk connection fails, usually with a
> ConnectionLossException. End result is ugly leak zk connections. ZKWatcher
> created instances are just left hang out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
