Bug 1118650 - 13.3. Hot Rod Hash Functions, consistent hash function
Summary: 13.3. Hot Rod Hash Functions, consistent hash function
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Documentation
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: GA
: 6.3.0
Assignee: Misha H. Ali
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-11 08:37 UTC by Vitalii Chepeliuk
Modified: 2014-07-21 02:14 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Build Name: 12532, Administration and Configuration Guide-6.3 Build Date: 07-07-2014 11:21:19 Topic ID: 6721-635853 [Latest]
Last Closed: 2014-07-21 02:14:43 UTC
Type: Bug


Attachments (Terms of Use)

Description Vitalii Chepeliuk 2014-07-11 08:37:37 UTC
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

Additional information:

Comment 3 Vitalii Chepeliuk 2014-07-14 07:09:17 UTC
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.

Comment 4 Misha H. Ali 2014-07-14 07:14:48 UTC
Sure, Vitalii. Updating now.

Comment 6 Misha H. Ali 2014-07-21 02:14:43 UTC
Now available on access.redhat.com under the JBoss Data Grid 6.3 documentation label.


Note You need to log in before you can comment on or make changes to this bug.