[
https://issues.apache.org/jira/browse/ZOOKEEPER-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942793#comment-16942793
]
Andor Molnar commented on ZOOKEEPER-3566:
-----------------------------------------
[~snelson21]
[~tison] 's point is valid, but I think the main issue here is something else.
This has been raised on the mailing lists multiple times so far and key takeway
is that ZooKeeper is not a messaging system. It's not guaranteed that client
will receive all events and this is by design. Order of events is another
aspect.
In your example when you receive change event, you have to re-attach your
watcher by reading the znode for instance. If the delete happens between these
2 actions, you won't get the notification about the delete. This is by design.
Do you still need this feature?
> Send event zxid to watches
> --------------------------
>
> Key: ZOOKEEPER-3566
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3566
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Reporter: Samuel Nelson
> Priority: Major
>
> The zxid that triggered a watch should be sent to the watch because it's
> useful for ordering events.
>
> Use case:
> I'm watching a znode and syncing its contents (and whether it has been
> deleted) to a third system. Without zxid attached to events it makes it very
> difficult to maintain the order of events as they happened in ZK.
>
> For example if I modify node `/a/b/c` and then delete it soon after, we have
> two watch events, but no reliable way to communicate to our third system that
> the modification happened before the deletion. If we are given the zxid we
> can use that to order events.
>
> Suggested implementation:
> Change `IWatchManager#triggerWatch` to take another parameter `Long zxid`.
> Callers pass the zxid of the event.
> Add member `Long zxid` to `WatchedEvent`
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
