zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Han (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-2348) Data between leader and followers are not synchronized.
Date Thu, 15 Jun 2017 17:40:00 GMT

    [ 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)

Mime
View raw message