Usually the paradigm I like to suggest is to have something like
Every client watches for the existence of this node and this node is only
created after /A has been initialized with the creation of /A/C or other
Would that work for you?
On 8/23/10 7:34 AM, "Gustavo Niemeyer" <gust...@niemeyer.net> wrote:
> We (a development team at Canonical) are stumbling into a situation
> here which I'd be curious to understand what is the general practice,
> since I'm sure this is somewhat of a common issue.
> It's quite easy to describe it: say there's a parent node A somewhere
> in the tree. That node was created dynamically over the course of
> running the system, because it's associated with some resource which
> has its own life-span. Now, under this node we put some control nodes
> for different reasons (say, A/B), and we also want to track some
> information which is related to a sequence of nodes (say, A/C/D-0,
> A/C/D-1, etc).
> So, we end up with something like this:
> The question here is about best-practices for taking care of nodes
> like A/C. It'd be fantastic to be able to create A's structure
> together with A itself, otherwise we risk getting in a situation where
> a client can see the node A before its "initialization" has been
> finished (A/C doesn't exist yet). In fact, A/C may never exist, since
> it is possible for a client to die between the creation of A and C.
> Anyway, I'm sure you all understand the problem. The question here
> is: this is pretty common, and quite boring to deal with properly on
> every single client. Is there any feature in the roadmap to deal with
> this, and any common practice besides the obvious "check for
> half-initialization and wait for A/C to be created or deal with
> timeouts and whatnot" on every client?
> I'm about to start writing another layer on top of Zookeeper's API, so
> it'd be great to have some additional insight into this issue.
> Gustavo Niemeyer