>
> the case you mention, the session is not really expired unless the quorum
> decides to expire it. So the client assuming that the session expired would
> be wrong to say. It is possible that as soon as you bring up the servers,
> the client reconnects with the same session and the session is s
Mahadev Konar wrote:
Why would you want the session to expire if all the servers are down (which
should not happen unless you kill all the nodes or the datacenter is down) ?
A more likely case is that the client port on the switch dies and the
client is partitioned from the servers...
Patric
Kevin,
the case you mention, the session is not really expired unless the quorum
decides to expire it. So the client assuming that the session expired would
be wrong to say. It is possible that as soon as you bring up the servers,
the client reconnects with the same session and the session is stil
>
> The ZK ensemble leader expires the client session if it doesn't hear from
> the client w/in the timeout specified by the client when the session was
> established.
>
> A client will disconnect from a server in the ensemble and attempt
> reconnect to another server in the ensemble if it doesn't
Kevin Burton wrote:
From what I can tell, a session will only expire if it can't communicate
with the ensemble due to the entire servers failing or the network splitting
preventing a ZK node from seeing the servers.
Correct?
The ZK ensemble leader expires the client session if it doesn't hear
>From what I can tell, a session will only expire if it can't communicate
with the ensemble due to the entire servers failing or the network splitting
preventing a ZK node from seeing the servers.
Correct?
Then in this case, an application should in theory only care about session
expiration and ZK
