[
https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193999#comment-13193999
]
Benjamin Reed commented on ZOOKEEPER-1355:
------------------------------------------
i'll let alex provide a better answer, but just to test my understanding:
the scary math symbols boil down to a simple set of 4 rules for maintaining
balanced load when the serverList changes. (the rules are at the end of the
document) if you try to do something naive, like randomly disconnecting from
the server you are connecting to, it will cause lots of reconnects and you
still will end up with imbalanced load. it all boils down to four simple rules
for determining when to disconnect from your current host. the math is just
there so that it is clear that it wasn't pulled from thin air.
as far as the public api. we have to add the updateServerList since that is the
whole point of the bug. i have no strong feelings about getCurrentHost() in
terms of the name or making it public. it is only different from
testableRemoteSocketAddress in the sense that testableRemoteSocketAddress says
that it should only be used for testing in the javadoc. alex should add javadoc
to those two methods.
i agree that we should also get a C client. alex are you willing to do that?
can we do it in a separate jira?
> 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
