[
https://issues.apache.org/jira/browse/ZOOKEEPER-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191803#comment-13191803
]
Daniel Lord commented on ZOOKEEPER-1309:
----------------------------------------
It looks to me that this issue (and fix) don't apply to branches-3.4 and trunk.
The structure of the zookeeper client seems to have changed a lot in 3.4. For
example the ClientCnxn used to leak file handles because it initialized the
Selector.open() before it attempted to resolve any InetAddresses for the
ensemble. This is no longer the case. If you look at the constructor of
ZooKeeper now the StaticHostProvider constructor is responsible for resolving
the InetAddresses. If any of the addresses are bad then StaticHostProvider
will throw an UnknownHostException and the whole ZooKeeper handle will fall
apart and won't leak any resources.
My original test for this was to connect to a single host named "qwerty" where
"qwerty" does not resolve to a valid host and to watch the file handles grow
very quickly. I can see that in this test there is no file handle leak using
the 3.4 zookeeper client.
Objections on this jira applying only to 3.3.x?
> Creating a new ZooKeeper client can leak file handles
> -----------------------------------------------------
>
> Key: ZOOKEEPER-1309
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1309
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Affects Versions: 3.3.4
> Reporter: Daniel Lord
> Assignee: Daniel Lord
> Priority: Critical
> Fix For: 3.4.3, 3.5.0
>
> Attachments: zk-1309-1.patch, zk-1309-1.patch, zk-1309-1.patch,
> zk-1309-3.patch
>
>
> If there is an IOException thrown by the constructor of ClientCnxn then file
> handles are leaked because of the initialization of the Selector which is
> never closed.
> final Selector selector = Selector.open();
> If there is an abnormal exit from the constructor then the Selector is not
> closed and file handles are leaked. You can easily see this by setting the
> hosts string to garbage ("qwerty", "asdf", etc.) and then try to open a new
> ZooKeeper connection. I've observed the same behavior in production when
> there were DNS issues where the host names of the ensemble can no longer be
> resolved and the application servers quickly run out of handles attempting to
> (re)connect to zookeeper.
--
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
