But the implication is still the same. After each item processing, getChildren() will get called. This is seems incredibly inefficient to me. Further, the next item must wait until the getChildren() returns.
Imagine a system that is putting hundreds (1000s?) of items in this queue. You're going to get an ugly stampede. For each Zk client processing the queue, you will require n (number of messages) trips to getChildren(). -JZ On 7/14/11 5:40 PM, "Ted Dunning" <[email protected]> wrote: >Right. So you will have to get the children (and set a new watch) and >then >do a set subtraction to see if the difference is just the item you >deleted. > If so, you don't need to reset. Likewise, if something else was deleted >that is still in your future, you can just delete it from the list of >upcoming items and continue. > >On Thu, Jul 14, 2011 at 5:31 PM, Jordan Zimmerman ><[email protected]>wrote: > >> I won't get a delete event. I'll get a NodeChildrenChanged on the parent >> path. >> >> -JZ >> >> On 7/14/11 5:28 PM, "Ted Dunning" <[email protected]> wrote: >> >> >Since you can see what the event is, can you test it to see if is the >> >delete >> >that was just issued? >> > >> >On Thu, Jul 14, 2011 at 5:24 PM, Jordan Zimmerman >> ><[email protected]>wrote: >> > >> >> Is there a way to tell ZooKeeper not to fire a watch to the same >>session >> >> that caused the event? Or, is there a way to tell which session >>caused >> >>the >> >> event to fire? Without this, it's not really possible to write a >>useful >> >> Priority Queue. >> >>
