|
|
-
Re: Forcing DISCONNECTED event?
JL 2012-03-15, 17:41
On Mar 15, 2012, JL <[EMAIL PROTECTED]> wrote:
Thanks Patrick.
> This is the c client? (In java I know we have a zk subclass that provides this.)
This is Java. Could you point me to the ZK subclass that provides this functionality? I may or may not be able to use it without tearing things apart too much as I am using ZK through Curator.
> Perhaps an easier way would be to simulate Server failure - e.g. start a quroum of 3 servers, Have your client connect, then shutdown the server that the client connected to. The client will be disconnected and reconnect to one of the remaining 2 servers.
The 3-server quorom approach seems like the way to go for us, as we can easily set up a ZK cluster for testing (thanks again to curator-test). I'll give that a try. Thanks for the quick response,
-Julio
-
Re: Forcing DISCONNECTED event?
Patrick Hunt 2012-03-17, 15:57
On Thu, Mar 15, 2012 at 10:41 AM, JL <[EMAIL PROTECTED]> wrote: > On Mar 15, 2012, JL <[EMAIL PROTECTED]> wrote: > > Thanks Patrick. > >> This is the c client? (In java I know we have a zk subclass that provides this.) > > This is Java. Could you point me to the ZK subclass that provides this functionality? I may or may not be able to use it without tearing things apart too much as I am using ZK through Curator. >
org.apache.zookeeper.TestableZooKeeper.testableConnloss()
>> Perhaps an easier way would be to simulate Server failure - e.g. start a quroum of 3 servers, Have your client connect, then shutdown the server that the client connected to. The client will be disconnected and reconnect to one of the remaining 2 servers. > > The 3-server quorom approach seems like the way to go for us, as we can easily set up a ZK cluster for testing (thanks again to curator-test). I'll give that a try. >
That's what we often do in zk testing itself. It better simulates what happens in the real world. Curator is the bees knees.
> > Thanks for the quick response,
NP. Regards.
Patrick
+
Patrick Hunt 2012-03-17, 15:57
-
Re: Re: Forcing DISCONNECTED event?
JL 2012-03-15, 17:38
Thanks Mark.
I am using Java for this.
The approach you suggest was the first one that I tried, but I was getting a session error and the ZK client was going into the CLOSED state. The server is being cleanly shutdown. As far as I can tell (from the logs and skimming through the code path), the server terminates the client session(s) during shutdown. I'm guessing it persists the session termination in the log (or elsewhere), so on restart it tells the client that this is an invalid session if the client tries to reconnect with the same session id (which I'm guessing the client does not try to do if the session termination was clean).
Nevertheless, I'll play a little bit with the timeout parameters and dive in a bit.
Thanks for the prompt reply.
-Julio
On Mar 14, 2012, Mark Gius <[EMAIL PROTECTED]> wrote:
With the python client (thin wrapper around C) I was able to simulate CONNECTING in a single node scenario. Just shutdown the only zookeeper server and the client will notice this real quick. Turn zookeeper server back on and client should reconnect within a few seconds. You'll need to make sure your recv_timeout is high enough so that the client doesn't give up and fire a DISCONNECTED.
Mark
On Wed, Mar 14, 2012 at 11:06 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> This is the c client? (In java I know we have a zk subclass that > provides this.) You can use jmx on the server, there is a > terminateConnection method. Perhaps an easier way would be to simulate > Server failure - e.g. start a quroum of 3 servers, Have your client > connect, then shutdown the server that the client connected to. The > client will be disconnected and reconnect to one of the remaining 2 > servers. Our zk tests do this. > > Patrick > > On Wed, Mar 14, 2012 at 11:04 AM, JL <[EMAIL PROTECTED]> wrote: > > Is there a way of forcing the ZK client to go into CONNECTING state > after having reached the CONNECTED state, but without killing the session? > > We are aware of the FAQ entry for "Is there an easy way to expire a > session for testing?", but that does not achieve what we want as it kills > the session. > > > > We'd like to be able to essentially test the sequence of going: > > > > - From CONNECTED to CONNECTING; > > - followed by a transition from CONNECTING to CONNECTED. > > > > Thanks, > > > > -Julio >
-
Forcing DISCONNECTED event?
JL 2012-03-14, 18:04
Is there a way of forcing the ZK client to go into CONNECTING state after having reached the CONNECTED state, but without killing the session? We are aware of the FAQ entry for "Is there an easy way to expire a session for testing?", but that does not achieve what we want as it kills the session.
We'd like to be able to essentially test the sequence of going:
- From CONNECTED to CONNECTING; - followed by a transition from CONNECTING to CONNECTED.
Thanks,
-Julio
-
Re: Forcing DISCONNECTED event?
Patrick Hunt 2012-03-15, 06:06
This is the c client? (In java I know we have a zk subclass that provides this.) You can use jmx on the server, there is a terminateConnection method. Perhaps an easier way would be to simulate Server failure - e.g. start a quroum of 3 servers, Have your client connect, then shutdown the server that the client connected to. The client will be disconnected and reconnect to one of the remaining 2 servers. Our zk tests do this.
Patrick
On Wed, Mar 14, 2012 at 11:04 AM, JL <[EMAIL PROTECTED]> wrote: > Is there a way of forcing the ZK client to go into CONNECTING state after having reached the CONNECTED state, but without killing the session? > We are aware of the FAQ entry for "Is there an easy way to expire a session for testing?", but that does not achieve what we want as it kills the session. > > We'd like to be able to essentially test the sequence of going: > > - From CONNECTED to CONNECTING; > - followed by a transition from CONNECTING to CONNECTED. > > Thanks, > > -Julio
+
Patrick Hunt 2012-03-15, 06:06
-
Re: Forcing DISCONNECTED event?
Mark Gius 2012-03-15, 06:56
With the python client (thin wrapper around C) I was able to simulate CONNECTING in a single node scenario. Just shutdown the only zookeeper server and the client will notice this real quick. Turn zookeeper server back on and client should reconnect within a few seconds. You'll need to make sure your recv_timeout is high enough so that the client doesn't give up and fire a DISCONNECTED.
Mark
On Wed, Mar 14, 2012 at 11:06 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> This is the c client? (In java I know we have a zk subclass that > provides this.) You can use jmx on the server, there is a > terminateConnection method. Perhaps an easier way would be to simulate > Server failure - e.g. start a quroum of 3 servers, Have your client > connect, then shutdown the server that the client connected to. The > client will be disconnected and reconnect to one of the remaining 2 > servers. Our zk tests do this. > > Patrick > > On Wed, Mar 14, 2012 at 11:04 AM, JL <[EMAIL PROTECTED]> wrote: > > Is there a way of forcing the ZK client to go into CONNECTING state > after having reached the CONNECTED state, but without killing the session? > > We are aware of the FAQ entry for "Is there an easy way to expire a > session for testing?", but that does not achieve what we want as it kills > the session. > > > > We'd like to be able to essentially test the sequence of going: > > > > - From CONNECTED to CONNECTING; > > - followed by a transition from CONNECTING to CONNECTED. > > > > Thanks, > > > > -Julio >
+
Mark Gius 2012-03-15, 06:56
|
|