Thanks! So it looks to me like for the Java client at least, this bit of code 
reliably expires the session

     final ZooKeeper dupZookeeper = 
         new ZooKeeper(connection.getServers(), 
curZookeeper.getSessionTimeout(), watcher, 
             curZookeeper.getSessionId(), curZookeeper.getSessionPasswd()); 
     // wait until connected, then close 
     while (dupZookeeper.getState() != States.CONNECTED) { 
       Thread.sleep(10); 
     } 
     Assert.assertEquals(dupZookeeper.getState(), States.CONNECTED, "Fail to 
connect to zk using current session info"); 
     dupZookeeper.close();

But the equivalent in the C# client doesn't (reliably at least), 

            // This forces the session to be closed
            var watcher = new ConnectionWatcher();
            using (
                var zoo =
                    new ZooKeeper(
                        
Config.GetNameValueSettings("MemoryCube/HighAvailability")
                            .GetOptionalSetting("ZookeeperServers"),
                        TimeSpan.FromSeconds(1),
                        watcher,
                        connToExpire.SessionId,
                        connToExpire.SesionPassword))
            {
                watcher.WaitForConnection(TimeSpan.FromSeconds(20));
            } // Disconnects here.

so either there's something subtle I don't understand, or the C# client doesn't 
handle this case. It seems excellent elsewhere, so it's more likely to be the 
first! 

Thanks,
Ben

-----Original Message-----
From: kishore g [mailto:[email protected]] 
Sent: 14 January 2014 16:42
To: [email protected]
Subject: Re: Is there an easy way to expire a session for testing?

We have a test case in Helix to simulate session expiry in Helix that might be 
of help. It follows the similar mechanism of creating another session using the 
same session id and password and diconnecting from zookeeper.

https://git-wip-us.apache.org/repos/asf?p=helix.git;a=blob;f=helix-core/src/test/java/org/apache/helix/ZkTestHelper.java;h=7aa235177904c2c71a730146f70ff547ea41e645;hb=2981d6aa8ac4c4d6f24d946cc41ff0edd822ad6f

There are two more ways to simulate session expiry

1. Use iptables and block the connection from local host to all zookeeper 
servers. This might not work if zookeeper is running locally or atleast we 
havent figure out how to block iptables if the process is local. After 30 
seconds or what ever you have configured as session timeout, unblock the 
connection and you should get session expiry event.
2. Use kill -STOP pid, this will freeze the process and hence no heart beat 
will be sent to ZK. After 30 seconds unfreeze the process and you should get 
session expiry events.


thanks,
Kishore G


On Tue, Jan 14, 2014 at 7:14 AM, <[email protected]> wrote:

> Hi
>
> Apologies for delibaratly reusing an FAQ item as the title of the 
> question, but it's when I'm trying to implement the suggestion that 
> I'm having issues! I'm currently using the latest C# client, but the 
> code looks identical in the Java client, so it may be applicable to both.
>
> I'm trying to reconnect to an existing session using the session id 
> and password in order to force an expiry in a unit test. The 
> connection works ok, but actually forcing the expiry seems very flaky. 
> The problem seems to occur at the line:
>
>                         SubmitRequest(new RequestHeader { Type = 
> (int)OpCode.CloseSession }, null, null, null);
>
> Or
>
>             RequestHeader h = new RequestHeader();
>             h.setType(ZooDefs.OpCode.closeSession);
>
>             submitRequest(h, null, null, null);
>
> in the Java case. In many cases the client is in the state 
> CONNECTION_LOST (which seems ok, as it normally reconnects?), so the 
> send fails, but as the client is in the process of shutting down, it's 
> not resent, and so the server never gets the explicit expiry, which 
> means the original connection never gets a SessionExpired error. Is 
> there a unit test anywhere in the codebase that shows how to implement 
> tests like this reliably? I've even tried performing the session 
> expiry in a separate process, but this doesn't appear to work reliably 
> either
>
> Thanks,
> Ben
>
>

Reply via email to