[jira] [Commented] (ZOOKEEPER-2368) Client watches are not disconnected on close

["Patrick Hunt (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474907#comment-15474907 ] 

Patrick Hunt commented on ZOOKEEPER-2368:
-----------------------------------------

bq. This would not be a breaking behaviour change as Watchers are already required to handle disconnection events.

while this _should_ be the case I suspect a change such as proposed here would result in breaking a number of clients... I can't prove it of course but the likelihood to me seems very high.

> 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)