答复: [jira] [Created] (ZOOKEEPER-3706) ZooKeeper.close() would leak SendThread when the network is broken

[殷芳玺 <yi...@kuaishou.com>]

Hi, folks:


The pr is in


https://github.com/apache/zookeeper/pull/1235


Welcome any comments.


Thanks


Pierre Yin

________________________________
发件人: Pierre Yin (Jira) <ji...@apache.org>
发送时间: 2020年1月25日 下午 4:29:00
收件人: dev@zookeeper.apache.org
主题: [jira] [Created] (ZOOKEEPER-3706) ZooKeeper.close() would leak SendThread when the network is broken

Pierre Yin created ZOOKEEPER-3706:
-------------------------------------

             Summary: 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.5.6, 3.4.14, 3.6.0
            Reporter: Pierre Yin


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)