[
https://issues.apache.org/jira/browse/ZOOKEEPER-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182987#comment-13182987
]
Patrick Hunt commented on ZOOKEEPER-126:
----------------------------------------
Oliver - a system property would be less invasive. However there is then the
issue of supporting backward compatibility. (3.3.5 to 3.4 to 3.5/...)
It seems to me that we need to address the underlying cause of the problem
otherwise unexpected/bad behavior might happen that we don't handle. Say the
SendThread exited case, if the EventThread is still running it's likely that
we'll start leaking threads. Shouldn't we fix the root issue rather than
papering over it?
> zookeeper client close operation may block indefinitely
> -------------------------------------------------------
>
> Key: ZOOKEEPER-126
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-126
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Reporter: Patrick Hunt
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-126.patch, ZOOKEEPER-126.patch
>
>
> Moving the hang issue from ZOOKEEPER-63 to here. See 63 for background and
> potential patch (patch_ZOOKEEPER-63.patch).
> specifically (from James):
> "I'm thinking the close() method should not wait() forever on the disconnect
> packet, just a closeTimeout length - say a few seconds. Afterall blocking and
> forcing a reconnect just to redeliver the disconnect packet seems a bit silly
> - when the server has to deal with clients which just have their sockets fail
> anyway"
--
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
