I have found out what was causing the problem and, unsurprisingly, the bug was on our side. Thank you for your help.
On Wed, Aug 26, 2015 at 1:35 PM, Flavio Junqueira < [email protected]> wrote: > Hi Robert, > > If it is the same client that created the znode, then yes, it does read > its own writes. A different client may not read it immediately because we > propagate updates agreed upon to the replicas asynchronously. You could > watch the parents for changes, though, and have the client being notified > when the newly created child becomes visible for that client. > > -Flavio > > > On 26 Aug 2015, at 11:08, Robert Rosolek <[email protected]> > wrote: > > > > To clarify more: in my program no-one is deleting this node in the > > meantime. Also the state of the zookeeper session is Connected all the > time. > > > > On Wed, Aug 26, 2015 at 10:03 AM, Robert Rosolek < > [email protected]> > > wrote: > > > >> Hi, > >> > >> Sorry if this question was asked here before, but I couldn't find the > >> search functionality in the archives. > >> > >> My question is the following: after create operation is successful, am I > >> guaranteed to > >> see the new child when doing get_children on the parent? I have a > program, > >> that seems to be breaking because it makes this assumption. Looking at > the > >> lock recipe at > >> > https://github.com/apache/zookeeper/blob/trunk/src/recipes/lock/src/java/org/apache/zookeeper/recipes/lock/WriteLock.java > , > >> it seems this code does *not* make this assumption and simply keeps > >> retrying in a tight loop until it finds the child. > >> > >> Thank you, > >> Robert > >> > >
