org.jgroups.blocks
Class PartitionedHashMap.ConsistentHashFunction<K>

java.lang.Object
  extended by org.jgroups.blocks.PartitionedHashMap.ConsistentHashFunction<K>
All Implemented Interfaces:
PartitionedHashMap.HashFunction<K>, MembershipListener
Enclosing class:
PartitionedHashMap<K,V>

public static class PartitionedHashMap.ConsistentHashFunction<K>
extends java.lang.Object
implements MembershipListener, PartitionedHashMap.HashFunction<K>


Constructor Summary
PartitionedHashMap.ConsistentHashFunction()
           
 
Method Summary
 void block()
          Called (usually by the FLUSH protocol), as an indication that the member should stop sending messages.
 Address hash(K key, java.util.List<Address> members)
          Defines a hash function to pick the right node from the list of cluster nodes.
 void suspect(Address suspected_mbr)
          Called whenever a member is suspected of having crashed, but has not yet been excluded.
 void unblock()
          Called after the FLUSH protocol has unblocked previously blocked senders, and messages can be sent again.
 void viewAccepted(View new_view)
          Called when a change in membership has occurred.
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Constructor Detail

PartitionedHashMap.ConsistentHashFunction

public PartitionedHashMap.ConsistentHashFunction()
Method Detail

hash

public Address hash(K key,
                    java.util.List<Address> members)
Description copied from interface: PartitionedHashMap.HashFunction
Defines a hash function to pick the right node from the list of cluster nodes. Ideally, this function uses consistent hashing, so that the same key maps to the same node despite cluster view changes. If a view change causes all keys to hash to different nodes, then PartitionedHashMap will redirect requests to different nodes and this causes unnecessary overhead.

Specified by:
hash in interface PartitionedHashMap.HashFunction<K>
Parameters:
key - The object to be hashed
members - The membership. This value can be ignored for example if the hash function keeps track of the membership itself, e.g. by registering as a membership listener (PartitionedHashMap.addMembershipListener(org.jgroups.MembershipListener) )
Returns:

viewAccepted

public void viewAccepted(View new_view)
Description copied from interface: MembershipListener
Called when a change in membership has occurred. No long running actions, sending of messages or anything that could block should be done in this callback. If some long running action needs to be performed, it should be done in a separate thread.

Note that on reception of the first view (a new member just joined), the channel will not yet be in the connected state. This only happens when Channel.connect(String) returns.

Specified by:
viewAccepted in interface MembershipListener

suspect

public void suspect(Address suspected_mbr)
Description copied from interface: MembershipListener
Called whenever a member is suspected of having crashed, but has not yet been excluded.

Specified by:
suspect in interface MembershipListener

block

public void block()
Description copied from interface: MembershipListener
Called (usually by the FLUSH protocol), as an indication that the member should stop sending messages. Any messages sent after returning from this callback might get blocked by the FLUSH protocol. When the FLUSH protocol is done, and messages can be sent again, the FLUSH protocol will simply unblock all pending messages. If a callback for unblocking is desired, implement MembershipListener.unblock(). Note that block() is the equivalent of reception of a BlockEvent in the pull mode.

Specified by:
block in interface MembershipListener

unblock

public void unblock()
Description copied from interface: MembershipListener
Called after the FLUSH protocol has unblocked previously blocked senders, and messages can be sent again. This callback only needs to be implemented if we require a notification of that.

Note that during new view installation we provide guarantee that unblock invocation strictly follows view installation at some node A belonging to that view . However, some other message M may squeeze in between view and unblock callbacks. For more details see https://jira.jboss.org/jira/browse/JGRP-986

Specified by:
unblock in interface MembershipListener


Copyright © 1998-2012 Bela Ban / Red Hat. All Rights Reserved.