]
Galder Zamarreno resolved ISPN-491.
-----------------------------------
Resolution: Done
HotRod Client and server not hashing on the same thing
------------------------------------------------------
Key: ISPN-491
URL:
https://jira.jboss.org/browse/ISPN-491
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 4.1.0.BETA2
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Priority: Critical
Fix For: 4.1.0.CR1
Yesterday while running a demo I spotted an issue with how distribution was working for
Hot Rod clients. Basically, the client is calculating the hash code on the byte[]
that's the key. However, in the server, the byte[] is wrapped behind a class called
CacheKey and in this case, CacheKey's hashcode is computed and hash on that number is
being calculated. This seem to be producing different results which means that the client
is sending requests on a particular key to nodes that the server does not consider to be
owner.
There's two possibilities here: Either, the client wraps the byte[] around a CacheKey
instance and calculate the hash on that, or the server abandons CacheKey and uses the
byte[] directly as key.
I don't think we can use the latter cos there's no such thing as a reasonable
equals for arrays. IOW, you can't just expect to byte[] arrays to be equal if you call
byteArray1.equals(byteArray2). You have to call Arrays.equals(byteArray1, byteArray2).
Besides, the benefit of CacheKey is that it allows us to give a more meaningful toString
representation [1] compared to standard byte[] toString.
[1] override def toString = {
new StringBuilder().append("CacheKey").append("{")
.append("data=").append(Util.printArray(data, true))
.append("}").toString
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: