[
https://issues.apache.org/jira/browse/ZOOKEEPER-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108346#comment-13108346
]
Hadoop QA commented on ZOOKEEPER-1194:
--------------------------------------
+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12495185/zookeeper-1194-ver1.patch
against trunk revision 1172406.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 3 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9)
warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/566//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/566//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/566//console
This message is automatically generated.
> Two possible race conditions during leader establishment
> --------------------------------------------------------
>
> Key: ZOOKEEPER-1194
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1194
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.4.0
> Reporter: Alexander Shraer
> Assignee: Alexander Shraer
> Fix For: 3.4.0
>
> Attachments: zookeeper-1194-ver1.patch, zookeeper-1194.patch
>
>
> Leader.getEpochToPropose() and Leader.waitForNewEpoch() act as barriers -
> they make sure that a leader/follower can return from calling the method only
> once connectingFollowers (or electingFollowers) contain a quorum. But these
> methods don't make sure that the leader itself is in
> connectingFollowers/electingFollowers. So the leader didn't necessarily reach
> the barrier when followers pass it. This can cause the following problems:
> 1. If the leader is not in connectingFollowers when a LearnerHandler returns
> from getEpochToPropose(), then the epoch sent by the leader to the follower
> might be smaller than the leader's own last accepted epoch.
> 2. If the leader is not in electingFollowers when LearnerHandler returns from
> waitForNewEpoch() then the leader will send a NEWLEADER message to followers,
> and the followers will respond, but it is possible that the NEWLEADER message
> is not in outstandingProposals when these NEWLEADER acks arrive, which will
> cause the NEWLEADER acks to be dropped.
> To fix this I propose to explicitly check that the leader is in
> connectingFollowers/electingFollowers before anyone can pass these barriers.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
