Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <49947845.3030802@apache.org>
Date: Thu, 12 Feb 2009 11:28:05 -0800
From: Patrick Hunt <phunt@apache.org>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: zookeeper-user@hadoop.apache.org
Subject: Re: Dealing with session expired
References: <d8cb87ee0902121058u54d77780p47c7cd6f72878a02@mail.gmail.com>
	 <C5B9B4B9.180EE%mahadev@yahoo-inc.com>
 <d8cb87ee0902121117s2bf0c255w49c48f8c409e2715@mail.gmail.com>
In-Reply-To: <d8cb87ee0902121117s2bf0c255w49c48f8c409e2715@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ephemerals and watches are maintained across disconnect/reconnect btw 
the client and server however session expiration (or closing the session 
explicitly) will trigger deletion of ephemeral nodes associated with the 
session.

Right - once the session is expired the id is invalid. You need to 
create a new session (new id).

Btw, the "timeout" value you provide to when constructing the zookeeper 
client session directly effects the session expiration - the server uses 
this timeout as the session expiration time.

Patrick

Tom Nichols wrote:
> So if a session expires, my ephemeral nodes and watches have already
> disappeared?  I suppose creating a new ZK instance with the old
> session ID would not do me any good in that case.  Correct?
> 
> Thanks.
> -Tom
> 
> 
> 
> On Thu, Feb 12, 2009 at 2:12 PM, Mahadev Konar <mahadev@yahoo-inc.com> wrote:
>> Hi Tom,
>>  We prefer to discard the zookeeper instance if a session expires.
>> Maintaining a one to one relationship between a client handle and a session
>> makes it much simpler for users to understand the existence and
>> disappearance of ephemeral nodes and watches created by a zookeeper client.
>>
>> thanks
>> mahadev
>>
>>
>> On 2/12/09 10:58 AM, "Tom Nichols" <tmnichols@gmail.com> wrote:
>>
>>> I've come across the situation where a ZK instance will have an
>>> expired connection and therefore all operations fail.  Now AFAIK the
>>> only way to recover is to create  a new ZK instance with the old
>>> session ID, correct?
>>>
>>> Now, my problem is, the ZK instance may be shared -- not between
>>> threads -- but maybe two classes in the same thread synchronize on
>>> different nodes by using different watchers.  So it makes sense that
>>> one ZK client instance can handle this.  Except that even if I detect
>>> the session expiration by catching the KeeperException, if I want to
>>> "resume" the session, I have to create a new ZK instance and pass it
>>> to any classes who were previously sharing the same instance.  Does
>>> this make sense so far?
>>>
>>> Anyway, bottom line is, it would be nice if a ZK instance could itself
>>> recover a session rather than discarding that instance and creating a
>>> new one.
>>>
>>> Thoughts?
>>>
>>> Thanks in advance,
>>>
>>> -Tom
>>