[
https://issues.apache.org/jira/browse/ZOOKEEPER-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373274#comment-15373274
]
Jordan Zimmerman commented on ZOOKEEPER-2368:
---------------------------------------------
When I get a change I can run Curator's tests on this. Or maybe Timothy can do
that. For Curator, it already handles shutdown internally for all of its
recipes (assuming correct usage). My only concern is that the Disconnect event
would occur out-of-band from the ZooKeeper closure (i.e. a different thread at
a different point in time).
> 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
> Fix For: 3.5.2
>
> 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)
