zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shelley, Ryan" <Ryan.Shel...@disney.com>
Subject Re: session watches
Date Tue, 06 Mar 2012 01:02:25 GMT
The reason I was thinking that it might be useful to know if there are any
watches on a node is for the lack of ephemeral parent nodes. If a node
doesn't have a watch on it, I can assume no one is watching to see if
should be purged when it has no children, so a new watch should be set on
it. I don't, however, want to have multiple watches set on the same node
that all watch when a node has no children. I've experienced some
inconsistencies with that approach as two nodes will be notified that the
children have changed, they both check existence to make sure it's still
there and not already deleted by some other watcher, both get back
successful responses, both delete, one fails. It's an edge case I can
catch and replicate easily, but in reality, it's possible that with this
approach I could have a large number of clients watching the same znode
resulting in lots of overhead across the network when a znode's watch is
fired. If I can check and see that there are X other watches on this node,
I don't need to register another watch, one of the other instances should
hopefully be able to handle the job even if two of the other clients fail.
I'm sure I can make this happen by setting a counter on the znode itself
that I increment when I also watch the znode or they create ephemeral
znodes that represent their associated watch, just seems inefficient and
error prone (in the former case, two clients could try to set this value
at the same time, overwriting each other since I don't have something like
Mongo's atomic increment option - nor am I advocating it).

I can definitely run another service that's sole responsibility is to
clean up empty znodes (an explicit cleaner of persistent nodes acting as
"ephemeral parents"), but in my use case, there could be thousands of
these znodes. I was just concerned about a single point of failure, with
that approach. Of course, I can run a couple of those in parallel all
watching different sets of znodes, it's just added complexity. If I can't
avoid it, I can't, but I'm just trying to exhaust options first.

I'm not advocating changes to the ZK architecture, I'm just poking around
to see what I can and can't do, and how to architect a solution that will
either work in ZK or won't.


On 3/5/12 4:37 PM, "Ted Dunning" <ted.dunning@gmail.com> wrote:

>On Mon, Mar 5, 2012 at 3:59 PM, Shelley, Ryan
><Ryan.Shelley@disney.com>wrote:
>
>> Additionally, I'm curious if there is a way to know if there are any
>> watches currently on a znode. Since we can't do ephemeral parent nodes,
>> yet, and if I have a client that fails (which results in losing their
>> session and watches) - or forcefully shutdown from Eclipse (which is
>>what
>> happens when I'm testing), I'll need to find out which znodes are no
>>longer
>> being watched and reestablish them (possibly by another client).
>>
>
>Can you say more about why this is needed?  Why does it matter if your
>debugged program or some other is watching these nodes?  If you absolutely
>need to have somebody watching these nodes, why not run a program that
>permanently watches these nodes in addition to the program under test.
>
>
>> Another thought was a "named" watch, where a watch can be saved between
>> sessions by having uniquely named clients (I know this isn't currently
>> supported, just thinking out loud). Just trying to figure out how to
>>make
>> due without ephemeral parent nodes.
>>
>
>This can be emulated by keeping a znode with a list of the paths that
>should be watched.  I don't understand how it needs to be a primitive
>capability.


Mime
View raw message