hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satish <cthd2...@gmail.com>
Subject Re: zookeeper.getChildren asynchronous callback
Date Sat, 13 Jun 2009 01:09:20 GMT
I guess I was talking about removing the trigger.  Personally I don't  
think there's a need to bend over backwards to remove "in-flight"  
notifications! :)

Satish

On Jun 12, 2009, at 9:59 AM, Patrick Hunt <phunt@apache.org> wrote:

> We probably want to allow the caller to specify which type of watch  
> they want to remove - a watch on the znode itself, on children of  
> the znode, or both.
>
> zk.removeWatch(path, watcher, wtype)
> where:
> path is path to the znode
> watcher may be a specific watcher or null matching all watchers
> wtype is enum of TYPE_CHILD, TYPE_DATA, or TYPE_ALL (something like  
> that)
>
> We also need to be careful of the semantics since "watch" wraps up a  
> couple of concepts: the trigger and the notification. What are we  
> removing? The trigger or both? If just the trigger then you may  
> still be notified after removeWatch is called (if notification is  
> "in flight"). Perhaps removal of the watch should itself trigger the  
> notification to all watchers, with a new notification type of "watch  
> removed"?
>
> Patrick
>
> Satish Bhatti wrote:
>> Actually I guess that would be zookeeper.removeWatch( rootPath,  
>> tempWatcher
>> ) !!
>> On Thu, Jun 11, 2009 at 10:14 AM, Satish Bhatti  
>> <cthd2001@gmail.com> wrote:
>>> That's right Ben.  Basically, I would like to use it something  
>>> like this:
>>> public boolean waitForChildrenChanged( String rootPath,
>>>                                                           long  
>>> timeout )
>>> {
>>>    BooleanLock blChildrenChanged = new BooleanLock();
>>>
>>>    Watcher tempWatcher =
>>>        new Watcher()
>>>        {
>>>            public void process( WatchedEvent event )
>>>            {
>>>                logger.debug( "waitForAnyEntry(): Got state event:  
>>> " +
>>> ZooKeeperUtils.watchedEventToString( event ) );
>>>                blChildrenChanged.setValue( true );
>>>            }
>>>        };
>>>
>>>    zookeeper.getChildren( rootPath, watcher,
>>>
>>>        new AsyncCallback.ChildrenCallback()
>>>        {
>>>            public void processResult( int rc, String path, Object  
>>> ctx,
>>> List<String> children )
>>>            {
>>>                logger.debug( "waitForChildrenChanged():
>>> AsyncCallback.ChildrenCallback(): " + rc + ", " + path + ", " +  
>>> ctx + ", " +
>>> children );
>>>            }
>>>        }, null );
>>>
>>>    blChildrenChanged.waitUntilTrue( timeout );
>>>
>>>    zookeeper.removeWatch( tempWatcher );
>>>
>>>    return blChildrenChanged.isTrue();
>>> }
>>>
>>> The only piece missing from the API is the   zookeeper.removeWatch(
>>> tempWatcher );
>>>
>>> Satish
>>>
>>>
>>> On Thu, Jun 11, 2009 at 7:09 AM, Benjamin Reed <breed@yahoo- 
>>> inc.com>wrote:
>>>
>>>> just to clarify i believe you are talking about callbacks on the  
>>>> watch
>>>> object you are passing in the asynchronous call rather than the  
>>>> asynchronous
>>>> completion callback. (Henry is making the same assumption.) when  
>>>> you say you
>>>> are getting the callback 10 times, i believe your are talking  
>>>> about 10
>>>> different watch objects getting called back once each. right?
>>>>
>>>> it turns out that the zookeeper client does know what you are  
>>>> watching,
>>>> and the zookeeper server will only register one watch. the thing  
>>>> that is
>>>> missing is the clearWatches call that Henry refers to. the thing  
>>>> that
>>>> complicates things a bit, perhaps not for you, is the scenario  
>>>> where we have
>>>> different modules sharing the same zookeeper handle. if different  
>>>> modules
>>>> are interested in watching the same object, you don't want one  
>>>> module to
>>>> simply clear a the watches for a path because one module may mess  
>>>> up the
>>>> other.
>>>>
>>>> we have talked about adding this ability to clear watches for a  
>>>> while. i
>>>> think the auto-watch reregistration patch made the issue slightly  
>>>> more
>>>> pressing since it means that watches can survive for the entire  
>>>> lifetime of
>>>> a session not just for the duration of a connection to a specific  
>>>> server.
>>>> i've created ZOOKEEPER-442 to track this issue.
>>>>
>>>> ben
>>>>
>>>>
>>>> Henry Robinson wrote:
>>>>
>>>>> Hi Satish -
>>>>>
>>>>> As you've found out, you can set multiple identical watches per  
>>>>> znode -
>>>>> the
>>>>> zookeeper client will not detect identical watches in case you  
>>>>> really
>>>>> meant
>>>>> to call them several times. There's no way currently, as far as  
>>>>> I know,
>>>>> to
>>>>> clear the watches once they've been set. So your options are  
>>>>> either to
>>>>> avoid
>>>>> repeatedly setting them by detecting whether getChildren is a  
>>>>> repeat
>>>>> call,
>>>>> or by dealing with multiple invocations on the callback path and  
>>>>> not
>>>>> doing
>>>>> anything once you've established you're no longer interested.
>>>>>
>>>>> It might well make sense to add a clearWatches(path) call to the  
>>>>> API,
>>>>> which
>>>>> would be useful particularly for clients where callbacks are  
>>>>> expensive
>>>>> and
>>>>> require a context switch (which I think is true for all clients  
>>>>> right
>>>>> now!).
>>>>>
>>>>> Henry
>>>>>
>>>>> On Wed, Jun 10, 2009 at 8:05 PM, Satish Bhatti  
>>>>> <cthd2001@gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> I am using the asynchronous (callback) version of
>>>>>> zookeeper.getChildren().
>>>>>> That call returns immediately, I then wait for a certain time  
>>>>>> interval
>>>>>> for
>>>>>> nodes to appear, and if not I exit the method that made the
>>>>>> zookeeper.getChildren()
>>>>>> call.  Later on, a node gets added under that node and I see in 

>>>>>> my
>>>>>> logfile
>>>>>> that the Watcher.process() callback that I set above gets  
>>>>>> called.  Now
>>>>>> if I
>>>>>> make 10 failed attempts to get a node using the above  
>>>>>> technique, and at
>>>>>> some
>>>>>> later time a node does get added, I see in the logfile that the
>>>>>> Watcher.process() ends up being called 10 times!  Of course by  
>>>>>> this time
>>>>>> I
>>>>>> have totally lost interest in those callbacks.  Question:  Is  
>>>>>> there a
>>>>>> way
>>>>>> to
>>>>>> remove that asynchronous callback?  i.e. If I make a asynchronous
>>>>>> zookeeper.getChildren()
>>>>>> call, wait time t, give up, at that point can I remove the async
>>>>>> callback?
>>>>>> Satish
>>>>>>
>>>>>>
>>>>>>

Mime
View raw message