[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management, distinguish between static and dynamic configuration parameters
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Attachment: ZOOKEEPER-1411-ver10.patch > Consolidate membership management, distinguish between static and dynamic > configuration parameters > -- > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch, ZOOKEEPER-1411-ver10.patch, > ZOOKEEPER-1411-ver2.patch, ZOOKEEPER-1411-ver3.patch, > ZOOKEEPER-1411-ver4.patch, ZOOKEEPER-1411-ver5.patch, > ZOOKEEPER-1411-ver6.patch, ZOOKEEPER-1411-ver7.patch, > ZOOKEEPER-1411-ver8.patch, ZOOKEEPER-1411-ver9.patch > > > Currently every server has a different static configuration file. This patch > distinguishes between dynamic parameters, which are now in a separate > "dynamic configuration file", and static parameters which are in the usual > file. The config file points to the dynamic config file by specifying > "dynamicConfigFile=...". In the first stage (this patch), all cluster > membership definitions are in the dynamic config file, but in the future > additional parameters may be moved to the dynamic file. > Backward compatibility makes sure that you can still use a single config file > if you'd like. Only when the config is changed (once ZK-107 is in) a dynamic > file is automatically created and the necessary parameters are moved to it. > This patch also moves all membership parsing and management into the > QuorumVerifier classes, and removes QuorumPeer.quorumPeers. > The cluster membership is contained in QuorumPeer.quorumVerifier. > QuorumVerifier was expanded and now has methods such as getAllMembers(), > getVotingMembers(), getObservingMembers(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management, distinguish between static and dynamic configuration parameters
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Description: Currently every server has a different static configuration file. This patch distinguishes between dynamic parameters, which are now in a separate "dynamic configuration file", and static parameters which are in the usual file. The config file points to the dynamic config file by specifying "dynamicConfigFile=...". In the first stage (this patch), all cluster membership definitions are in the dynamic config file, but in the future additional parameters may be moved to the dynamic file. Backward compatibility makes sure that you can still use a single config file if you'd like. Only when the config is changed (once ZK-107 is in) a dynamic file is automatically created and the necessary parameters are moved to it. This patch also moves all membership parsing and management into the QuorumVerifier classes, and removes QuorumPeer.quorumPeers. The cluster membership is contained in QuorumPeer.quorumVerifier. QuorumVerifier was expanded and now has methods such as getAllMembers(), getVotingMembers(), getObservingMembers(). was: Currently every server has a different configuration file. With this patch, we will have all cluster membership definitions in a single file, and every sever can have a copy of this file. Summary: Consolidate membership management, distinguish between static and dynamic configuration parameters (was: Consolidate membership management and add client port information) > Consolidate membership management, distinguish between static and dynamic > configuration parameters > -- > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch, ZOOKEEPER-1411-ver10.patch, > ZOOKEEPER-1411-ver2.patch, ZOOKEEPER-1411-ver3.patch, > ZOOKEEPER-1411-ver4.patch, ZOOKEEPER-1411-ver5.patch, > ZOOKEEPER-1411-ver6.patch, ZOOKEEPER-1411-ver7.patch, > ZOOKEEPER-1411-ver8.patch, ZOOKEEPER-1411-ver9.patch > > > Currently every server has a different static configuration file. This patch > distinguishes between dynamic parameters, which are now in a separate > "dynamic configuration file", and static parameters which are in the usual > file. The config file points to the dynamic config file by specifying > "dynamicConfigFile=...". In the first stage (this patch), all cluster > membership definitions are in the dynamic config file, but in the future > additional parameters may be moved to the dynamic file. > Backward compatibility makes sure that you can still use a single config file > if you'd like. Only when the config is changed (once ZK-107 is in) a dynamic > file is automatically created and the necessary parameters are moved to it. > This patch also moves all membership parsing and management into the > QuorumVerifier classes, and removes QuorumPeer.quorumPeers. > The cluster membership is contained in QuorumPeer.quorumVerifier. > QuorumVerifier was expanded and now has methods such as getAllMembers(), > getVotingMembers(), getObservingMembers(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management and add client port information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Description: Currently every server has a different configuration file. With this patch, we will have all cluster membership definitions in a single file, and every sever can have a copy of this file. was: Currently every server has a different configuration file. With this patch, we will have all cluster membership definitions in a single file, and every sever can have a copy of this file. This also solves ZOOKEEPER-1113 > Consolidate membership management and add client port information > - > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch, ZOOKEEPER-1411-ver2.patch, > ZOOKEEPER-1411-ver3.patch, ZOOKEEPER-1411-ver4.patch, > ZOOKEEPER-1411-ver5.patch, ZOOKEEPER-1411-ver6.patch, > ZOOKEEPER-1411-ver7.patch, ZOOKEEPER-1411-ver8.patch, > ZOOKEEPER-1411-ver9.patch > > > Currently every server has a different configuration file. With this patch, > we will have all cluster membership definitions in a single file, and every > sever can have a copy of this file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management and add client port information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Attachment: ZOOKEEPER-1411-ver9.patch > Consolidate membership management and add client port information > - > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch, ZOOKEEPER-1411-ver2.patch, > ZOOKEEPER-1411-ver3.patch, ZOOKEEPER-1411-ver4.patch, > ZOOKEEPER-1411-ver5.patch, ZOOKEEPER-1411-ver6.patch, > ZOOKEEPER-1411-ver7.patch, ZOOKEEPER-1411-ver8.patch, > ZOOKEEPER-1411-ver9.patch > > > Currently every server has a different configuration file. With this patch, > we will have all cluster membership definitions in a single file, and every > sever can have a copy of this file. > This also solves ZOOKEEPER-1113 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management and add client port information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Attachment: ZOOKEEPER-1411-ver8.patch > Consolidate membership management and add client port information > - > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch, ZOOKEEPER-1411-ver2.patch, > ZOOKEEPER-1411-ver3.patch, ZOOKEEPER-1411-ver4.patch, > ZOOKEEPER-1411-ver5.patch, ZOOKEEPER-1411-ver6.patch, > ZOOKEEPER-1411-ver7.patch, ZOOKEEPER-1411-ver8.patch > > > Currently every server has a different configuration file. With this patch, > we will have all cluster membership definitions in a single file, and every > sever can have a copy of this file. > This also solves ZOOKEEPER-1113 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management and add client port information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Attachment: ZOOKEEPER-1411-ver7.patch this should be without tabs and with an updated comment. thanks Rakesh! > Consolidate membership management and add client port information > - > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch, ZOOKEEPER-1411-ver2.patch, > ZOOKEEPER-1411-ver3.patch, ZOOKEEPER-1411-ver4.patch, > ZOOKEEPER-1411-ver5.patch, ZOOKEEPER-1411-ver6.patch, > ZOOKEEPER-1411-ver7.patch > > > Currently every server has a different configuration file. With this patch, > we will have all cluster membership definitions in a single file, and every > sever can have a copy of this file. > This also solves ZOOKEEPER-1113 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management and add client port information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Attachment: ZOOKEEPER-1411-ver6.patch Rakesh's comments are addressed ZOOKEEPER-1411-ver6.patch > Consolidate membership management and add client port information > - > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch, ZOOKEEPER-1411-ver2.patch, > ZOOKEEPER-1411-ver3.patch, ZOOKEEPER-1411-ver4.patch, > ZOOKEEPER-1411-ver5.patch, ZOOKEEPER-1411-ver6.patch > > > Currently every server has a different configuration file. With this patch, > we will have all cluster membership definitions in a single file, and every > sever can have a copy of this file. > This also solves ZOOKEEPER-1113 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management and add client port information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Attachment: ZOOKEEPER-1411-ver5.patch > Consolidate membership management and add client port information > - > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch, ZOOKEEPER-1411-ver2.patch, > ZOOKEEPER-1411-ver3.patch, ZOOKEEPER-1411-ver4.patch, > ZOOKEEPER-1411-ver5.patch > > > Currently every server has a different configuration file. With this patch, > we will have all cluster membership definitions in a single file, and every > sever can have a copy of this file. > This also solves ZOOKEEPER-1113 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management and add client port information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Attachment: ZOOKEEPER-1411-ver4.patch > Consolidate membership management and add client port information > - > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch, ZOOKEEPER-1411-ver2.patch, > ZOOKEEPER-1411-ver3.patch, ZOOKEEPER-1411-ver4.patch > > > Currently every server has a different configuration file. With this patch, > we will have all cluster membership definitions in a single file, and every > sever can have a copy of this file. > This also solves ZOOKEEPER-1113 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management and add client port information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Attachment: ZOOKEEPER-1411-ver3.patch > Consolidate membership management and add client port information > - > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch, ZOOKEEPER-1411-ver2.patch, > ZOOKEEPER-1411-ver3.patch > > > Currently every server has a different configuration file. With this patch, > we will have all cluster membership definitions in a single file, and every > sever can have a copy of this file. > This also solves ZOOKEEPER-1113 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management and add client port information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Attachment: ZOOKEEPER-1411-ver2.patch > Consolidate membership management and add client port information > - > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch, ZOOKEEPER-1411-ver2.patch > > > Currently every server has a different configuration file. With this patch, > we will have all cluster membership definitions in a single file, and every > sever can have a copy of this file. > This also solves ZOOKEEPER-1113 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management and add client port information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Attachment: ZOOKEEPER-1411-ver1.patch > Consolidate membership management and add client port information > - > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1411-ver1.patch > > > Currently every server has a different configuration file. With this patch, > we will have all cluster membership definitions in a single file, and every > sever can have a copy of this file. > This also solves ZOOKEEPER-1113 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1411) Consolidate membership management and add client port information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1411: Issue Type: Sub-task (was: Improvement) Parent: ZOOKEEPER-107 > Consolidate membership management and add client port information > - > > Key: ZOOKEEPER-1411 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1411 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > > Currently every server has a different configuration file. With this patch, > we will have all cluster membership definitions in a single file, and every > sever can have a copy of this file. > This also solves ZOOKEEPER-1113 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-107) Allow dynamic changes to server cluster membership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-107: --- Attachment: ZOOKEEPER-107-1-Mar.patch not for inclusion. - added backward compatibility mode for configuration files: the feature generally requires that the config file points to a separate membership file (where the server, group and weight definitions are supposed to be), but will now also work with a standard single config file. In that case, if a reconfiguration happens, we create a membership file and edit the config file to point to the new membership file. Otherwise the config file remains unchanged. - Fixed small problem in C client > Allow dynamic changes to server cluster membership > -- > > Key: ZOOKEEPER-107 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: Patrick Hunt >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: SimpleAddition.rtf, ZOOKEEPER-107-1-Mar.patch, > ZOOKEEPER-107-28-Feb.patch, ZOOKEEPER-107-28-Feb.patch, > ZOOKEEPER-107-29-Feb.patch, zoo_replicated1.cfg, zoo_replicated1.members, > zookeeper-3.4.0.jar, zookeeper-dev-fatjar.jar, > zookeeper-reconfig-sep11.patch, zookeeper-reconfig-sep12.patch > > > Currently cluster membership is statically defined, adding/removing hosts > to/from the server cluster dynamically needs to be supported. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-107) Allow dynamic changes to server cluster membership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-107: --- Attachment: ZOOKEEPER-107-29-Feb.patch > Allow dynamic changes to server cluster membership > -- > > Key: ZOOKEEPER-107 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: Patrick Hunt >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: SimpleAddition.rtf, ZOOKEEPER-107-28-Feb.patch, > ZOOKEEPER-107-28-Feb.patch, ZOOKEEPER-107-29-Feb.patch, zoo_replicated1.cfg, > zoo_replicated1.members, zookeeper-3.4.0.jar, zookeeper-dev-fatjar.jar, > zookeeper-reconfig-sep11.patch, zookeeper-reconfig-sep12.patch > > > Currently cluster membership is statically defined, adding/removing hosts > to/from the server cluster dynamically needs to be supported. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-107) Allow dynamic changes to server cluster membership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-107: --- Attachment: ZOOKEEPER-107-28-Feb.patch > Allow dynamic changes to server cluster membership > -- > > Key: ZOOKEEPER-107 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: Patrick Hunt >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: SimpleAddition.rtf, ZOOKEEPER-107-28-Feb.patch, > ZOOKEEPER-107-28-Feb.patch, zoo_replicated1.cfg, zoo_replicated1.members, > zookeeper-3.4.0.jar, zookeeper-dev-fatjar.jar, > zookeeper-reconfig-sep11.patch, zookeeper-reconfig-sep12.patch > > > Currently cluster membership is statically defined, adding/removing hosts > to/from the server cluster dynamically needs to be supported. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-107) Allow dynamic changes to server cluster membership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-107: --- Attachment: ZOOKEEPER-107-28-Feb.patch This is not intended for inclusion at this point, just the current version that people can play with. > Allow dynamic changes to server cluster membership > -- > > Key: ZOOKEEPER-107 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: Patrick Hunt >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: SimpleAddition.rtf, ZOOKEEPER-107-28-Feb.patch, > zoo_replicated1.cfg, zoo_replicated1.members, zookeeper-3.4.0.jar, > zookeeper-dev-fatjar.jar, zookeeper-reconfig-sep11.patch, > zookeeper-reconfig-sep12.patch > > > Currently cluster membership is statically defined, adding/removing hosts > to/from the server cluster dynamically needs to be supported. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOKEEPER-1355-ver9-1.patch small javadoc fix. see comment for ZOOKEEPER-1355-ver9.patch > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1355-ver2.patch, ZOOKEEPER-1355-ver4.patch, > ZOOKEEPER-1355-ver5.patch, ZOOKEEPER-1355-ver6.patch, > ZOOKEEPER-1355-ver7.patch, ZOOKEEPER-1355-ver8.patch, > ZOOKEEPER-1355-ver9-1.patch, ZOOKEEPER-1355-ver9.patch, > ZOOKEEPER=1355-ver3.patch, ZOOOKEEPER-1355-test.patch, > ZOOOKEEPER-1355-ver1.patch, ZOOOKEEPER-1355.patch, > loadbalancing-more-details.pdf, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOKEEPER-1355-ver9.patch ZOOKEEPER-1355-ver9 applies for zookeeper-3.4.3 and trunk and fixes issues raised on review-board https://reviews.apache.org/r/3781 > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1355-ver2.patch, ZOOKEEPER-1355-ver4.patch, > ZOOKEEPER-1355-ver5.patch, ZOOKEEPER-1355-ver6.patch, > ZOOKEEPER-1355-ver7.patch, ZOOKEEPER-1355-ver8.patch, > ZOOKEEPER-1355-ver9.patch, ZOOKEEPER=1355-ver3.patch, > ZOOOKEEPER-1355-test.patch, ZOOOKEEPER-1355-ver1.patch, > ZOOOKEEPER-1355.patch, loadbalancing-more-details.pdf, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOKEEPER-1355-ver8.patch added a fix for ZOOKEEPER-1357 > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1355-ver2.patch, ZOOKEEPER-1355-ver4.patch, > ZOOKEEPER-1355-ver5.patch, ZOOKEEPER-1355-ver6.patch, > ZOOKEEPER-1355-ver7.patch, ZOOKEEPER-1355-ver8.patch, > ZOOKEEPER=1355-ver3.patch, ZOOOKEEPER-1355-test.patch, > ZOOOKEEPER-1355-ver1.patch, ZOOOKEEPER-1355.patch, > loadbalancing-more-details.pdf, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOKEEPER-1355-ver7.patch > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1355-ver2.patch, ZOOKEEPER-1355-ver4.patch, > ZOOKEEPER-1355-ver5.patch, ZOOKEEPER-1355-ver6.patch, > ZOOKEEPER-1355-ver7.patch, ZOOKEEPER=1355-ver3.patch, > ZOOOKEEPER-1355-test.patch, ZOOOKEEPER-1355-ver1.patch, > ZOOOKEEPER-1355.patch, loadbalancing-more-details.pdf, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOKEEPER-1355-ver6.patch Hi, thanks for the comments!! I removed getCurrentHost, added a JavaDoc for updateServerList, and a paragraph to the documentation. I can do the C client changes (although, after looking at the code, this scares me a bit :) ) sometime next week or the following one. I also prefer this to be in a separate Jira. To clarify the rules some more, let me give you a few examples (this also appears in different levels of details in the javadoc and documentation I added to the code). First, in case the current host to which the client is connected is not in the new list updateServerList will always cause the connection to be dropped. Otherwise, the decision is based on whether the number of servers has increased or decreased and by how much. Suppose that the previous connection string contained 3 hosts and now the list contains these 3 hosts and 2 more hosts, 40% of clients connected to each of the 3 hosts will move to one of the new hosts in order to balance the load. The algorithm will cause the client to drop its connection to the current host to which it is connected with probability 0.4 (= 1 - 3/5, rule 1) and in this case cause the client to connect to one of the 2 new hosts, chosen at random. Another example - suppose we have 5 hosts and now update the list to remove 2 of the hosts, the clients connected to the 3 remaining hosts will stay connected (rule 3), whereas all clients connected to the 2 removed hosts will need to move to one of the 3 hosts, chosen at random. In this case, the formula in rule 4 simply gives 1 (3(5-3)/(3*2)) since no new servers were added, so clients connected to the removed hosts have no choice but connecting to the 3 old servers. These rules also take into account the case where servers are both added and removed at the same time, and that's why rule 4 doesn't always give probability 1. If the connection is dropped, the client moves to a special mode where he chooses a new server to connect to using the probabilistic algorithm, and not jus round robin. In the first example, each client decides to disconnect from the current host with probability 0.4 but once the decision is made, it will try to connect to a random NEW server and only if it cannot connect to any of the new servers will it try to connect to the old ones. After finding a server, or trying all servers in the new list and failing to connect, the client moves back to the normal mode of operation where it will pick an arbitrary server from the connectString and attempt to connect to it. > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1355-ver2.patch, ZOOKEEPER-1355-ver4.patch, > ZOOKEEPER-1355-ver5.patch, ZOOKEEPER-1355-ver6.patch, > ZOOKEEPER=1355-ver3.patch, ZOOOKEEPER-1355-test.patch, > ZOOOKEEPER-1355-ver1.patch, ZOOOKEEPER-1355.patch, > loadbalancing-more-details.pdf, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.j
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOKEEPER-1355-ver5.patch > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1355-ver2.patch, ZOOKEEPER-1355-ver4.patch, > ZOOKEEPER-1355-ver5.patch, ZOOKEEPER=1355-ver3.patch, > ZOOOKEEPER-1355-test.patch, ZOOOKEEPER-1355-ver1.patch, > ZOOOKEEPER-1355.patch, loadbalancing-more-details.pdf, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOKEEPER-1355-ver4.patch ZOOKEEPER-1355-ver4.patch addresses Ben's comments. The synchronization now allows multiple threads updating the server list and another single thread trying to connect (calling next) as before. > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1355-ver2.patch, ZOOKEEPER-1355-ver4.patch, > ZOOKEEPER=1355-ver3.patch, ZOOOKEEPER-1355-test.patch, > ZOOOKEEPER-1355-ver1.patch, ZOOOKEEPER-1355.patch, > loadbalancing-more-details.pdf, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1365) Removing a duplicate function and another minor cleanup in QuorumPeer.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1365: Attachment: ZOOKEEPER-1365.patch trivial patch - no tests included > Removing a duplicate function and another minor cleanup in QuorumPeer.java > -- > > Key: ZOOKEEPER-1365 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1365 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer >Priority: Trivial > Attachments: ZOOKEEPER-1365.patch, ZOOKEEPER-1365.patch > > > - getMyId() and getId() in QuorumPeer are doing the same thing > - QuorumPeer.quorumPeers is being read directly from outside QuorumPeer, > although we have the getter QuorumPeers.getView(). > The purpose of this cleanup is to later be able to change more easily the way > QuorumPeer manages its list of peers (to support dynamic changes in this > list). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1365) Removing a duplicate function and another minor cleanup in QuorumPeer.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1365: Attachment: ZOOKEEPER-1365.patch > Removing a duplicate function and another minor cleanup in QuorumPeer.java > -- > > Key: ZOOKEEPER-1365 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1365 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer >Priority: Trivial > Attachments: ZOOKEEPER-1365.patch > > > - getMyId() and getId() in QuorumPeer are doing the same thing > - QuorumPeer.quorumPeers is being read directly from outside QuorumPeer, > although we have the getter QuorumPeers.getView(). > The purpose of this cleanup is to later be able to change more easily the way > QuorumPeer manages its list of peers (to support dynamic changes in this > list). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: loadbalancing-more-details.pdf some more details added to the design document. Would be great if more committers comment on this patch. thanks a lot, alex > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1355-ver2.patch, ZOOKEEPER=1355-ver3.patch, > ZOOOKEEPER-1355-test.patch, ZOOOKEEPER-1355-ver1.patch, > ZOOOKEEPER-1355.patch, loadbalancing-more-details.pdf, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOKEEPER=1355-ver3.patch > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1355-ver2.patch, ZOOKEEPER=1355-ver3.patch, > ZOOOKEEPER-1355-test.patch, ZOOOKEEPER-1355-ver1.patch, > ZOOOKEEPER-1355.patch, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOKEEPER-1355-ver2.patch > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1355-ver2.patch, ZOOOKEEPER-1355-test.patch, > ZOOOKEEPER-1355-ver1.patch, ZOOOKEEPER-1355.patch, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOOKEEPER-1355-test.patch > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOOKEEPER-1355-test.patch, ZOOOKEEPER-1355-ver1.patch, > ZOOOKEEPER-1355.patch, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOOKEEPER-1355-ver1.patch > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOOKEEPER-1355-ver1.patch, ZOOOKEEPER-1355.patch, > loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: ZOOOKEEPER-1355.patch > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOOKEEPER-1355.patch, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1358) In StaticHostProviderTest.java, testNextDoesNotSleepForZero tests that hostProvider.next(0) doesn't sleep by checking that the latency of this call is less than 10sec
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1358: Attachment: ZOOKEEPER-1358.patch > In StaticHostProviderTest.java, testNextDoesNotSleepForZero tests that > hostProvider.next(0) doesn't sleep by checking that the latency of this call > is less than 10sec > -- > > Key: ZOOKEEPER-1358 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1358 > Project: ZooKeeper > Issue Type: Bug >Reporter: Alexander Shraer >Assignee: Alexander Shraer >Priority: Trivial > Fix For: 3.2.3 > > Attachments: ZOOKEEPER-1358.patch, ZOOKEEPER-1358.patch > > > should check for something smaller, perhaps 1ms or 5ms -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1358) In StaticHostProviderTest.java, testNextDoesNotSleepForZero tests that hostProvider.next(0) doesn't sleep by checking that the latency of this call is less than 10sec
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1358: Attachment: ZOOKEEPER-1358.patch > In StaticHostProviderTest.java, testNextDoesNotSleepForZero tests that > hostProvider.next(0) doesn't sleep by checking that the latency of this call > is less than 10sec > -- > > Key: ZOOKEEPER-1358 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1358 > Project: ZooKeeper > Issue Type: Bug >Reporter: Alexander Shraer >Assignee: Alexander Shraer >Priority: Trivial > Fix For: 3.2.3 > > Attachments: ZOOKEEPER-1358.patch > > > should check for something smaller, perhaps 1ms or 5ms -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1357) Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port for leader in two different tests. The second test periodically fails complaining that th
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shraer updated ZOOKEEPER-1357:
Attachment: reconfig-8-jan.patch
> Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port
> for leader in two different tests. The second test periodically fails
> complaining that the port is still in use.
> -
>
> Key: ZOOKEEPER-1357
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1357
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Alexander Shraer
>Priority: Minor
> Attachments: reconfig-8-jan.patch
>
>
> Here's what I get:
> Testcase: testLeaderInConnectingFollowers took 34.117 sec
> Testcase: testLastAcceptedEpoch took 0.047 sec<- new
> test added in ZK-1343
> Testcase: testLeaderInElectingFollowers took 0.004 sec
> Caused an ERROR
> Address already in use
> java.net.BindException: Address already in use
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
> at java.net.ServerSocket.bind(ServerSocket.java:328)
> at java.net.ServerSocket.(ServerSocket.java:194)
> at java.net.ServerSocket.(ServerSocket.java:106)
> at org.apache.zookeeper.server.quorum.Leader.(Leader.java:220)
> at
> org.apache.zookeeper.server.quorum.Zab1_0Test.createLeader(Zab1_0Test.java:711)
> at
> org.apache.zookeeper.server.quorum.Zab1_0Test.testLeaderInElectingFollowers(Zab1_0Test.java:225)
> Testcase: testNormalFollowerRun took 29.128 sec
> Testcase: testNormalRun took 25.158 sec
> Testcase: testLeaderBehind took 25.148 sec
> Testcase: testAbandonBeforeACKEpoch took 34.029 sec
> My guess is that testLastAcceptedEpoch doesn't properly close the connection
> before testLeaderInElectingFollowers starts.
> I propose to add
> if (leadThread != null) {
> leadThread.interrupt();
> leadThread.join();
> }
> to the test.
> In addition, I propose to change the hard-wired ports in Zab1_0Test to use
> Portassignment.unique() as done in other tests. If I understand correctly the
> static counter used in unique() to assign ports is initialized once per test
> file, so it would also prevent the problem I'm seeing here of two tests in
> the same file trying to use the same port.
> The error can be reproduced using the attached patch (for some reason I don't
> see the problem in the trunk).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1355: Attachment: loadbalancing.pdf > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1293) Remove unused readyToStart from Leader.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1293: Attachment: ZOOKEEPER-1293-ver2.patch > Remove unused readyToStart from Leader.java > --- > > Key: ZOOKEEPER-1293 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1293 > Project: ZooKeeper > Issue Type: Bug > Components: server, tests >Reporter: Alexander Shraer >Assignee: Alexander Shraer >Priority: Trivial > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1293-ver2.patch, ZOOKEEPER-1293-ver2.patch, > ZOOKEEPER-1293.patch > > > After ZOOKEEPER-1194 readyToStart is no longer used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1293) Remove unused readyToStart from Leader.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1293: Attachment: ZOOKEEPER-1293-ver2.patch > Remove unused readyToStart from Leader.java > --- > > Key: ZOOKEEPER-1293 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1293 > Project: ZooKeeper > Issue Type: Bug > Components: server, tests >Reporter: Alexander Shraer >Assignee: Alexander Shraer >Priority: Trivial > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1293-ver2.patch, ZOOKEEPER-1293.patch > > > After ZOOKEEPER-1194 readyToStart is no longer used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1293) Remove unused readyToStart from Leader.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1293: Attachment: ZOOKEEPER-1293.patch > Remove unused readyToStart from Leader.java > --- > > Key: ZOOKEEPER-1293 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1293 > Project: ZooKeeper > Issue Type: Bug > Components: server, tests >Reporter: Alexander Shraer >Assignee: Alexander Shraer >Priority: Trivial > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1293.patch > > > After ZOOKEEPER-1194 readyToStart is no longer used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1282) Learner.java not following Zab 1.0 protocol - setCurrentEpoch should be done upon receipt of NEWLEADER (before acking it) and not upon receipt of UPTODATE
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shraer updated ZOOKEEPER-1282:
Issue Type: Sub-task (was: Bug)
Parent: ZOOKEEPER-1264
> Learner.java not following Zab 1.0 protocol - setCurrentEpoch should be done
> upon receipt of NEWLEADER (before acking it) and not upon receipt of UPTODATE
> --
>
> Key: ZOOKEEPER-1282
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1282
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: server
>Affects Versions: 3.4.0
>Reporter: Alexander Shraer
>Assignee: Benjamin Reed
>
> according to https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab1.0
> phase 2 part 2, "Once it receives NEWLEADER(e) it atomically applies
> the new state and sets f.currentEpoch =e. "
> In Learner.java self.setCurrentEpoch(newEpoch) is done after receiving
> UPTODATE and not before acking the NEWLEADER message as should be.
> case Leader.UPTODATE:
> if (!snapshotTaken) {
> zk.takeSnapshot();
> }
> self.cnxnFactory.setZooKeeperServer(zk);
> break outerLoop;
> case Leader.NEWLEADER: // it will be NEWLEADER in v1.0
> zk.takeSnapshot();
> snapshotTaken = true;
> writePacket(new QuorumPacket(Leader.ACK,
> newLeaderZxid, null, null), true);
> break;
> }
> }
> }
> long newEpoch = ZxidUtils.getEpochFromZxid(newLeaderZxid);
> self.setCurrentEpoch(newEpoch);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1291) AcceptedEpoch not updated at leader before it proposes the epoch to followers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1291: Issue Type: Sub-task (was: Bug) Parent: ZOOKEEPER-1264 > AcceptedEpoch not updated at leader before it proposes the epoch to followers > - > > Key: ZOOKEEPER-1291 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1291 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Affects Versions: 3.4.0 >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.4.0 > > > It is possible that a leader proposes an epoch e and a follower adopts it by > setting acceptedEpoch to e but the leader itself hasn't yet done so. > While I'm not sure this contradicts Zab (there is no description of where the > leader actually sets its acceptedEpoch), it is very counter intuitive. > The fix is to set acceptedEpoch in getEpochToPropose, i.e., before anyone > LearnerHandler passes the getEpochToPropose barrier. > The fix is done as part of ZK-1264 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1264) FollowerResyncConcurrencyTest failing intermittently
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shraer updated ZOOKEEPER-1264:
Attachment: ZOOKEEPER-ACCEPTEDEPOCH-trunk.patch
> FollowerResyncConcurrencyTest failing intermittently
>
>
> Key: ZOOKEEPER-1264
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264
> Project: ZooKeeper
> Issue Type: Bug
> Components: tests
>Affects Versions: 3.3.3, 3.4.0, 3.5.0
>Reporter: Patrick Hunt
>Assignee: Camille Fournier
>Priority: Blocker
> Fix For: 3.3.4, 3.4.0, 3.5.0
>
> Attachments: ZOOKEEPER-1264-34-bad.patch,
> ZOOKEEPER-1264-branch34.patch, ZOOKEEPER-1264-latest.patch,
> ZOOKEEPER-1264-merge.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch,
> ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch,
> ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch,
> ZOOKEEPER-1264unittest.patch, ZOOKEEPER-ACCEPTEDEPOCH-trunk.patch,
> ZOOKEEPER-ACCEPTEDEPOCH.patch, followerresyncfailure_log.txt.gz, logs.zip,
> tmp.zip
>
>
> The FollowerResyncConcurrencyTest test is failing intermittently.
> saw the following on 3.4:
> {noformat}
> junit.framework.AssertionFailedError: Should have same number of
> ephemerals in both followers expected:<11741> but was:<14001>
>at
> org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400)
>at
> org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196)
>at
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1264) FollowerResyncConcurrencyTest failing intermittently
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shraer updated ZOOKEEPER-1264:
Attachment: ZOOKEEPER-ACCEPTEDEPOCH.patch
> FollowerResyncConcurrencyTest failing intermittently
>
>
> Key: ZOOKEEPER-1264
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264
> Project: ZooKeeper
> Issue Type: Bug
> Components: tests
>Affects Versions: 3.3.3, 3.4.0, 3.5.0
>Reporter: Patrick Hunt
>Assignee: Camille Fournier
>Priority: Blocker
> Fix For: 3.3.4, 3.4.0, 3.5.0
>
> Attachments: ZOOKEEPER-1264-34-bad.patch,
> ZOOKEEPER-1264-branch34.patch, ZOOKEEPER-1264-latest.patch,
> ZOOKEEPER-1264-merge.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch,
> ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch,
> ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch,
> ZOOKEEPER-1264unittest.patch, ZOOKEEPER-ACCEPTEDEPOCH.patch,
> followerresyncfailure_log.txt.gz, logs.zip, tmp.zip
>
>
> The FollowerResyncConcurrencyTest test is failing intermittently.
> saw the following on 3.4:
> {noformat}
> junit.framework.AssertionFailedError: Should have same number of
> ephemerals in both followers expected:<11741> but was:<14001>
>at
> org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400)
>at
> org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196)
>at
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1270) testEarlyLeaderAbandonment failing intermittently, quorum formed, no serving.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1270: Attachment: ZOOKEEPER-1270-and-1194-branch34.patch > testEarlyLeaderAbandonment failing intermittently, quorum formed, no serving. > - > > Key: ZOOKEEPER-1270 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1270 > Project: ZooKeeper > Issue Type: Bug > Components: server >Reporter: Patrick Hunt >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.4.0, 3.5.0 > > Attachments: ZOOKEEPER-1270-and-1194-branch34.patch, > ZOOKEEPER-1270-and-1194.patch, ZOOKEEPER-1270-and-1194.patch, > ZOOKEEPER-1270.patch, ZOOKEEPER-1270.patch, ZOOKEEPER-1270_br34.patch, > ZOOKEEPER-1270tests.patch, ZOOKEEPER-1270tests2.patch, > testEarlyLeaderAbandonment.txt.gz, testEarlyLeaderAbandonment2.txt.gz, > testEarlyLeaderAbandonment3.txt.gz, testEarlyLeaderAbandonment4.txt.gz > > > Looks pretty serious - quorum is formed but no clients can attach. Will > attach logs momentarily. > This test was introduced in the following commit (all three jira commit at > once): > ZOOKEEPER-335. zookeeper servers should commit the new leader txn to their > logs. > ZOOKEEPER-1081. modify leader/follower code to correctly deal with new leader > ZOOKEEPER-1082. modify leader election to correctly take into account current -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1270) testEarlyLeaderAbandonment failing intermittently, quorum formed, no serving.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1270: Attachment: ZOOKEEPER-1270-and-1194.patch > testEarlyLeaderAbandonment failing intermittently, quorum formed, no serving. > - > > Key: ZOOKEEPER-1270 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1270 > Project: ZooKeeper > Issue Type: Bug > Components: server >Reporter: Patrick Hunt >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.4.0, 3.5.0 > > Attachments: ZOOKEEPER-1270-and-1194.patch, > ZOOKEEPER-1270-and-1194.patch, ZOOKEEPER-1270.patch, ZOOKEEPER-1270.patch, > ZOOKEEPER-1270_br34.patch, ZOOKEEPER-1270tests.patch, > ZOOKEEPER-1270tests2.patch, testEarlyLeaderAbandonment.txt.gz, > testEarlyLeaderAbandonment2.txt.gz, testEarlyLeaderAbandonment3.txt.gz, > testEarlyLeaderAbandonment4.txt.gz > > > Looks pretty serious - quorum is formed but no clients can attach. Will > attach logs momentarily. > This test was introduced in the following commit (all three jira commit at > once): > ZOOKEEPER-335. zookeeper servers should commit the new leader txn to their > logs. > ZOOKEEPER-1081. modify leader/follower code to correctly deal with new leader > ZOOKEEPER-1082. modify leader election to correctly take into account current -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1270) testEarlyLeaderAbandonment failing intermittently, quorum formed, no serving.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1270: Attachment: ZOOKEEPER-1270-and-1194.patch I'm attaching an alternative patch to this. > testEarlyLeaderAbandonment failing intermittently, quorum formed, no serving. > - > > Key: ZOOKEEPER-1270 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1270 > Project: ZooKeeper > Issue Type: Bug > Components: server >Reporter: Patrick Hunt >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.4.0, 3.5.0 > > Attachments: ZOOKEEPER-1270-and-1194.patch, ZOOKEEPER-1270.patch, > ZOOKEEPER-1270.patch, ZOOKEEPER-1270_br34.patch, ZOOKEEPER-1270tests.patch, > ZOOKEEPER-1270tests2.patch, testEarlyLeaderAbandonment.txt.gz, > testEarlyLeaderAbandonment2.txt.gz, testEarlyLeaderAbandonment3.txt.gz, > testEarlyLeaderAbandonment4.txt.gz > > > Looks pretty serious - quorum is formed but no clients can attach. Will > attach logs momentarily. > This test was introduced in the following commit (all three jira commit at > once): > ZOOKEEPER-335. zookeeper servers should commit the new leader txn to their > logs. > ZOOKEEPER-1081. modify leader/follower code to correctly deal with new leader > ZOOKEEPER-1082. modify leader election to correctly take into account current -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
