[
https://issues.apache.org/jira/browse/ZOOKEEPER-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100677#comment-13100677
]
Camille Fournier commented on ZOOKEEPER-1174:
---------------------------------------------
--The documentation for sock.connect is exactly what I base my (current)
position on. The idea is that if connect returns true, then you don't need to
use select to wait for the connection and can proceed immediately with the
primeConnection and light up the connection for prime time. It is only if
connect returns false that deferred actions are required.--
But where are you setting sockKey then? You're not setting it at all if it
returns true immediately on the first time this is called.
> FD leak when network unreachable
> --------------------------------
>
> Key: ZOOKEEPER-1174
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1174
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Affects Versions: 3.3.3
> Reporter: Ted Dunning
> Assignee: Ted Dunning
> Priority: Critical
> Fix For: 3.3.4
>
> Attachments: ZOOKEEPER-1174.patch, zk-fd-leak.tgz
>
>
> In the socket connection logic there are several errors that result in bad
> behavior. The basic problem is that a socket is registered with a selector
> unconditionally when there are nuances that should be dealt with. First, the
> socket may connect immediately. Secondly, the connect may throw an
> exception. In either of these two cases, I don't think that the socket
> should be registered.
> I will attach a test case that demonstrates the problem. I have been unable
> to create a unit test that exhibits the problem because I would have to mock
> the low level socket libraries to do so. It would still be good to do so if
> somebody can figure out a good way.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
