[
https://issues.apache.org/jira/browse/ZOOKEEPER-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050836#comment-16050836
]
Michael Han commented on ZOOKEEPER-2348:
----------------------------------------
What client saw depends on how the session is expired. There are two cases:
* Session is expired by client by explicitly calling close which will set the
client state to "closed" and any future requests will yield session expired
exception. I think this is the only case that client might see a session expire
event before the client's session really gets terminated on the quorum. It
would be inconsistent if the current ZK client can reconnect to the new quorum
and find out that the session state changed from expired to reestablished, but
since the current ZK client is already closed, that is not possible. The last
session event the current closed ZK client saw reflects the state of the
session. Other clients will eventually see the removal of the ephemerals
appertained to the closed session as well (and there is no middle state in
between).
* Session is expired because heart beats between client / server failed (e.g.
network partition, server overloaded, client overloaded, and so on). In this
case, client will get connection loss event. When client reconnects to the
quorum, client will first try reestablish the session, which also requires
consensus. Because ordering guarantees, when the quorum processes the request
from this client the session is either already expired by the quorum, or the
session is still valid. In either case, the client would either only see
session expired event after reconnecting (by which time ephemerals are gone
from other client's view as well), or the old state. It is still a consistent
view across all clients.
> Data between leader and followers are not synchronized.
> -------------------------------------------------------
>
> Key: ZOOKEEPER-2348
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2348
> Project: ZooKeeper
> Issue Type: Bug
> Affects Versions: 3.5.1
> Reporter: Echo Chen
>
> When client session expired, leader tried to remove it from session map and
> remove its EPHEMERAL znode, for example, /test_znode. This operation succeed
> on leader, but at the very same time, network fault happended and not synced
> to followers, a new leader election launched. After leader election finished,
> the new leader is not the old leader. we found the znode /test_znode still
> existed in the followers but not on leader
> *Scenario :*
> 1) Create znode E.g.
> {{/rmstore/ZKRMStateRoot/RMAppRoot/application_1449644945944_0001/appattempt_1449644945944_0001_000001}}
> 2) Delete Znode.
> 3) Network fault b/w follower and leader machines
> 4) leader election again and follower became leader.
> Now data is not synced with new leader..After this client is not able to same
> znode.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
