Re: Reconnecting to another host on failure but before session expires...

2009-01-07 Thread Vinod Johnson

Kevin Burton wrote:

Crazy, I don't know how I missed that...
Wouldn't it be cleaner to specify this as a ListString of host:port names?

  
If API cleanup was being considered, my inclination would have been 
ListInetSocketAddress.


Re: Reconnecting to another host on failure but before session expires...

2009-01-07 Thread Patrick Hunt
There's also been interest in having a chroot type capability as part 
of the connect string:


host:port/app/abc,...

where the client's session would be rooted at /app/abc rather than /

This is very useful in multi-tenant situations (more than 1 app sharing 
a zk cluster).


Patrick

Benjamin Reed wrote:

Using a string gives us some flexibility. There is an outstanding issue to be 
able to pass in a URL: http://aeoueu/oeueue, the idea being that we pull down 
the content to get the list of servers and ports.

ben


From: thomas.john...@sun.com [thomas.john...@sun.com]
Sent: Wednesday, January 07, 2009 8:35 AM
To: zookeeper-user@hadoop.apache.org
Subject: Re: Reconnecting to another host on failure but before session 
expires...

Kevin Burton wrote:

Crazy, I don't know how I missed that...
Wouldn't it be cleaner to specify this as a ListString of host:port names?



If API cleanup was being considered, my inclination would have been
ListInetSocketAddress.


Re: Reconnecting to another host on failure but before session expires...

2009-01-05 Thread Kevin Burton
The ZooKeeper constructor only takes a host and port... not a list of
servers.
I assumed you communicated with on server by default, and that server then
passed you the list of all known servers.

Am I missing something?

Kevin


/**
 * @see ZooKeeper(String, int, Watcher, long, byte[])
 */
public ZooKeeper(String host, int sessionTimeout, Watcher watcher)
throws IOException {
watchManager.defaultWatcher = watcher;
cnxn = new ClientCnxn(host, sessionTimeout, this, watchManager);
}

/**
 * To create a client(ZooKeeper) object, the application needs to pass a
 * string containing a list of host:port pairs, each corresponding to a
 * ZooKeeper server.
 * p
 * The client object will pick an arbitrary server and try to connect to
it.
 * If failed, it will try the next one in the list, until a connection
is
 * established, or all the servers have been tried.
 * p
 * Use {...@link #getSessionId} and {...@link #getSessionPasswd} on an
established
 * client connection, these values must be passed as sessionId and
 * sessionPasswd respectively if reconnecting. Otherwise, if not
 * reconnecting, use the other constructor which does not require these
 * parameters.
 *
 * @param host
 *comma separated host:port pairs, each corresponding to a
zk
 *server. eg. 127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002
 * @param sessionTimeout
 *session timeout in milliseconds
 * @param watcher
 *a watcher object which will be notified of state changes,
may
 *also be notified for node events
 * @param sessionId
 *specific session id to use if reconnecting
 * @param sessionPasswd
 *password for this session
 *
 * @throws IOException
 * in cases of network failure
 */
public ZooKeeper(String host, int sessionTimeout, Watcher watcher,
long sessionId, byte[] sessionPasswd) throws IOException {
watchManager.defaultWatcher = watcher;
cnxn = new ClientCnxn(host, sessionTimeout, this, watchManager,
sessionId, sessionPasswd);
}


On Mon, Jan 5, 2009 at 1:51 AM, Flavio Junqueira f...@yahoo-inc.com wrote:

 Are you guys passing one server to the ZooKeeper constructor or a list of
 servers? If possible, could you provide your part of the code in which you
 create a ZooKeeper object?

 Thanks,
 -Flavio


 On Jan 5, 2009, at 10:46 AM, David Yee wrote:

  I'm seeing this behavior as well, and I'm dealing with it by writing
 custom code to handle the logic of reconnecting to another zookeeper server.

 it would be nice to get some clarity regarding whether this is expected
 behavior or if there is a bug in the client code.

 We've also written code for dealing with other issues when losing a
 connection to a zk server. (implict triggering of all watches - since
 watches are stored locally on a particlar an server, etc)


 On Jan 5, 2009, at 12:03 AM, Kevin Burton bur...@spinn3r.com wrote:

  I'm not observing this behavior... if I shutdown the zookeeper server my
 client doesn't reconnect and I get a disconnect event followed by
 eventual
 session expiration.

 Which is not the behavior I want :)

 Clients connect to a single ZooKeeper server. The client maintains a TCP
 connection through which it sends requests, gets responses, gets watch
 events, and sends heart beats. If the TCP connection to the server
 breaks,
 the client will connect to a different server.


  I don't see this documented anywhere.
 I setup 5 zk servers if I connect to host1 and am performing some
 action like watching for file updates, and host1 fails, I *should* be
 able
 to connect to hosts2-5 just fine.

 But the ZooKeeper object doesn't do this for me

 What's the correct behavior here?

 Kevin


  --
 Founder/CEO Spinn3r.com
 Location: San Francisco, CA
 AIM/YIM: sfburtonator
 Skype: burtonator
 Work: http://spinn3r.com





-- 
Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com