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

Raul Gutierrez Segales commented on ZOOKEEPER-1909:
---------------------------------------------------

bq. I hope this is a kind of notification is "in flight", say just before 
submitting the call to server, client recieves the watch notification. Now 
otherside server will not be able to see the watch anymore. isn't it ?

That's one possibility, yes.

bq. In client side, we have two phase validation (1)before submitting the call 
to server and (2)after recieving the response from server. Also we know in 
server side it will ensure orderly exec. (2)After recieving the success 
response from server, again client will be checking whether I can remove the 
requested watcher. If yes, it continues with 'WatchRemoval' notification 
otherwise it throws 'NoWatcherException' to the user. 

Yeah that is fine as well, but even if a client-side impl doesn't do that - the 
server should do the check.

bq. Also, could you please tell me whether you have observed this case in tests 
?

Oh, not in the Java tests - just when I was implementing this in Kazoo. 

> removeWatches doesn't return NOWATCHER when there is no watch set
> -----------------------------------------------------------------
>
>                 Key: ZOOKEEPER-1909
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1909
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 3.5.0
>            Reporter: Raul Gutierrez Segales
>             Fix For: 3.5.0
>
>         Attachments: ZOOKEEPER-1909.patch
>
>
> ZOOKEEPER-442 introduced support for a new opcode: removeWatches. The way it 
> was implemented though, implies that you need to check on the client side if 
> a watch/watcher is set *before* you send your request to the server. If you 
> don't, ZK will just swallow your request and won't return an error code if 
> there isn't a watch set for that path.
> I noticed this whilst implementing removeWatches for Kazoo [1]. As mentioned, 
> I guess it could be expected that clients should do the check on their side 
> but I think that the correct thing would to have the server do the validation 
> and return the error code accordingly as well.
> [~rakeshr], [~phunt]: thoughts?
> [1] 
> https://github.com/rgs1/kazoo/commit/44ca48e975aeea3fd0664fe13136a72caf89e54f



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to