[
https://issues.jboss.org/browse/ISPN-1275?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-1275:
------------------------------------
I got it now, if we have a collision (A and B should both get hash id 100, B is moved to
101) and then A leaves, B will get id 100 unless we somehow remember that B was assigned
position 101 before.
The problem is that not all nodes will have the same chain of CHs, if we have a cluster
{A, B} and B and C join in rapid succession A may see ch_0 = {A, B}, ch_1 = {A, B, C},
ch_2 = {A, B, C, D}, while B might see only ch_0 = {A, B} and ch_1 = {A, B, C, D}.
Reassigning to Manik, it turns out the fix isn't the one-liner in
AbstractWheelConsistentHash I was thinking of...
Virtual nodes producing same hash id for two different cluster nodes
--------------------------------------------------------------------
Key: ISPN-1275
URL:
https://issues.jboss.org/browse/ISPN-1275
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 5.0.0.CR8
Reporter: Galder ZamarreƱo
Assignee: Dan Berindei
Priority: Blocker
Fix For: 5.0.0.FINAL
Attachments: hashids.log
While working on ISPN-1273, I've discovered that when virtual nodes are enabled,
ConsistentHash.getHashIds(address) can return the same hash for two different cluster
nodes. Example: with 500 virtual nodes, both NodeA-23181 and NodeB-39177 produce hash id
*5289*. See attached log.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira