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

Hudson commented on ZOOKEEPER-2368:
-----------------------------------

FAILURE: Integrated in Jenkins build ZooKeeper-trunk #68 (See 
[https://builds.apache.org/job/ZooKeeper-trunk/68/])
[ZOOKEEPER-2368] Send a watch event is when a client is closed (andor: rev 
2a951868bda3b7343069f9155f6404c3d9d5aa8e)
* (edit) src/java/main/org/apache/zookeeper/Watcher.java
* (edit) src/java/test/org/apache/zookeeper/test/WatcherTest.java
* (edit) src/java/main/org/apache/zookeeper/ClientCnxn.java


> 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
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 3.6.0, 3.5.5
>
>         Attachments: ZOOKEEPER-2368.patch
>
>          Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> 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
(v7.6.3#76005)

Reply via email to