[jira] Updated: (ZOOKEEPER-417) stray message problem when changing servers
[
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] Updated: (ZOOKEEPER-417) stray message problem when changing servers
[
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
[
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
[
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
[
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] Updated: (ZOOKEEPER-417) stray message problem when changing servers
[
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] Updated: (ZOOKEEPER-417) stray message problem when changing servers
[
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
[
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
[
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] Updated: (ZOOKEEPER-417) stray message problem when changing servers
[
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.
[jira] Updated: (ZOOKEEPER-417) stray message problem when changing servers
[
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] Updated: (ZOOKEEPER-417) stray message problem when changing servers
[
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
[
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
[
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] Updated: (ZOOKEEPER-417) stray message problem when changing servers
[
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.
