[
https://issues.apache.org/jira/browse/ZOOKEEPER-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809461#comment-13809461
]
Germán Blanco commented on ZOOKEEPER-1805:
------------------------------------------
The reason why the changes in Vote are not required is because all the Votes
inserted in "outofelection" have the same values for zxid and election epoch.
So the comparison is already based only in the other fields of Vote.
The value "newEpoch - 1" works because we want to get back to the last accepted
epoch of the leader, and the leader is sending the last accepted epoch plus
one. The newEpoch that is sent from the Leader to all learners is calculated in
"getEpochToPropose" in Leader.java. My interpretation of that method is that
the new epoch will always be lastAcceptedEpoch plus one.
There are at least these other alternatives, but they look worse:
- ignoring also peerEpoch in the comparison. Which will have the risk of taking
into account left-over votes of ensembles established before the current one.
- setting peerEpoch to any other value. Has the same problem that we are trying
to fix.
- changing the protocol in order to send lastAcceptedEpoch (and maybe zxid and
election epoch, since the protocol is changed anyway) instead of the new epoch.
I will provide the logs tomorrow.
> "Don't care" value in ZooKeeper election breaks rolling upgrades
> ----------------------------------------------------------------
>
> Key: ZOOKEEPER-1805
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1805
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Flavio Junqueira
> Priority: Blocker
> Attachments: ZOOKEEPER-1805.patch, ZOOKEEPER-1805.patch,
> ZOOKEEPER-1805.patch
>
>
> This is an issue that has been originally reported in ZOOKEEPER-1732.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
