Bug 1118650

Summary:	13.3. Hot Rod Hash Functions, consistent hash function
Product:	[JBoss] JBoss Data Grid 6	Reporter:	Vitalii Chepeliuk <vchepeli>
Component:	Documentation	Assignee:	Misha H. Ali <mhusnain>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.3.0	CC:	jdg-bugs, mhusnain, vchepeli
Target Milestone:	GA
Target Release:	6.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
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
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.