Async watches and their creators

Kapil Thangavelu kapil.thangavelu at canonical.com
Wed Apr 20 13:23:06 UTC 2011


Excerpts from Gustavo Niemeyer's message of Tue Apr 19 16:21:42 -0400 2011:
> > This is bit technical, regarding the ensemble internals.
> 
> Sorry for the delay.  I had a first pass and was thinking about it as
> we discussed, but then forgot to come back.
> 
> (...)
> > The problem arries in that the apis which setup these watches are
> > returning after they have setup the watch, when as result of creating
> > the watch they have pending initialization work outstanding. This
> > leads to some timing issues when dealing with initilization. I've
> > identified this problem in a few places in the codebase.
> >
> >  - ensemble.unit.lifecycle.UnitLifecycle.start
> >
> > At the return of start method, there is still pending activity in the
> > form of the initial the unit relation watch processing occuring in the
> > background.
> 
> One thing that makes the proposal you follow up below not entirely
> clear to me is that this work isn't *really* initialization. 

Perhaps initialization is a bad choice of words, the notion is that the
invoker is trying to setup a watch, and that the watch callback will match 
the current state of system with the invocation only after the initial watch 
execution.

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.

> This is
> going to be persistently monitoring the state of the system and
> reacting to changes by applying the deltas in the system.  This means
> that if those changes happen not in the first call, but in the second
> one, it's totally fine for the system. 

Sure watches are being setup in permanent fashion, and the change can happen 
at any time in the future, for the purpose of the API invoker though, the 
guarantee i'm trying to see introduced is that the behavior being setup
is current with state at the time of invocation before control returns
to the invoker. Future watches continue as normal.

>For that reason, it's not
> clear that having special behavior taking place on the very first call
> is the right thing to do.. will it just make tests easier to write, or
> will it more easily hide bugs since the system can in fact postpone
> such actions?

We've already got some bugs as a result of the current behavior (debug-log 
and debug-hook setup, per my original email). The invokers need some way 
of knowing that the current state has been accounted for, else we're 
introducing arbitrary waits when we need this behavior. 

There's a simple way to arrive at this behavior, which i've proposed, and 
cited several real world examples of where this has been problematic.
I've not heard an alternative yet.

> 
> Not saying it's not a good idea, but it'd be nice to at least talk a
> bit more with higher bandwidth about the issue (a voice call) to make
> sure there's no underlying problem which we'll be hiding with it.
> 

Sounds goood.

Kapil




More information about the Ensemble mailing list