[
https://issues.apache.org/jira/browse/CASSANDRA-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992045#comment-12992045
]
Nick Bailey commented on CASSANDRA-1427:
----------------------------------------
bq. 2. In StorageService.handleStateMoving store both new token and InetAddress
of the moving node.
Not sure what you mean.
bq. 3. Add following code to
calculatePendingRanges(AbstractReplicationStrategy, String) after
bootstrapToken ranges calculation to track pending ranges of the moving nodes
(almost the same code as for bootstrapping nodes):
I think this is the right approach. Would it be useful to get rid of
'movingRanges' in TMD and simply add nodes that are moving to both the leaving
endpoints and the bootstrap tokens. I think this would remove the need to
change calculate pending ranges at all. I could see how the distinction between
moving and leaving+bootstrap might be easier to follow in the code though.
> Optimize loadbalance/move for moves within the current range
> ------------------------------------------------------------
>
> Key: CASSANDRA-1427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1427
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Affects Versions: 0.7 beta 1
> Reporter: Nick Bailey
> Assignee: Pavel Yaskevich
> Fix For: 0.8
>
> Attachments: CASSANDRA-1427-v2.patch, CASSANDRA-1427.patch
>
> Original Estimate: 42h
> Time Spent: 42h
> Remaining Estimate: 0h
>
> Currently our move/loadbalance operations only implement case 2 of the Ruhl
> algorithm described at
> https://issues.apache.org/jira/browse/CASSANDRA-192#action_12713079.
> We should add functionality to optimize moves that take/give ranges to a
> node's direct neighbors.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
