RE: Updated NodeWatcher...
yeah, i was thinking it should be in forrest, but i couldn't figure out where to put it. that is why i didn't close the issue. ben -Original Message- From: Patrick Hunt [mailto:ph...@apache.org] Sent: Friday, January 09, 2009 9:37 AM To: zookeeper-user@hadoop.apache.org Subject: Re: Updated NodeWatcher... Ben this is great, thanks! Do you want to close out this one and point to the faq? https://issues.apache.org/jira/browse/ZOOKEEPER-264 Although IMO this should be moved to the forrest docs. Patrick Benjamin Reed wrote: > I'm really bad a creating figures, but i've put up something that should be > informative. (i'm also really bad at apache wiki.) hopefully someone can make > it more beautiful. i've added the state diagram to the FAQ: > http://wiki.apache.org/hadoop/ZooKeeper/FAQ > > ben > > -Original Message- > From: adam.ros...@gmail.com [mailto:adam.ros...@gmail.com] On Behalf Of Adam > Rosien > Sent: Thursday, January 08, 2009 8:06 PM > To: zookeeper-user@hadoop.apache.org > Subject: Re: Updated NodeWatcher... > > It feels like we need a flowchart, state-chart, or something, so we > can all talk about the same thing. Then people could suggest > abstractions that would essentially put a box around sections of the > diagram. However I feel woefully inadequate at the former :(. > > .. Adam > > On Thu, Jan 8, 2009 at 4:20 PM, Benjamin Reed wrote: >> For your first issue if an ensemble goes offline and comes back, everything >> should be fine. it will look to the client just like a server went down. if >> a session expires, you are correct that the client will not reconnect. this >> again is on purpose. for the node watcher the session is unimportant, but if >> the ZooKeeper object is also being used for leader election, for example, >> you do not want the object to grab a new session automatically. >> >> For 2) i think pat responded to that one. an async request will always >> return. if the server goes down after the request is issued, you will get a >> connection loss error in your callback. >> >> Your third issued is described with the first. >> >> ben >> >> -Original Message- >> From: burtona...@gmail.com [mailto:burtona...@gmail.com] On Behalf Of Kevin >> Burton >> Sent: Thursday, January 08, 2009 4:02 PM >> To: zookeeper-user@hadoop.apache.org >> Subject: Re: Updated NodeWatcher... >> >>> >>> i just found that part of this thread went to my junk folder. can you send >>> the URL for the NodeListener? >>> >> Sure... here you go: >> >> http://pastebin.com/f1e9d3706 >> >> >>> this NodeWatcher is a useful thing. i have a couple of suggestions to >>> simplify it: >>> >>> 1) Construct the NodeWatcher with a ZooKeeper object rather than >>> constructing one. Not only does it simplify NodeWatcher, but it also makes >>> it so that the ZooKeeper object can be used for other things as well. >> >> I hear you I was thinking that this might not be a good idea because >> NodeWatcher can reconnect you to the ensemble if it goes offline. >> >> I'm not sure if it's a bug or not but once my session expired on the client >> it wouldn't reconnect so I just implemented my own reconnect and session >> expiry. >> >> >>> 2) Use the async API in watchNodeData and watchNodeExists. it simplifies >>> the code and the error handling. >> >> The problem was that according to feedback here an async request might never >> return if the server dies shortly after the request and before it has a >> change to respond. >> >> I wanted NodeWatcher to hide as much rope as possible. >> >> >>> 3) You don't need to do a connect() in handleDisconnected(). ZooKeeper >>> object will do it automatically for you. >>> >>> >> I can try again if you'd like by this isn't my experience. Once the session >> expired and the whole ensemble was offline it wouldn't connect again. >> >> If it was a transient disconnect I'd see on disconnect event and then a >> quick reconnect. If it was a long disconnect (with nothing to attach to) >> then ZK won't ever reconnect me. >> >> I'd like this to be the behavior though... >> >> >>> There is an old example on sourceforge >>> http://zookeeper.wiki.sourceforge.net/ZooKeeperJavaExample that may give >>> you some more ideas on how to simplify your code. >>> >> That would be nice simple is good! >> >> Kevin >> >> >> -- >> Founder/CEO Spinn3r.com >> Location: San Francisco, CA >> AIM/YIM: sfburtonator >> Skype: burtonator >> Work: http://spinn3r.com >>
Re: Updated NodeWatcher...
Thanks. And yes, your chart is really ugly! :) These are the states of... what? The session? The ZooKeeper object? It would be nice to include the corresponding API references. .. Adam On Fri, Jan 9, 2009 at 5:09 AM, Benjamin Reed wrote: > I'm really bad a creating figures, but i've put up something that should be > informative. (i'm also really bad at apache wiki.) hopefully someone can make > it more beautiful. i've added the state diagram to the FAQ: > http://wiki.apache.org/hadoop/ZooKeeper/FAQ > > ben > > -Original Message- > From: adam.ros...@gmail.com [mailto:adam.ros...@gmail.com] On Behalf Of Adam > Rosien > Sent: Thursday, January 08, 2009 8:06 PM > To: zookeeper-user@hadoop.apache.org > Subject: Re: Updated NodeWatcher... > > It feels like we need a flowchart, state-chart, or something, so we > can all talk about the same thing. Then people could suggest > abstractions that would essentially put a box around sections of the > diagram. However I feel woefully inadequate at the former :(. > > .. Adam > > On Thu, Jan 8, 2009 at 4:20 PM, Benjamin Reed wrote: >> For your first issue if an ensemble goes offline and comes back, everything >> should be fine. it will look to the client just like a server went down. if >> a session expires, you are correct that the client will not reconnect. this >> again is on purpose. for the node watcher the session is unimportant, but if >> the ZooKeeper object is also being used for leader election, for example, >> you do not want the object to grab a new session automatically. >> >> For 2) i think pat responded to that one. an async request will always >> return. if the server goes down after the request is issued, you will get a >> connection loss error in your callback. >> >> Your third issued is described with the first. >> >> ben >> >> -Original Message- >> From: burtona...@gmail.com [mailto:burtona...@gmail.com] On Behalf Of Kevin >> Burton >> Sent: Thursday, January 08, 2009 4:02 PM >> To: zookeeper-user@hadoop.apache.org >> Subject: Re: Updated NodeWatcher... >> >>> >>> >>> i just found that part of this thread went to my junk folder. can you send >>> the URL for the NodeListener? >>> >> >> Sure... here you go: >> >> http://pastebin.com/f1e9d3706 >> >> >>> >>> this NodeWatcher is a useful thing. i have a couple of suggestions to >>> simplify it: >>> >>> 1) Construct the NodeWatcher with a ZooKeeper object rather than >>> constructing one. Not only does it simplify NodeWatcher, but it also makes >>> it so that the ZooKeeper object can be used for other things as well. >> >> >> I hear you I was thinking that this might not be a good idea because >> NodeWatcher can reconnect you to the ensemble if it goes offline. >> >> I'm not sure if it's a bug or not but once my session expired on the client >> it wouldn't reconnect so I just implemented my own reconnect and session >> expiry. >> >> >>> >>> 2) Use the async API in watchNodeData and watchNodeExists. it simplifies >>> the code and the error handling. >> >> >> The problem was that according to feedback here an async request might never >> return if the server dies shortly after the request and before it has a >> change to respond. >> >> I wanted NodeWatcher to hide as much rope as possible. >> >> >>> 3) You don't need to do a connect() in handleDisconnected(). ZooKeeper >>> object will do it automatically for you. >>> >>> >> I can try again if you'd like by this isn't my experience. Once the session >> expired and the whole ensemble was offline it wouldn't connect again. >> >> If it was a transient disconnect I'd see on disconnect event and then a >> quick reconnect. If it was a long disconnect (with nothing to attach to) >> then ZK won't ever reconnect me. >> >> I'd like this to be the behavior though... >> >> >>> There is an old example on sourceforge >>> http://zookeeper.wiki.sourceforge.net/ZooKeeperJavaExample that may give >>> you some more ideas on how to simplify your code. >>> >> >> That would be nice simple is good! >> >> Kevin >> >> >> -- >> Founder/CEO Spinn3r.com >> Location: San Francisco, CA >> AIM/YIM: sfburtonator >> Skype: burtonator >> Work: http://spinn3r.com >> >
Re: Updated NodeWatcher...
Ben this is great, thanks! Do you want to close out this one and point to the faq? https://issues.apache.org/jira/browse/ZOOKEEPER-264 Although IMO this should be moved to the forrest docs. Patrick Benjamin Reed wrote: I'm really bad a creating figures, but i've put up something that should be informative. (i'm also really bad at apache wiki.) hopefully someone can make it more beautiful. i've added the state diagram to the FAQ: http://wiki.apache.org/hadoop/ZooKeeper/FAQ ben -Original Message- From: adam.ros...@gmail.com [mailto:adam.ros...@gmail.com] On Behalf Of Adam Rosien Sent: Thursday, January 08, 2009 8:06 PM To: zookeeper-user@hadoop.apache.org Subject: Re: Updated NodeWatcher... It feels like we need a flowchart, state-chart, or something, so we can all talk about the same thing. Then people could suggest abstractions that would essentially put a box around sections of the diagram. However I feel woefully inadequate at the former :(. .. Adam On Thu, Jan 8, 2009 at 4:20 PM, Benjamin Reed wrote: For your first issue if an ensemble goes offline and comes back, everything should be fine. it will look to the client just like a server went down. if a session expires, you are correct that the client will not reconnect. this again is on purpose. for the node watcher the session is unimportant, but if the ZooKeeper object is also being used for leader election, for example, you do not want the object to grab a new session automatically. For 2) i think pat responded to that one. an async request will always return. if the server goes down after the request is issued, you will get a connection loss error in your callback. Your third issued is described with the first. ben -Original Message- From: burtona...@gmail.com [mailto:burtona...@gmail.com] On Behalf Of Kevin Burton Sent: Thursday, January 08, 2009 4:02 PM To: zookeeper-user@hadoop.apache.org Subject: Re: Updated NodeWatcher... i just found that part of this thread went to my junk folder. can you send the URL for the NodeListener? Sure... here you go: http://pastebin.com/f1e9d3706 this NodeWatcher is a useful thing. i have a couple of suggestions to simplify it: 1) Construct the NodeWatcher with a ZooKeeper object rather than constructing one. Not only does it simplify NodeWatcher, but it also makes it so that the ZooKeeper object can be used for other things as well. I hear you I was thinking that this might not be a good idea because NodeWatcher can reconnect you to the ensemble if it goes offline. I'm not sure if it's a bug or not but once my session expired on the client it wouldn't reconnect so I just implemented my own reconnect and session expiry. 2) Use the async API in watchNodeData and watchNodeExists. it simplifies the code and the error handling. The problem was that according to feedback here an async request might never return if the server dies shortly after the request and before it has a change to respond. I wanted NodeWatcher to hide as much rope as possible. 3) You don't need to do a connect() in handleDisconnected(). ZooKeeper object will do it automatically for you. I can try again if you'd like by this isn't my experience. Once the session expired and the whole ensemble was offline it wouldn't connect again. If it was a transient disconnect I'd see on disconnect event and then a quick reconnect. If it was a long disconnect (with nothing to attach to) then ZK won't ever reconnect me. I'd like this to be the behavior though... There is an old example on sourceforge http://zookeeper.wiki.sourceforge.net/ZooKeeperJavaExample that may give you some more ideas on how to simplify your code. That would be nice simple is good! Kevin -- Founder/CEO Spinn3r.com Location: San Francisco, CA AIM/YIM: sfburtonator Skype: burtonator Work: http://spinn3r.com
RE: Updated NodeWatcher...
I'm really bad a creating figures, but i've put up something that should be informative. (i'm also really bad at apache wiki.) hopefully someone can make it more beautiful. i've added the state diagram to the FAQ: http://wiki.apache.org/hadoop/ZooKeeper/FAQ ben -Original Message- From: adam.ros...@gmail.com [mailto:adam.ros...@gmail.com] On Behalf Of Adam Rosien Sent: Thursday, January 08, 2009 8:06 PM To: zookeeper-user@hadoop.apache.org Subject: Re: Updated NodeWatcher... It feels like we need a flowchart, state-chart, or something, so we can all talk about the same thing. Then people could suggest abstractions that would essentially put a box around sections of the diagram. However I feel woefully inadequate at the former :(. .. Adam On Thu, Jan 8, 2009 at 4:20 PM, Benjamin Reed wrote: > For your first issue if an ensemble goes offline and comes back, everything > should be fine. it will look to the client just like a server went down. if a > session expires, you are correct that the client will not reconnect. this > again is on purpose. for the node watcher the session is unimportant, but if > the ZooKeeper object is also being used for leader election, for example, you > do not want the object to grab a new session automatically. > > For 2) i think pat responded to that one. an async request will always > return. if the server goes down after the request is issued, you will get a > connection loss error in your callback. > > Your third issued is described with the first. > > ben > > -Original Message- > From: burtona...@gmail.com [mailto:burtona...@gmail.com] On Behalf Of Kevin > Burton > Sent: Thursday, January 08, 2009 4:02 PM > To: zookeeper-user@hadoop.apache.org > Subject: Re: Updated NodeWatcher... > >> >> >> i just found that part of this thread went to my junk folder. can you send >> the URL for the NodeListener? >> > > Sure... here you go: > > http://pastebin.com/f1e9d3706 > > >> >> this NodeWatcher is a useful thing. i have a couple of suggestions to >> simplify it: >> >> 1) Construct the NodeWatcher with a ZooKeeper object rather than >> constructing one. Not only does it simplify NodeWatcher, but it also makes >> it so that the ZooKeeper object can be used for other things as well. > > > I hear you I was thinking that this might not be a good idea because > NodeWatcher can reconnect you to the ensemble if it goes offline. > > I'm not sure if it's a bug or not but once my session expired on the client > it wouldn't reconnect so I just implemented my own reconnect and session > expiry. > > >> >> 2) Use the async API in watchNodeData and watchNodeExists. it simplifies >> the code and the error handling. > > > The problem was that according to feedback here an async request might never > return if the server dies shortly after the request and before it has a > change to respond. > > I wanted NodeWatcher to hide as much rope as possible. > > >> 3) You don't need to do a connect() in handleDisconnected(). ZooKeeper >> object will do it automatically for you. >> >> > I can try again if you'd like by this isn't my experience. Once the session > expired and the whole ensemble was offline it wouldn't connect again. > > If it was a transient disconnect I'd see on disconnect event and then a > quick reconnect. If it was a long disconnect (with nothing to attach to) > then ZK won't ever reconnect me. > > I'd like this to be the behavior though... > > >> There is an old example on sourceforge >> http://zookeeper.wiki.sourceforge.net/ZooKeeperJavaExample that may give >> you some more ideas on how to simplify your code. >> > > That would be nice simple is good! > > Kevin > > > -- > Founder/CEO Spinn3r.com > Location: San Francisco, CA > AIM/YIM: sfburtonator > Skype: burtonator > Work: http://spinn3r.com >
Re: Updated NodeWatcher...
It feels like we need a flowchart, state-chart, or something, so we can all talk about the same thing. Then people could suggest abstractions that would essentially put a box around sections of the diagram. However I feel woefully inadequate at the former :(. .. Adam On Thu, Jan 8, 2009 at 4:20 PM, Benjamin Reed wrote: > For your first issue if an ensemble goes offline and comes back, everything > should be fine. it will look to the client just like a server went down. if a > session expires, you are correct that the client will not reconnect. this > again is on purpose. for the node watcher the session is unimportant, but if > the ZooKeeper object is also being used for leader election, for example, you > do not want the object to grab a new session automatically. > > For 2) i think pat responded to that one. an async request will always > return. if the server goes down after the request is issued, you will get a > connection loss error in your callback. > > Your third issued is described with the first. > > ben > > -Original Message- > From: burtona...@gmail.com [mailto:burtona...@gmail.com] On Behalf Of Kevin > Burton > Sent: Thursday, January 08, 2009 4:02 PM > To: zookeeper-user@hadoop.apache.org > Subject: Re: Updated NodeWatcher... > >> >> >> i just found that part of this thread went to my junk folder. can you send >> the URL for the NodeListener? >> > > Sure... here you go: > > http://pastebin.com/f1e9d3706 > > >> >> this NodeWatcher is a useful thing. i have a couple of suggestions to >> simplify it: >> >> 1) Construct the NodeWatcher with a ZooKeeper object rather than >> constructing one. Not only does it simplify NodeWatcher, but it also makes >> it so that the ZooKeeper object can be used for other things as well. > > > I hear you I was thinking that this might not be a good idea because > NodeWatcher can reconnect you to the ensemble if it goes offline. > > I'm not sure if it's a bug or not but once my session expired on the client > it wouldn't reconnect so I just implemented my own reconnect and session > expiry. > > >> >> 2) Use the async API in watchNodeData and watchNodeExists. it simplifies >> the code and the error handling. > > > The problem was that according to feedback here an async request might never > return if the server dies shortly after the request and before it has a > change to respond. > > I wanted NodeWatcher to hide as much rope as possible. > > >> 3) You don't need to do a connect() in handleDisconnected(). ZooKeeper >> object will do it automatically for you. >> >> > I can try again if you'd like by this isn't my experience. Once the session > expired and the whole ensemble was offline it wouldn't connect again. > > If it was a transient disconnect I'd see on disconnect event and then a > quick reconnect. If it was a long disconnect (with nothing to attach to) > then ZK won't ever reconnect me. > > I'd like this to be the behavior though... > > >> There is an old example on sourceforge >> http://zookeeper.wiki.sourceforge.net/ZooKeeperJavaExample that may give >> you some more ideas on how to simplify your code. >> > > That would be nice simple is good! > > Kevin > > > -- > Founder/CEO Spinn3r.com > Location: San Francisco, CA > AIM/YIM: sfburtonator > Skype: burtonator > Work: http://spinn3r.com >
RE: Updated NodeWatcher...
For your first issue if an ensemble goes offline and comes back, everything should be fine. it will look to the client just like a server went down. if a session expires, you are correct that the client will not reconnect. this again is on purpose. for the node watcher the session is unimportant, but if the ZooKeeper object is also being used for leader election, for example, you do not want the object to grab a new session automatically. For 2) i think pat responded to that one. an async request will always return. if the server goes down after the request is issued, you will get a connection loss error in your callback. Your third issued is described with the first. ben -Original Message- From: burtona...@gmail.com [mailto:burtona...@gmail.com] On Behalf Of Kevin Burton Sent: Thursday, January 08, 2009 4:02 PM To: zookeeper-user@hadoop.apache.org Subject: Re: Updated NodeWatcher... > > > i just found that part of this thread went to my junk folder. can you send > the URL for the NodeListener? > Sure... here you go: http://pastebin.com/f1e9d3706 > > this NodeWatcher is a useful thing. i have a couple of suggestions to > simplify it: > > 1) Construct the NodeWatcher with a ZooKeeper object rather than > constructing one. Not only does it simplify NodeWatcher, but it also makes > it so that the ZooKeeper object can be used for other things as well. I hear you I was thinking that this might not be a good idea because NodeWatcher can reconnect you to the ensemble if it goes offline. I'm not sure if it's a bug or not but once my session expired on the client it wouldn't reconnect so I just implemented my own reconnect and session expiry. > > 2) Use the async API in watchNodeData and watchNodeExists. it simplifies > the code and the error handling. The problem was that according to feedback here an async request might never return if the server dies shortly after the request and before it has a change to respond. I wanted NodeWatcher to hide as much rope as possible. > 3) You don't need to do a connect() in handleDisconnected(). ZooKeeper > object will do it automatically for you. > > I can try again if you'd like by this isn't my experience. Once the session expired and the whole ensemble was offline it wouldn't connect again. If it was a transient disconnect I'd see on disconnect event and then a quick reconnect. If it was a long disconnect (with nothing to attach to) then ZK won't ever reconnect me. I'd like this to be the behavior though... > There is an old example on sourceforge > http://zookeeper.wiki.sourceforge.net/ZooKeeperJavaExample that may give > you some more ideas on how to simplify your code. > That would be nice simple is good! Kevin -- Founder/CEO Spinn3r.com Location: San Francisco, CA AIM/YIM: sfburtonator Skype: burtonator Work: http://spinn3r.com
Re: Updated NodeWatcher...
> > > i just found that part of this thread went to my junk folder. can you send > the URL for the NodeListener? > Sure... here you go: http://pastebin.com/f1e9d3706 > > this NodeWatcher is a useful thing. i have a couple of suggestions to > simplify it: > > 1) Construct the NodeWatcher with a ZooKeeper object rather than > constructing one. Not only does it simplify NodeWatcher, but it also makes > it so that the ZooKeeper object can be used for other things as well. I hear you I was thinking that this might not be a good idea because NodeWatcher can reconnect you to the ensemble if it goes offline. I'm not sure if it's a bug or not but once my session expired on the client it wouldn't reconnect so I just implemented my own reconnect and session expiry. > > 2) Use the async API in watchNodeData and watchNodeExists. it simplifies > the code and the error handling. The problem was that according to feedback here an async request might never return if the server dies shortly after the request and before it has a change to respond. I wanted NodeWatcher to hide as much rope as possible. > 3) You don't need to do a connect() in handleDisconnected(). ZooKeeper > object will do it automatically for you. > > I can try again if you'd like by this isn't my experience. Once the session expired and the whole ensemble was offline it wouldn't connect again. If it was a transient disconnect I'd see on disconnect event and then a quick reconnect. If it was a long disconnect (with nothing to attach to) then ZK won't ever reconnect me. I'd like this to be the behavior though... > There is an old example on sourceforge > http://zookeeper.wiki.sourceforge.net/ZooKeeperJavaExample that may give > you some more ideas on how to simplify your code. > That would be nice simple is good! Kevin -- Founder/CEO Spinn3r.com Location: San Francisco, CA AIM/YIM: sfburtonator Skype: burtonator Work: http://spinn3r.com
RE: Updated NodeWatcher...
Hey kevin,
i just found that part of this thread went to my junk folder. can you send the
URL for the NodeListener?
this NodeWatcher is a useful thing. i have a couple of suggestions to simplify
it:
1) Construct the NodeWatcher with a ZooKeeper object rather than constructing
one. Not only does it simplify NodeWatcher, but it also makes it so that the
ZooKeeper object can be used for other things as well.
2) Use the async API in watchNodeData and watchNodeExists. it simplifies the
code and the error handling.
3) You don't need to do a connect() in handleDisconnected(). ZooKeeper object
will do it automatically for you.
There is an old example on sourceforge
http://zookeeper.wiki.sourceforge.net/ZooKeeperJavaExample that may give you
some more ideas on how to simplify your code.
thanx
ben
From: burtona...@gmail.com [burtona...@gmail.com] On Behalf Of Kevin Burton
[bur...@spinn3r.com]
Sent: Thursday, January 08, 2009 12:00 AM
To: zookeeper-user@hadoop.apache.org
Subject: Updated NodeWatcher...
I've updated based on the last round of feedback regarding ZK operation:
http://pastebin.com/f66898b7
This is what I think the API should look like for event based applications
without any insane requirements.
You write code like:
NodeListener listener = new NodeListener() {
public void onData( String path, Stat stat, byte[] data ) {
System.out.printf( "event: onData path: %s, version: %s,
data: %s\n", path, stat.getVersion(), new String( data ) );
}
public void onKeeperException( KeeperException e ) {
System.out.printf( "event: onKeeperException: \n" );
e.printStackTrace();
}
public void onFailure() {
System.out.printf( "event: onFailure\n" );
}
public void onConnect() {
System.out.printf( "event: onConnect\n" );
}
};
NodeWatcher nWatcher = new NodeWatcher( "server45.example.com:2181,
server46.example.com:2181,server47.example.com:2181", listener );
nWatcher.watch( "/foo" );
nWatcher.poll();
and then you will receive events back from ZK when the files are
updated.
I believe it handles all race and fail conditions of ZK which was the hard
part since some of these are subtle or not really documented.
I'd be willing to contrib this if others found it useful.
I think we're going to use it as our main interface to ZK since it solves
all the issues I care about.
Kevin
--
Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com
Updated NodeWatcher...
I've updated based on the last round of feedback regarding ZK operation:
http://pastebin.com/f66898b7
This is what I think the API should look like for event based applications
without any insane requirements.
You write code like:
NodeListener listener = new NodeListener() {
public void onData( String path, Stat stat, byte[] data ) {
System.out.printf( "event: onData path: %s, version: %s,
data: %s\n", path, stat.getVersion(), new String( data ) );
}
public void onKeeperException( KeeperException e ) {
System.out.printf( "event: onKeeperException: \n" );
e.printStackTrace();
}
public void onFailure() {
System.out.printf( "event: onFailure\n" );
}
public void onConnect() {
System.out.printf( "event: onConnect\n" );
}
};
NodeWatcher nWatcher = new NodeWatcher( "server45.example.com:2181,
server46.example.com:2181,server47.example.com:2181", listener );
nWatcher.watch( "/foo" );
nWatcher.poll();
and then you will receive events back from ZK when the files are
updated.
I believe it handles all race and fail conditions of ZK which was the hard
part since some of these are subtle or not really documented.
I'd be willing to contrib this if others found it useful.
I think we're going to use it as our main interface to ZK since it solves
all the issues I care about.
Kevin
--
Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com
