[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191542#comment-13191542
 ] 

Patrick Hunt commented on ZOOKEEPER-1309:
-----------------------------------------

Looks like trunk (auto patch testing only tests against trunk) is different 
enough from 3.3 that your now properly formatted patch is not applying due to 
conflicts. Typically what we do is create patches for each branch in this case 
- say we should include this in 3.3/3.4/3.5 you might need to create a separate 
patch for 3.4/3.5 than 3.3 (in some cases we end up with 3 patches). Also, we 
typically name the patches ZOOKEEPER-####.patch (ZOOKEEPER-####_br34.patch, 
etc...), jira handles uploading new versions with the same name properly. Also 
- qa bot always uses the most recent patch. So you need to upload 3.3/3.4 
before 3.5 patch if you want to patch to be auto-tested correctly. (sorry about 
that but it's pretty bare bones and that's how it currently works).
                
> 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

        

Reply via email to