Title: Hot Rod Hash Functions
Describe the issue: following is wrong, now there is no hash wheel
Red Hat JBoss Data Grid uses a consistent hash function to place nodes and, subsequently, their corresponding keys on a hash wheel to determine where entries live.
The hash space value is constant and limited to the maximum 32-bit positive integer value (Integer.MAX_INT). This value is returned to the client using the Hot Rod protocol each time a hash-topology change is detected to prevent Hot Rod clients assuming a specific hash space as a default. The hash space can only contain positive numbers ranging from 0 to Integer.MAX_INT.
When the Hot Rod protocol is used to interact with JBoss Data Grid, the keys (and their values) must be byte arrays to ensure platform neutral behavior. Smart clients (which are aware of hash distribution in the background) must be able to recalculate hash codes of such byte array keys in this platform-neutral manner. To accommodate this, version information for hash functions used in JBoss Data Grid is saved for implementation by non-Java clients, if required.
Suggestions for improvement:
Take information from development docs
Misha can you change text about hashing to this one
The hashing algorithm in JBoss Data Grid is based on consistent hashing, and even though our implementation has diverged a bit, we still use the term consistent hash.
Unlike in consistent hashing, we split the key space into fixed segments. The number of segments is configurable (numSegments), and it cannot be changed without restarting the cluster. The mapping of keys to segments is also fixed — a key should map to the same segment, regardless of how the topology of the cluster changes.
Each hash segment is mapped to a list of nodes called owners. The order matters, because the first owner, also known as the primary owner, has a special role in many cache operations (e.g. locking). The other owners are called backup owners. There is no hard rule on how the segments are mapped to owners, although the hashing algorithms generally try to balance the number of segments allocated to each node and at the same time minimize the number of segments that have to move after a node joins or leaves the cluster.
Sure, Vitalii. Updating now.
Now available on access.redhat.com under the JBoss Data Grid 6.3 documentation label.