> Isn't it the case that the client won't get session expired until it's
> able to connect to a server, right? So what might happen is that the
> client loses connection to the server, the server eventually expires the
> client and deletes ephemerals (notifying all watchers) but the client
> won't see the "session expiration" until it is able to reconnect to one
> of the servers. ie the client doesn't know it's been expired until it's
> able to reconnect to the cluster, at which point it's notified that it's
> been expired.
You are right pat!
>> Has this information scattered around, but we should put it in the FAQ
> 3.0.1 is a bit old, try this for the latest docs:
>> - Is the ZooKeeper handle I'm using dead after this event?
>> Again no. your handle is valid until you get an session expiry event or you
>> do a zoo_close on your handle.
>> On 3/25/09 5:42 PM, "Nitay" <nit...@gmail.com> wrote:
>>> I'm a little unclear about the ConnectionLoss exception as it's described in
>>> the FAQ and would like some clarification.
>>> From the state diagram, http://wiki.apache.org/hadoop/ZooKeeper/FAQ#1, there
>>> are three events that cause a ConnectionLoss:
>>> 1) In Connecting state, call close().
>>> 2) In Connected state, call close().
>>> 3) In Connected state, get disconnected.
>>> It's the third one I'm unclear about.
>>> - Does this event happening mean my ephemeral nodes will go away?
>>> - Is the ZooKeeper handle I'm using dead after this event? Meaning that,
>>> similar to the SessionExpired case, I need to construct a new connection
>>> handle to ZooKeeper and take care of the restarting myself. It seems from
>>> the diagram that this should not be the case. Rather, seeing as the
>>> disconnected event sends the user back to the Connecting state, my handle
>>> should be fine and the library will keep trying to reconnect to ZooKeeper
>>> internally? I understand my current operation may have failed, what I'm
>>> asking about is future operations.