SessionExpiredExceptions should be extremely rare. Basically they should only happen if a machine goes down (of course that would mean no exception would actually get generated since the client is dead :) or a network partition occurs.
Having said that we seem to have a bug that cause SessionExpiredExceptions when nothing bad has happened. The bug must be in the heart beat code (we do them automatically, so the client shouldn't have to worry about it). If you can reproduce it well, it would greatly help to track down the bug! Can you send me the code to reproduce the problem? thanx ben On Wednesday 23 July 2008 06:28:12 James Strachan wrote: > Am just wondering if I've hit this due to some other bug. I thought ZK > did keep-alive pings to ensure each client is alive and its session > does not expire? Or does the client have to explicitly keep calling > some method on the ZooKeeper interface to ensure a steady flow of > packets to the ZK server to keep it alive? > > The test case WriteLockTest in the patch for ZOOKEEPER-78 (the > WriteLock) can always reproduce a SessionExpiredException when using 3 > clients (its always the 3rd session that expires). > > Now when a SessionExpiredException occurs, any recipe/protocol has to > be able to deal with it; so the ZOOKEEPER-84 issue is still valid > IMHO. But I'm wondering if in my test case it shouldn't be happening; > as I've got 3 clients and a server all in the same JVM and the JVM > isn't locked or pegged nor do the TCP sockets fail AFAIK. > > So I just thought I'd ask; are the keep alive packets used by default? > If they are then maybe they are not sent very frequently or something?
