>> 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 session expire code
in the response header. On client side, the response is parsed and session
expire error is extracted and thrown to client if there are pending
requests submitted.
Once the session is expired, server will close socket. Depends on how fast
session expiration is (it's not done instantly as it's a quorum operation),
client may either find out session expiration from responses of their
requests, or through reconnection.
On Tue, Sep 24, 2019 at 11:04 AM Zili Chen <wander4...@gmail.com> wrote:
> 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 reconnects to one of the
> ensemble it will find session expire...
>
> You're right that if we lost connection to all the ensemble we cannot even
> notice
> that we are in session expired state. And I think it is the reason why
> Curator
> also check if time has already elapsed over session timeout.
>
> Best,
> tison.
>
>
> Zili Chen <wander4...@gmail.com> 于2019年9月24日周二 下午8:20写道：
>
> > 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
> > established. Where is the latter case trigger?
> >
> > Best,
> > tison.
> >
> >
> > Enrico Olivelli <eolive...@gmail.com> 于2019年9月24日周二 下午8:06写道：
> >
> >> 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 <wander4...@gmail.com> ha scritto:
> >>
> >> > 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<Watcher>
> >> > materializedWatchers, EventType eventType) {
> >> > KeeperState sessionState = KeeperState.SyncConnected;
> >> > if (KeeperException.Code.SESSIONEXPIRED.intValue() == err
> >> > || KeeperException.Code.CONNECTIONLOSS.intValue() == err)
> {
> >> > sessionState = Event.KeeperState.Disconnected;
> >> > }
> >> > WatchedEvent event = new WatchedEvent(eventType, sessionState,
> >> > clientPath);
> >> > eventThread.queueEvent(event, materializedWatchers);
> >> > }
> >> >
> >> > which seems a bit wried to me what we queue
> >> > a Event.KeeperState.Disconnected on
> >> > KeeperException.Code.SESSIONEXPIRED.
> >> >
> >> > Back to the question, how zookeeper discovers and triggers session
> >> expire
> >> > event on
> >> > session expired after connection established successfully?
> >> >
> >> > Best,
> >> > tison.
> >> >
> >>
> >
>
