[
https://issues.apache.org/jira/browse/ZOOKEEPER-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13715069#comment-13715069
]
Germán Blanco commented on ZOOKEEPER-1732:
------------------------------------------
I am thinking that, giving that we don't care if this is solved a few
milliseconds later, one way to handle the backward compatibility issues would
be this:
- Follower/Observer sends an increased protocol number in
FOLLOWERINFO/OBSERVERINFO.
- When the Leader sees the new version, it sends the "LE" epoch and zxid in
LeaderInfo.
- Follower/Observer check if the Leader has an updated protocol version and if
it does, they read the "LE" epoch and zxid from LeaderInfo. If they are not the
same as the "LE" epoch and zxid that they have, they start LOOKING again.
Does that sound ok?
> ZooKeeper server unable to join established ensemble
> ----------------------------------------------------
>
> Key: ZOOKEEPER-1732
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1732
> Project: ZooKeeper
> Issue Type: Bug
> Components: leaderElection
> Affects Versions: 3.4.5
> Environment: Windows 7, Java 1.7
> Reporter: Germán Blanco
> Priority: Blocker
> Fix For: 3.5.0, 3.4.6
>
> Attachments: zklog.tar.gz
>
>
> I have a test in which I do a rolling restart of three ZooKeeper servers and
> it was failing from time to time.
> I ran the tests in a loop until the failure came out and it seems that at
> some point one of the servers is unable to join the enssemble formed by the
> other two.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
