[
https://issues.apache.org/jira/browse/ZOOKEEPER-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15811936#comment-15811936
]
Timothy Ward commented on ZOOKEEPER-2368:
-----------------------------------------
I'm not sure that I agree with this. If the ZooKeeper handle is already
disconnected (e.g. due to a network failure) before it is closed then the
session may not actually be expired when the handle is closed. If the session
timeout is a long one it is perfectly possible that a client could be recreated
and re-attach to the previous session. The one thing that is absolutely
guaranteed on a call to close is that the ZooKeeper handle is disconnected,
hence I proposed using that KeeperState.
> Client watches are not disconnected on close
> --------------------------------------------
>
> Key: ZOOKEEPER-2368
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2368
> Project: ZooKeeper
> Issue Type: Improvement
> Affects Versions: 3.4.0, 3.5.0
> Reporter: Timothy Ward
> Assignee: Timothy Ward
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2368.patch
>
>
> If I have a ZooKeeper client connected to an ensemble then obviously I can
> register watches.
> If the client is disconnected (for example by a failing ensemble member) then
> I get a disconnection event for all of my watches. If, on the other hand, my
> client is closed then I *do not* get a disconnection event. This asymmetry
> makes it really hard to clear up properly when using the asynchronous API, as
> there is no way to "fail" data reads/updates when the client is closed.
> I believe that the correct behaviour should be for all watchers to receive a
> disconnection event when the client is closed. The watchers can then respond
> as appropriate, and can differentiate between a "server disconnect" and a
> "client disconnect" by checking the ZooKeeper#getState() method.
> This would not be a breaking behaviour change as Watchers are already
> required to handle disconnection events.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
