ZOOKEEPER-4466: Support different watch modes on same path#1859
Conversation
eolivelli
left a comment
There was a problem hiding this comment.
This is a great work
@lvfangmin @Randgalt @breed please take a look carefully.
I am afraid that we could inadvertently change the semantics of watchers
|
We need more eyes on this patch |
1722faa to
c8557af
Compare
c8557af to
4bdd355
Compare
Currently, in server side, there is only one watcher mode per path. This will destroy and corrupt old watch when client watch a watching path.
4bdd355 to
b65852e
Compare
|
Could you please take a look at this ? @tisonkun @eolivelli @Randgalt @symat @maoling @arshadmohammad @anmolnar @ztzg @lvfangmin @breed |
eolivelli
left a comment
There was a problem hiding this comment.
+1
Unfortunately we need more eyes on this patch.
Signed-off-by: tison <wander4096@gmail.com>
| } | ||
| } | ||
| return false; | ||
| Set<Watcher> list = watchTable.get(path); |
There was a problem hiding this comment.
@kezhuw Can you explain a bit why this change is correct?
It seems that previously, containsWatcher (path, watcher) will be true if any parent of the path has a persistent recursive watch.
There was a problem hiding this comment.
It seems that previously, containsWatcher (path, watcher) will be true if any parent of the path has a persistent recursive watch.
It is no true though it might intend to do so. Two cases for old code:
- If there is a watch for (watcher, path), the first
return truewill hold. - If there is no watch for (watcher, path),
watcherModewill beWatcherMode.STANDARD, noreturn truewill hold:- First
return truewill not hold as it only apply for leaf node where there is no such watch. - Second
return truewill not hold asWatcherMode.STANDARDis no recursive.
- First
So my change has same behavior as old code and also same to when it was introduced. I think this behavior meets what OpCode.checkWatches expects which is the sole client visible call to this method. Disregard cheating behaviour of ZooKeeper.removeWatches, removing sub nodes from recursive watching sounds quirk as similar one I saw in ZOOKEEPER-4471.
There was a problem hiding this comment.
Thanks for your explanation! I get it now :)
tisonkun
left a comment
There was a problem hiding this comment.
The rest looks good to me. One comment above.
Signed-off-by: tison <wander4096@gmail.com>
| } | ||
| } | ||
| return false; | ||
| Set<Watcher> list = watchTable.get(path); |
There was a problem hiding this comment.
Thanks for your explanation! I get it now :)
|
Cc @Randgalt @lvfangmin @breed if you can take a look also. |
…st-with-same-path
|
Shall we merge this ? Or we need more eyeballs on this? @eolivelli @tisonkun @Randgalt @lvfangmin @breed @cnauroth @symat @maoling I guess lazy consensus could apply here if no more comments. |
|
Merging... Thanks for your contribution @kezhuw! |
PR apache#1950(ZOOKEEPER-4655) was created before apache#1859(ZOOKEEPER-4466) merged. It changes `assertEvent`'s signature which is depended by apache#1859.
…2012) PR #1950(ZOOKEEPER-4655) was created before #1859(ZOOKEEPER-4466) merged. It changes `assertEvent`'s signature which is depended by #1859.
PR #1950(ZOOKEEPER-4655) was created before #1859(ZOOKEEPER-4466) merged. It changes `assertEvent`'s signature which is depended by #1859.
Signed-off-by: Kezhu Wang <kezhuw@gmail.com> Co-authored-by: tison <wander4096@gmail.com>
…) (#49) Signed-off-by: Kezhu Wang <kezhuw@gmail.com> Co-authored-by: Kezhu Wang <kezhuw@gmail.com> Co-authored-by: tison <wander4096@gmail.com>
PR apache#1950(ZOOKEEPER-4655) was created before apache#1859(ZOOKEEPER-4466) merged. It changes `assertEvent`'s signature which is depended by apache#1859.
PR apache#1950(ZOOKEEPER-4655) was created before apache#1859(ZOOKEEPER-4466) merged. It changes `assertEvent`'s signature which is depended by apache#1859. Co-authored-by: Kezhu Wang <kezhuw@gmail.com>
PR apache#1950(ZOOKEEPER-4655) was created before apache#1859(ZOOKEEPER-4466) merged. It changes `assertEvent`'s signature which is depended by apache#1859.
Currently, in server side, there is only one watcher mode per path. This
will destroy and corrupt old watch when client watch a watching path.