zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jzimmer...@netflix.com>
Subject Re: Priority Queue?
Date Fri, 15 Jul 2011 00:46:43 GMT
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" <ted.dunning@gmail.com> 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
><jzimmerman@netflix.com>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" <ted.dunning@gmail.com> 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
>> ><jzimmerman@netflix.com>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.
>>
>>


Mime
View raw message