Class SyncConsistentHashFactory

  • All Implemented Interfaces:
    ConsistentHashFactory<DefaultConsistentHash>
    Direct Known Subclasses:
    TopologyAwareSyncConsistentHashFactory

    public class SyncConsistentHashFactory
    extends Object
    implements ConsistentHashFactory<DefaultConsistentHash>
    One of the assumptions people made on consistent hashing involves thinking that given a particular key and same topology, it would produce the same consistent hash value no matter which cache it was stored in. However, that's not exactly the case in Infinispan. In order to the optimise the number of segments moved on join/leave, Infinispan uses a consistent hash that depends on the previous consistent hash. Given two caches, even if they contain exactly the same keyset, it's very easy for the consistent hash history to differ, e.g. if 2 nodes join you might see two separate topology change in one cache and a single topology change in the other. The reason for that each node has to send a CacheTopologyControlCommand for each cache it wants to join and Infinispan can and does batch cache topology changes. For example, if a rebalance is in progress, joins are queued and send in one go when the rebalance has finished. This ConsistentHashFactory implementation avoids any of the issues mentioned and guarantees that multiple caches with the same members will have the same consistent hash. It has a drawback compared to DefaultConsistentHashFactory though: it can potentially move a lot more segments during a rebalance than strictly necessary because it's not taking advantage of the optimisation mentioned above.
    Since:
    5.2
    Author:
    Dan Berindei
    • Field Detail

      • OWNED_SEGMENTS_ALLOWED_VARIATION

        public static final float OWNED_SEGMENTS_ALLOWED_VARIATION
        See Also:
        Constant Field Values
      • PRIMARY_SEGMENTS_ALLOWED_VARIATION

        public static final float PRIMARY_SEGMENTS_ALLOWED_VARIATION
        See Also:
        Constant Field Values
    • Constructor Detail

      • SyncConsistentHashFactory

        public SyncConsistentHashFactory()
    • Method Detail

      • create

        public DefaultConsistentHash create​(org.infinispan.commons.hash.Hash hashFunction,
                                            int numOwners,
                                            int numSegments,
                                            List<Address> members,
                                            Map<Address,​Float> capacityFactors)
        Description copied from interface: ConsistentHashFactory
        Create a new consistent hash instance. The consistent hash will be balanced.
        Specified by:
        create in interface ConsistentHashFactory<DefaultConsistentHash>
        Parameters:
        hashFunction - The hash function to use on top of the keys' own hashCode() implementation.
        numOwners - The ideal number of owners for each key. The created consistent hash can have more or less owners, but each key will have at least one owner.
        numSegments - Number of hash-space segments. The implementation may round up the number of segments for performance, or may ignore the parameter altogether.
        members - A list of addresses representing the new cache members.
        capacityFactors - The capacity factor of each member. Determines the relative capacity of each node compared to the others. The implementation may ignore this parameter. If null, all the members are assumed to have a capacity factor of 1.
      • updateMembers

        public DefaultConsistentHash updateMembers​(DefaultConsistentHash baseCH,
                                                   List<Address> newMembers,
                                                   Map<Address,​Float> actualCapacityFactors)
        Description copied from interface: ConsistentHashFactory
        Updates an existing consistent hash instance to remove owners that are not in the newMembers list.

        If a segment has at least one owner in newMembers, this method will not add another owner. This guarantees that the new consistent hash can be used immediately, without transferring any state.

        If a segment has no owners in newMembers and the ConsistentHash implementation (e.g. DefaultConsistentHash) requires at least one owner for each segment, this method may add one or more owners for that segment. Since the data in that segment was lost, the new consistent hash can still be used without transferring state.

        Specified by:
        updateMembers in interface ConsistentHashFactory<DefaultConsistentHash>
        Parameters:
        baseCH - An existing consistent hash instance, should not be null
        newMembers - A list of addresses representing the new cache members.
        actualCapacityFactors - The capacity factor of each member. Determines the relative capacity of each node compared to the others. The implementation may ignore this parameter. If null, all the members are assumed to have a capacity factor of 1.
        Returns:
        A new ConsistentHash instance, or baseCH if the existing instance does not need any changes.
      • hashCode

        public int hashCode()
        Overrides:
        hashCode in class Object