[infinispan-dev] MurmurHash fixes

[Manik Surtani]

Well, even with a 4.3 we'd still need to provide some form of backward compat.

The last, and most expensive, approach is to use the fixed function, and if a request doesn't find anything, retry with the old function (!)

On 14 Jan 2011, at 08:36, Emmanuel Bernard wrote:

> Or release a 4.3.
> 
> On 14 janv. 2011, at 09:32, Bela Ban wrote:
> 
>> 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
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org