Details
-
Bug
-
Resolution: Done
-
Critical
-
4.1.0.BETA2
-
None
Description
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("
").toString
}
Attachments
Issue Links
- relates to
-
ISPN-492 Use map implementations that do array equality based on contents
- Closed