[
https://issues.apache.org/jira/browse/ZOOKEEPER-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716210#comment-13716210
]
Flavio Junqueira commented on ZOOKEEPER-1732:
---------------------------------------------
I think you say that 3 is a more direct way of solving the problem because we
would be enforcing that a follower is following the right instance of the
leader. It is a fair observation, although I tend to think that leader election
is unreliable in nature, so I can really go either way.
Given that you are keen on implementing the changes to the recovery handshake,
what if we try to outline the precise changes in both cases and try to
determine which one to go with once we have that? He are some initial thoughts.
For option 3, we add LE information to the LearnerInfo message. The leader
checks the version of the protocol and uses the new information in LearnerInfo
in the case the protocol version is appropriate. In the case the leader
instance information doesn't match, we have two choices:
# The leader drops the connection to the follower and the follower goes back to
LOOKING;
# The leader sends to the follower the LE instance information and the follower
updates its vote info.
For the second option, I believe we would need a new message, since LEADERINFO
only contains a zxid. I'd rather avoid adding another message, though.
If we don't change the recovery handshake and use the other approach I
outlined, then I believe all changes are concentrated in the FLE class, perhaps
some in QuorumPeer as well, I'm not sure. We just need to call
sendNotifications() upon receiving a notification while leading. For a
follower, when receiving a notification from a LEADING server, it checks if its
vote is still valid, updating otherwise.
bq. Is it ok if I prepare a patch with the change in the leader election
process that you suggest?
Sure, it would be great if you could propose a patch, independent of the
approach we end up choosing.
bq. The test case might be a bit tricky, do you have any suggestion for that?
There are some FLE test cases that implement a mock server. I think we should
do something similar here. Instead of trying to reproduce the race, we could
just test that the follower correctly updates its information upon receiving a
notification.
> 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
