[
https://issues.apache.org/jira/browse/HBASE-12376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14188918#comment-14188918
]
Sean Busbey commented on HBASE-12376:
-------------------------------------
{code}
+ } finally {
+ // If we did not succeed but created a catalogtracker, clean it up. CT
has a ZK instance
+ // in it and we'll leak if we don't do the 'stop'.
+ if (!succeeded && ct != null) {
+ ct.stop();
+ ct = null;
+ }
{code}
Wrap the ct.stop() call in a try/catch(RuntimeException) that logs a warning.
Otherwise, if we end up in the finally block because of an exception
(RuntimeException, ZooKeeperConnectionException, or IOException) and it should
throw we'll overrun the original exception.
{code}
+ /**
+ * For testing so can intercept the catalog tracker start.
+ * @param c
+ * @return Instance of CatalogTracker or exceptions if we fail
+ * @throws IOException
+ * @throws InterruptedException
+ */
{code}
leave out the boilerplate javadoc param and throws.
{code}
+ @VisibleForTesting
+ protected CatalogTracker startCatalogTracker(final CatalogTracker ct)
+ throws IOException, InterruptedException {
{code}
nit: this can be package-private and still be used in the test it's currently
used in.
{code}
+ CatalogTracker ct = doctoredAdmin.getCatalogTracker();
+ assertFalse(ct.isStopped());
+ ct.stop();
+ assertTrue(ct.isStopped());
{code}
use {{doctoredAdmin.cleanupCatalogTracker(ct)}} instead of {{ct.stop()}} since
that's what the javadoc for getCatalogTracker says to do.
> 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
>
>
> 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)
