You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Kevin Burton <bu...@spinn3r.com> on 2009/01/05 05:49:22 UTC
Reconnecting to another host on failure but before session expires...
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
Re: Reconnecting to another host on failure but before session expires...
Posted by Patrick Hunt <ph...@apache.org>.
We have a "see also" in the shorter constructor over to this which has
the detail:
http://hadoop.apache.org/zookeeper/docs/r3.0.1/api/org/apache/zookeeper/ZooKeeper.html#ZooKeeper(java.lang.String,%20int,%20org.apache.zookeeper.Watcher,%20long,%20byte[])
We should copy/paste the docs instead to make it more clear.
We don't currently talk about this in the main documentation (prog
guide) which is a mistake, I've entered a jira for this:
https://issues.apache.org/jira/browse/ZOOKEEPER-263
Patrick
Thomas Vinod Johnson wrote:
> Kevin Burton wrote:
>> The ZooKeeper constructor only takes a host and port... not a list of
>> servers.
>>
> The second constructor documents the host parameter as follows:
> @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"
>> 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
>>
>>
Re: Reconnecting to another host on failure but before session expires...
Posted by Patrick Hunt <ph...@apache.org>.
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.Johnson@Sun.COM [Thomas.Johnson@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 List<String> of host:port names?
>>
>>
> If API cleanup was being considered, my inclination would have been
> List<InetSocketAddress>.
Re: Reconnecting to another host on failure but before session
expires...
Posted by Mahadev Konar <ma...@yahoo-inc.com>.
Hi Kevin,
Here is the link to the jira
http://issues.apache.org/jira/browse/ZOOKEEPER-146
Comments are welcome.
mahadev
On 1/7/09 12:35 PM, "Kevin Burton" <bu...@spinn3r.com> wrote:
> I like this idea.... though if that URL vanishes you can't connect to ZK.
> The bootstrap problem is hard.
>
> Another issue is adding more ensembles without reconfiguring all clients.
>
> It might be nice to connect to a 'profile' and have the client persist hosts
> in that profile.
>
> This way you can new machines (ZK servers) to the profile, wait for all ZK
> nodes to DL the new profile, then safely shutdown the old machines.
>
> The local ZK nodes would need some type of local persistent storage though.
>
> Kevin
>
> On Wed, Jan 7, 2009 at 9:05 AM, Benjamin Reed <br...@yahoo-inc.com> 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.
>>
Re: Reconnecting to another host on failure but before session expires...
Posted by Kevin Burton <bu...@spinn3r.com>.
I like this idea.... though if that URL vanishes you can't connect to ZK.
The bootstrap problem is hard.
Another issue is adding more ensembles without reconfiguring all clients.
It might be nice to connect to a 'profile' and have the client persist hosts
in that profile.
This way you can new machines (ZK servers) to the profile, wait for all ZK
nodes to DL the new profile, then safely shutdown the old machines.
The local ZK nodes would need some type of local persistent storage though.
Kevin
On Wed, Jan 7, 2009 at 9:05 AM, Benjamin Reed <br...@yahoo-inc.com> 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.
>
--
Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com
RE: Reconnecting to another host on failure but before session
expires...
Posted by Benjamin Reed <br...@yahoo-inc.com>.
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.Johnson@Sun.COM [Thomas.Johnson@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 List<String> of host:port names?
>
>
If API cleanup was being considered, my inclination would have been
List<InetSocketAddress>.
Re: Reconnecting to another host on failure but before session
expires...
Posted by Vinod Johnson <Th...@Sun.COM>.
Kevin Burton wrote:
> Crazy, I don't know how I missed that...
> Wouldn't it be cleaner to specify this as a List<String> of host:port names?
>
>
If API cleanup was being considered, my inclination would have been
List<InetSocketAddress>.
Re: Reconnecting to another host on failure but before session expires...
Posted by Kevin Burton <bu...@spinn3r.com>.
Crazy, I don't know how I missed that...
Wouldn't it be cleaner to specify this as a List<String> of host:port names?
Kevin
On Mon, Jan 5, 2009 at 10:36 AM, Thomas Vinod Johnson <
Thomas.Johnson@sun.com> wrote:
> Kevin Burton wrote:
>
>> The ZooKeeper constructor only takes a host and port... not a list of
>> servers.
>>
>>
> The second constructor documents the host parameter as follows:
> @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"
>
>> I assumed you communicated with on server by default, and that server then
>>
>
--
Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com
Re: Reconnecting to another host on failure but before session
expires...
Posted by Thomas Vinod Johnson <Th...@Sun.COM>.
Kevin Burton wrote:
> The ZooKeeper constructor only takes a host and port... not a list of
> servers.
>
The second constructor documents the host parameter as follows:
@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"
> 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
>
>
Re: Reconnecting to another host on failure but before session expires...
Posted by Robert Newson <ro...@gmail.com>.
It's in the javadocs...
"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.
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. "
On Mon, Jan 5, 2009 at 6:32 PM, Flavio Junqueira <fp...@yahoo-inc.com> wrote:
> You can pass a comma-separated list of servers (address:port). I couldn't
> find a reference in the documentation, but in the code you can check:
> ZooKeeper.ZooKeeper() and ClientCnxn.ClientCnxn().
>
> -Flavio
>
> On Jan 5, 2009, at 6:54 PM, Kevin Burton wrote:
>
>> 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 <fp...@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" <bu...@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
>
>
Re: Reconnecting to another host on failure but before session expires...
Posted by Flavio Junqueira <fp...@yahoo-inc.com>.
You can pass a comma-separated list of servers (address:port). I
couldn't find a reference in the documentation, but in the code you
can check: ZooKeeper.ZooKeeper() and ClientCnxn.ClientCnxn().
-Flavio
On Jan 5, 2009, at 6:54 PM, Kevin Burton wrote:
> 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 <fp...@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" <bu...@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
Re: Reconnecting to another host on failure but before session expires...
Posted by Kevin Burton <bu...@spinn3r.com>.
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 <fp...@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" <bu...@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
Re: Reconnecting to another host on failure but before session expires...
Posted by Flavio Junqueira <fp...@yahoo-inc.com>.
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" <bu...@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
Re: Reconnecting to another host on failure but before session expires...
Posted by David Yee <da...@collarity.com>.
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" <bu...@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
Re: Reconnecting to another host on failure but before session expires...
Posted by Kevin Burton <bu...@spinn3r.com>.
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