PendingRangeCalculatorService (apache-cassandra API)
Date: 2014-10-21

org.apache.cassandra.service

## Class PendingRangeCalculatorService

- java.lang.Object
- - org.apache.cassandra.service.PendingRangeCalculatorService

-     public class PendingRangeCalculatorService
      extends java.lang.Object

- - ### Field Summary

    Fields
    Modifier and Type | Field and Description
    --- | ---
    `static PendingRangeCalculatorService` | `instance`

  - ### Constructor Summary

    Constructors
    Constructor and Description
    `PendingRangeCalculatorService()`

  - ### Method Summary

    Methods
    Modifier and Type | Method and Description
    --- | ---
    `void` | `blockUntilFinished()`
    `static void` | `calculatePendingRanges(AbstractReplicationStrategy strategy, java.lang.String keyspaceName)` Calculate pending ranges according to bootsrapping and leaving nodes.
    `java.util.concurrent.Future<?>` | `update()`

    - ### Methods inherited from class java.lang.Object

      `clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

- - ### Field Detail

    - #### instance

          public static final PendingRangeCalculatorService instance

  - ### Constructor Detail

    - #### PendingRangeCalculatorService

          public PendingRangeCalculatorService()

  - ### Method Detail

    - #### update

          public java.util.concurrent.Future<?> update()

    - #### blockUntilFinished

          public void blockUntilFinished()

    - #### calculatePendingRanges

          public static void calculatePendingRanges(AbstractReplicationStrategy strategy,
                                    java.lang.String keyspaceName)

      Calculate pending ranges according to bootsrapping and leaving nodes. Reasoning is: (1) When in doubt, it is better to write too much to a node than too little. That is, if there are multiple nodes moving, calculate the biggest ranges a node could have. Cleaning up unneeded data afterwards is better than missing writes during movement. (2) When a node leaves, ranges for other nodes can only grow (a node might get additional ranges, but it will not lose any of its current ranges as a result of a leave). Therefore we will first remove _all_ leaving tokens for the sake of calculation and then check what ranges would go where if all nodes are to leave. This way we get the biggest possible ranges with regard current leave operations, covering all subsets of possible final range values. (3) When a node bootstraps, ranges of other nodes can only get smaller. Without doing complex calculations to see if multiple bootstraps overlap, we simply base calculations on the same token ring used before (reflecting situation after all leave operations have completed). Bootstrapping nodes will be added and removed one by one to that metadata and checked what their ranges would be. This will give us the biggest possible ranges the node could have. It might be that other bootstraps make our actual final ranges smaller, but it does not matter as we can clean up the data afterwards. NOTE: This is heavy and ineffective operation. This will be done only once when a node changes state in the cluster, so it should be manageable.

Copyright © 2014 The Apache Software Foundation