I would fix the existing MurmurHash; IMO backward compat doesn't extend
to consistent hashing...
Does leaving the 1 bit out create extreme anomalies wrt hashing
distribution ? I wouldn't think so...
I'm fine with the other solution, too.
On 1/13/11 8:35 PM, Manik Surtani wrote:
Guys,
The MurmurHash2 impl we have in 4.2.0 is buggy in that my translation from the original C
source was faulty and it effectively hashes over just 31 bits instead of 32. It means the
distribution result isn't as good as it could be.
Now it isn't that easy for me to just *fix* this in 4.2.1, since it means keys mapped
to nodes using 4.2.0 may not map to the same node in 4.2.1.
So here is what I propose:
1) Fix it in 4.2.x as MurmurHash2A
2) Use MurmurHash2A by default, *unless* a config flag is provided that forces the use of
MurmurHash2. (e.g.,<hash function="MurmurHash2">)
This will even give us the ability to use MurmurHash3 in 5.0 when we have it.
WDYT?
--
Bela Ban
Lead JGroups / Clustering Team
JBoss