You may want to consider adding a distributed queue to your use of ZK. As was mentioned previously, watches don't notify you of every change, just that a change was made. For example multiple changes may be "visible" when you get the notification.

A distributed queue would allow you to "log" every change, and have your "watcher" process easily process the result. The only issue I could see is one of atomicity, but depending on your use case(s) that may not be an issue, or perhaps one that can be worked around.


On 08/02/2010 09:18 AM, Ted Dunning wrote:
Another option besides Steve's excellent one would be to keep something like
1000 nodes in your list per znode.  Many update patterns will give you the
same number of updates, but the ZK transactions that result (getChildren,
read znode) will likely be more efficient, especially the getChildren call.

Remember, it is not a requirement that you have a one-to-one mapping between
your in-memory objects and in-zookeeper znodes.  If that works, fine.  If
not, feel free to be creative.

On Mon, Aug 2, 2010 at 7:45 AM, Steve Gury

Is there any recipe that would provide this feature (or a work around) ?

Reply via email to