[
https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184245#comment-13184245
]
Benjamin Reed commented on ZOOKEEPER-1355:
------------------------------------------
this looks really good! i have a couple of requests and something to think
about:
1) you need to use spaces rather than tabs. you have a bunch of tabs in the
patch. (there is a setting in eclipse to do tabs rather than spaces)
2) it would be nice in updateList to comment about the overall strategy for
determining the return code
3) can you add a comment to "(currentIndex >= serverAddresses.size())" to say
why >= is needed? i think i see it in the context of this patch, but later
people might be tempted to change it back to ==
something to think about: on the updateServerList method, perhaps rather than
making the second parameter a boolean we can make it the InetSocketAddress of
the currently connected server. what do you think? i don't feel strongly about
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, 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
