You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Benjamin Reed (JIRA)" <ji...@apache.org> on 2009/05/26 20:11:45 UTC
[jira] Created: (ZOOKEEPER-417) stray message problem when changing
servers
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
Fix For: 3.2.0
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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-417:
------------------------------------
Attachment: ZOOKEEPER-417.patch
> 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
>
>
> 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.
[jira] Commented: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724617#action_12724617 ]
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 failed 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/140/testReport/
Release audit warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/140/artifact/trunk/patchprocess/releaseAuditDiffWarnings.txt
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/140/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/140/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.
[jira] Commented: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724838#action_12724838 ]
Hudson commented on ZOOKEEPER-417:
----------------------------------
Integrated in ZooKeeper-trunk #359 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/359/])
. stray message problem when changing servers (breed via mahadev)
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-417:
------------------------------------
Status: Open (was: Patch Available)
> 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
>
>
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mahadev konar updated ZOOKEEPER-417:
------------------------------------
Status: Open (was: Patch Available)
I tried running it on the hudson manually and the tests seems to pass .... ill retry on hudson again to see if the passes the tests... .
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mahadev konar updated ZOOKEEPER-417:
------------------------------------
Status: Open (was: Patch Available)
> 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
>
>
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-417:
------------------------------------
Status: Patch Available (was: Open)
> 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
>
>
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-417:
------------------------------------
Status: Patch Available (was: Open)
> 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
>
>
> 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.
[jira] Commented: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724408#action_12724408 ]
Mahadev konar commented on ZOOKEEPER-417:
-----------------------------------------
+1 to the patch ... ill wait for hudson's +1 before committing.
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-417:
------------------------------------
Status: Patch Available (was: Open)
removed the deprecated member
> 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
>
>
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-417:
------------------------------------
Attachment: ZOOKEEPER-417.patch
implemented mahadev's suggestion
> 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
> 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.
[jira] Commented: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724607#action_12724607 ]
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/139/testReport/
Release audit warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/139/artifact/trunk/patchprocess/releaseAuditDiffWarnings.txt
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/139/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/139/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.
[jira] Commented: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723860#action_12723860 ]
Mahadev konar commented on ZOOKEEPER-417:
-----------------------------------------
ben, the patch doesnt seem to apply. can you update the jira with the patch that applies to trunk?
> 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
>
>
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-417:
------------------------------------
Attachment: ZOOKEEPER-417.patch
> 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
>
>
> 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.
[jira] Assigned: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Patrick Hunt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Hunt reassigned ZOOKEEPER-417:
--------------------------------------
Assignee: Benjamin Reed
> 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
>
>
> 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.
[jira] Commented: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723483#action_12723483 ]
Hadoop QA commented on ZOOKEEPER-417:
-------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12411594/ZOOKEEPER-417.patch
against trunk revision 787907.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 12 new or modified tests.
-1 patch. The patch command could not apply the patch.
Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/130/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
>
>
> 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.
[jira] Commented: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724309#action_12724309 ]
Benjamin Reed commented on ZOOKEEPER-417:
-----------------------------------------
the release audit generates warnings before the way i added the new keeper exception codes. we made the integers deprecated, so i've made the new ones deprecated as well. should i put the integer in the new error code rather than added a new deprecated constant?
i can't find any failed tests in the test results. what am i missing?
> 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
>
>
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Patrick Hunt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Hunt updated ZOOKEEPER-417:
-----------------------------------
Priority: Blocker (was: Major)
> 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
> Priority: Blocker
> Fix For: 3.2.0
>
>
> 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.
[jira] Commented: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724348#action_12724348 ]
Mahadev konar commented on ZOOKEEPER-417:
-----------------------------------------
the patch looks good ... i have some comments --
line 543 in NIOServerCnxn.java
{code}
si.setOwner(zk);
zk.submitRequest(si);
{code}
Can we just use some static final Object adn si.setOwner(Object)?
- Is there any use of using zk specifically? If we just use some static object then we can just say that this will be replaced at the leader with the right follower handler and then is a dummy object in followers and single zookeeper wherein it has no spefic use case... the reason I say this is that its a little confusing to understand the code if we dont have comments here .... also if we can use a dummy object rather than zk, its much cleaner. what do you think?
> 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
>
>
> 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.
[jira] Commented: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724301#action_12724301 ]
Hadoop QA commented on ZOOKEEPER-417:
-------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12411753/ZOOKEEPER-417.patch
against trunk revision 788502.
+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 appears to have generated 1 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 183 release audit warnings (more than the trunk's current 181 warnings).
-1 core tests. The patch failed 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/135/testReport/
Release audit warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/135/artifact/trunk/patchprocess/releaseAuditDiffWarnings.txt
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/135/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/135/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
>
>
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-417:
------------------------------------
Assignee: Benjamin Reed
Status: Patch Available (was: Open)
> 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.
[jira] Commented: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mahadev konar updated ZOOKEEPER-417:
------------------------------------
Status: Patch Available (was: Open)
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-417:
------------------------------------
Assignee: (was: Benjamin Reed)
Status: Open (was: Patch Available)
> 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
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mahadev konar updated ZOOKEEPER-417:
------------------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
I committed this. the -1 from hudson for jdiff is just because we added another error code which is fine.. thanks ben
> 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.
[jira] Commented: (ZOOKEEPER-417) stray message problem when
changing servers
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724312#action_12724312 ]
Mahadev konar commented on ZOOKEEPER-417:
-----------------------------------------
{code}
[exec] Running Zookeeper_clientretry::testRetry
[exec] [exec] make: *** [run-check] Broken pipe
[exec]
[exec] BUILD FAILED
[exec] /home/hudson/hudson-slave/workspace/Zookeeper-Patch-vesta.apache.org/trunk/build.xml:692: The following error occurred while executing this line:
[exec] /home/hudson/hudson-slave/workspace/Zookeeper-Patch-vesta.apache.org/trunk/build.xml:703: exec returned: 2
{code}
I see the above int he console ooutput of the tests.
Also for the depreacted integers we dont need to add them to the deperecated api. We should just add them to the new error code.
> 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
>
>
> 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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing
servers
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-417:
------------------------------------
Attachment: ZOOKEEPER-417.patch
removed a stray change from another patch
> 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
>
>
> 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.