To give some context to this, on the PR Jordan asked about the following scenario:
“”” I want to make sure that once a Persistent Watcher is set the client will not miss events. i.e. T1: set the watch; T2: multiple clients set data on a watched path; T3: our client calls getData. While processing the getData multiple clients call setData on the node. I believe that the server will queue up multiple watch triggers for the client and the client will see them in order after its getData completes. “”” Looking at the code it seems to me that this is not necessarily the case: if getData request takes long enough, watchers are able to put their response in client’s response queue and it’s not guaranteed that client will receive getData response first. Is that correct? Andor > On 2019. Oct 23., at 21:39, Jordan Zimmerman <[email protected]> > wrote: > > The Persistent/Recursive watches (ZOOKEEPER-1416) PR is ready. But, I'm > concerned about an assumption I've made. I worry about event ordering > regarding multiple writes from multiple clients and watchers. Here's my > assumption: > > If you successfully set a Persistent watcher (i.e. you get confirmation via a > synchronous addWatch() completing or the callback to an asynchronous > addWatch) then any future ZooKeeper calls (getData, setData, etc.) have the > same guarantees as any other Watcher. ZOOKEEPER-1416 adds the persistent > watchers to both the dataWatchers and childWatchers managed by DataTree. This > is what all other watchers do. > > So, I believe it's true but we really need some confirmation from someone who > knows those internals better than me. > > -Jordan
