Async watches and their creators

Kapil Thangavelu kapil.thangavelu at
Wed Apr 20 14:41:01 UTC 2011

Excerpts from Gustavo Niemeyer's message of Wed Apr 20 09:26:39 -0400 2011:
> > The invoker is trying to sync state to behavior, if the sync isn't complete
> > when control is returned by the invoker, it has no way of proceeding easily
> > based on the current state if it depends on the async behavior.
> Yes, the problem as I tried to explain yesterday online, though, is
> that this is an unrealistic assumption.
> Simple example where your proposal *would* work:
> A) Class A sets up state in ZK
> B) Class B sets up watch on node N, doesn't fire deferred
> C) Class B gets first state set by A, fires deferred
> At the end, we got the state fully synchronized, as you were wishing for.
> Now, let's invert things.
> B) Class B sets up watch on node N, doesn't fire deferred
> C) Class B gets first state set by A, fires deferred
> A) Class A sets up state in ZK
> Now, the state is *not* fully synchronized, because B will fire a watch
> again to process the changes done by A.  The only thing I did was to
> reorder calls in the source code.
> I'm concerned about getting into rabbit hole where we have to call
> things in the proper order by understanding how the internals work
> so tests can pass.

So from my original email

 The other common aspect of these watch apis, is that they will fire
 initially (and immediately) based on the current state of zookeeper.

These aren't straight zookeeper watches, their the watch apis we 
construct. Which as a common theme have always fired initially 
reflecting the current  state, their not waiting on a change to fire 
initially. So there is no  'doesn't fire deferred' as part of any of 
the steps above. 

The watches are permanent, so even in the inversion there's a D) where
the watch fires again, but that doesn't matter at all to the original 
ivoker, its already moved on after B) in both cases, because the
original api that set the zk watch, has completed after its first
callback invocation not of the zookeeper watch, but the callback
invocation by the ensemble watch api that setup the zk watch. ie.
the first watch invocation for units assigned to a machine, or related
services of a unit, happens based on the current state not the zk
watch firing.

I think your trying to get at a larger issue of the commutability of 
this watch callback with the invoker. But the intended usage doesn't 
care about commutability either, its a temporal sync/coordination point. 

Take the debug-log/debug-hook examples here, the usage by the their 
invoker, the unit agent, is pretty generic, what the 
invoker wants though is a notion that the apis invoked are consistent 
with the current shared state when their invocation is done. It doesn't
care what that state is or whether the watches ever fires. 



More information about the Ensemble mailing list