Hi Todd - The general explanation for why Zookeeper doesn't pass the event information w/ the event notification is that an event notification is only triggered once, and thus may indicate multiple events. For example, if you do a GetChildren and set a watch, then multiple children are added at about the same time, the first one triggers a notification, but the second (or later) ones do not. When you do another GetChildren() request to get the list and reset the watch, you'll see all the changed nodes, however if you had just been told about the first change in the notification you would have missed the others. To do what you are wanting, you would really need "persistent" watches that send notifications every time a change occurs and don't need to be reset so you can't miss events. That isn't the design that was chosen for Zookeeper and I don't think it's likely to be implemented.
-Dave Wright On Tue, Aug 31, 2010 at 3:49 AM, Todd Nine <t...@spidertracks.co.nz> wrote: > Hi all, > I'm writing a distributed queue monitoring class for our leader node in > the cluster. We're queueing messages per input hardware device, this queue > is then assigned to a node with the least load in our cluster. To do this, > I maintain 2 Persistent Znode with the following format. > > data queue > > /dataqueue/devices/<unit id>/<data packet> > > processing follower > > /dataqueue/nodes/<node name>/<unit id> > > The queue monitor watches for changes on the path of /dataqueue/devices. > When the first packet from a unit is received, the queue writer will > create > the queue with the unit id. This triggers the watch event on the > monitoring > class, which in turn creates the znode for the path with the least loaded > node. This path is watched for child node creation and the node creates a > queue consumer to consume messages from the new queue. > > > Our list of queues can become quite large, and I would prefer not to > maintain a list of queues I have assigned then perform a delta when the > event fires to determine which queues are new and caused the watch event. I > can't really use sequenced nodes and keep track of my last read position, > because I don't want to iterate over the list of queues to determine which > sequenced node belongs to the current unit id (it would require full > iteration, which really doesn't save me any reads). Is it possible to > create a watch to return the path and Stat of the child node that caused > the > event to fire? > > Thanks, > Todd >
