[
https://issues.apache.org/jira/browse/ZOOKEEPER-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated ZOOKEEPER-3706:
--------------------------------------
Labels: pull-request-available (was: )
> ZooKeeper.close() would leak SendThread when the network is broken
> ------------------------------------------------------------------
>
> Key: ZOOKEEPER-3706
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3706
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Affects Versions: 3.6.0, 3.4.14, 3.5.6
> Reporter: Pierre Yin
> Priority: Major
> Labels: pull-request-available
>
> The close method of ZooKeeper may cause the leak of SendThread when the
> network is broken.
> When the network is broken, the SendThread of ZooKeeper client falls into the
> continuous reconnecting scenario. But there is an unsafe point which is just
> at the moment before startConnect() during the continuous reconnecting. If
> SendThread.close() in another thread hit the unsafe point, startConnect()
> would sleep some time and force to change state to States.CONNECTING although
> SendThread.close() already set state to States.CLOSED. In this case, the
> SendThread would be never be dead and nobody would change the state again.
> In normal case, ZooKeeper.close() would be blocked forever to wait
> closeSession packet is finished until the network broken is recovered. But if
> user set the request timeout, ZooKeeper.close() would break the block waiting
> within timeout and invoke SendThread.close() to change state to CLOSED.
> That's why SendThread.close() can hit the unsafe point.
> Set request timeout is a very common practice.
> I propose a patch and send it out later.
> Maybe someone can help to review it.
>
> Thanks
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
