Michael,
Thanks for your information. I found the codepath that client finds out
session expiration through reconnection.
However, still I cannot find where the client finds out session expiration
from responses.
Could you describe one of such case use server and client instead of bare
>> However, session could expire after connection established. Where is the
latter case trigger?
ZooKeeper checks every incoming request and the appertained session. When a
session is expiring, all requests appertain to this session will fail
session check and the responses generated will contain
Enrico,
Well I think I understand how it works now and why you said it is a weird
edge case
>if the server/cluster is down the session cannot expire.
If the server find a session expire, it will close the socket and the
client will try to
reconnect to the ensemble. While it successfully
Enrico,
Thanks for your reply.
Still I cannot understand how session expire detected on client side. The
only codepath
KeeperState.Expired generated is ClientCnxn#onConnected. It seems only
called on
client successfully connected to server. However, session could expire
after connection
Zili,
Sessions expire in the server. If you are not connected to the cluster you
cannot assume that the session is expired.
There is another weird edge case: if the server/cluster is down the session
cannot expire.
Hope that helps
Enrico
Il mar 24 set 2019, 13:54 Zili Chen ha scritto:
> Hi
Hi ZooKeepers,
I want to trace where Watcher.Event.KeeperState.Expired generated and it
seems only generated
when connect to server fails due to exceed session timeout.
Besides, I find code snippet in ClientCnxn as below
void queueEvent(String clientPath, int err, Set
materializedWatchers,
