[infinispan-dev] MurmurHash fixes

Bela Ban bban at redhat.com
Fri Jan 14 03:32:31 EST 2011


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


More information about the infinispan-dev mailing list