I'm curious, what is the "best practice" for how to handle the case
where re-adding a watch inside a Watcher.process callback fails?
I keep stumbling upon the same kind of thing, and the possibility of
race conditions or undefined behavior keep troubling me. Maybe I'm
missing something.
Suppose I have a callback like:
public void process( WatchedEvent watchedEvent )
{
if ( watchedEvent.getType() ==
Event.EventType.NodeChildrenChanged ) {
try {
... do stuff ...
}
catch ( Throwable e ) {
log.error( "Could not do stuff!", e );
}
try {
zooKeeperManager.watchChildren( zPath, this );
}
catch ( InterruptedException e ) {
log.info( "Interrupted adding watch -- shutting down?" );
return;
}
catch ( KeeperException e ) {
// oh crap, now what?
}
}
}
(In this cases, watchChildren is just calling getChildren and passing
the watcher in.)
It occurs to me I could get more and more complicated here: I could
wrap watchChildren in a while loop until it succeeds, but that seems
kind of rude to the caller. Plus what if I get a
KeeperException.SessionExpiredException or a
KeeperException.ConnectionLossException? How to handle that in this
loop? Or I could send some other thread a message that it needs to keep
trying until the watch has been re-added ... but ... yuck.
I would very much like to just setup this watch once, and have ZooKeeper
make sure it keeps firing until I tear down ZooKeeper -- this logic
seems tricky for clients, and quite error prone and full of race conditions.
Any thoughts?
Thanks,
Eric
--
Eric Bowman
Boboco Ltd
ebowman@boboco.ie
http://www.boboco.ie/ebowman/pubkey.pgp
+35318394189/+353872801532
|