[
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14106102#comment-14106102
]
Alexander Shraer commented on ZOOKEEPER-2016:
---------------------------------------------
The way I was proposing to take care of the herd effect is on the client side -
don't migrate right away - wait for some short random period of time and then
migrate. On the server side I'm still not convinced that there is a problem - a
server will probably handle it well.
Regarding your suggestion - there is a property of watches that states that a
client is not allowed to see the new value of a znode before it gets a watch
notification about the update. If we update the znode but delay the watch and
the client comes and reads the znode, he'll see the new value and only later
get a watch event (suppose that he did set a watch). To solve that you'd
probably need to delay the write, or delay the read, or show an old value to
the read - all of these seem problematic. I'd worry about it if we see a
problem reported by users or if we can show that there's a problem, but
currently there's no evidence like this.
> Automate client-side rebalancing
> --------------------------------
>
> Key: ZOOKEEPER-2016
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
> Project: ZooKeeper
> Issue Type: Improvement
> Reporter: Hongchao Deng
>
> ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in
> both the C and Java client libraries. However, it requires the client to
> detect a configuration change and call updateServerList with the new
> connection string (see reconfig manual). It may be better if the client just
> indicates that he is interested in this feature when creating a ZK handle and
> we'll detect configuration changes and invoke updateServerList for him
> underneath the hood.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
