[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724658#action_12724658 ]
Hadoop QA commented on ZOOKEEPER-417: ------------------------------------- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12411886/ZOOKEEPER-417.patch against trunk revision 788539. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 12 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 warnings. -1 release audit. The applied patch generated 182 release audit warnings (more than the trunk's current 181 warnings). +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/141/testReport/ Release audit warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/141/artifact/trunk/patchprocess/releaseAuditDiffWarnings.txt Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/141/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/141/console This message is automatically generated. > stray message problem when changing servers > ------------------------------------------- > > Key: ZOOKEEPER-417 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-417 > Project: Zookeeper > Issue Type: Bug > Reporter: Benjamin Reed > Assignee: Benjamin Reed > Priority: Blocker > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-417.patch, ZOOKEEPER-417.patch, > ZOOKEEPER-417.patch, ZOOKEEPER-417.patch > > > There is a possibility for stray messages from a previous connection to > violate ordering and generally cause problems. Here is a scenario: we have a > client, C, two followers, F1 and F2, and a leader, L. The client is connected > to F1, which is a slow follower. C sends setData("/a", "1") to F1 and then > loses the connection, so C reconnects to F2 and sends setData("/a", "2"). it > is possible, if F1 is slow enough and the setData("/a", "1") got onto the > network before the connection break, for F1 to forward the setData("/a", "1") > to L after F2 forwards setData("/a", "2"). > to fix this, the leader should keep track of which follower last registered a > session for a client and drop any requests from followers for clients for > whom they do not have a registration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.