[infinispan-dev] Hash calculation in DefaultConsistentHash

[Manik Surtani]

On 13 Oct 2009, at 15:30, Jason T. Greene wrote:

> We've always had that requirement. Hes referring to classes which do  
> not
> define a hashCode, and thus inherit Object.hashCode(), which  
> produces a
> number based on the reference pointer which is different per-vm.

Sure, but for folks that don't expect to be able to retrieve a key  
from anywhere, it should still work.  But that is a weird use case  
anyway, unless the cache is in local mode in which case DIST doesn't  
apply.

>
> Manik Surtani wrote:
>> Hi Alex.  Looks good - except for the name collision, as you
>> mentioned :)
>>
>> You mentioned (in ReHash.java) that "It is important that ... and not
>> use the Object hashcode.".  Could you explain this a bit more?   
>> Again,
>> this is not something we can mandate, since folks could use JDK types
>> as keys (Integer, String, even Object).
>>
>> Cheers
>> Manik
>>
>>
>> On 12 Oct 2009, at 06:54, Alex Kluge wrote:
>>
>>> Hi,
>>>
>>> I had a few moments to do a bit of reading on the desirable traits
>>> of such a hash function, and I have modified the proof of concept
>>> to to utilize the key's hash function, then use another hash to
>>> ensure a uniform distribution of hashes. It also supports the
>>> injection of a different hash function. As before, it is at the
>>> bottom of
>>>
>>> http://www.vizitsolutions.com/ConsistentHashingCaching.html
>>>
>>> Of course after I uploaded it, I saw the (almost) name collision
>>> with ReHash...
>>>
>>>                                            Alex
>>>
>>>
>>> --- On Thu, 10/1/09, Manik Surtani <manik at jboss.org> wrote:
>>>
>>>> From: Manik Surtani <manik at jboss.org>
>>>> Subject: Re: [infinispan-dev] Hash calculation in
>>>> DefaultConsistentHash
>>>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>>>> Date: Thursday, October 1, 2009, 12:15 PM
>>>>
>>>> On 1 Oct 2009, at 17:55, Alex Kluge wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>  Thanks for the comments.
>>>>>
>>>>>  On item 1:
>>>>>   I chose the way we use the hashing to
>>>> fit in with the
>>>>> current Dell-MessageOne use cases. It is an easy
>>>> change to use
>>>>> a different hash in the locate method , you just want
>>>> to be careful
>>>>> about getting uniform distributions of values, as this
>>>> determines the
>>>>> distribution of key/value pairs among the caches. So
>>>> you exchange
>>>>> one requirement for another. I could even implement a
>>>> strategy pattern
>>>>> here to make it very adaptable.
>>>>>
>>>>>  For generating the original bins in the
>>>> constructor, however, it is
>>>>> important to use a representation that is malliable,
>>>> like a string, to
>>>>> generate the virtual nodes. For the server class you
>>>> also have
>>>>> complete
>>>>> control so it is a reasonable restriction.
>>>> Yes, this is fine for the Address type.  Just that we
>>>> can't depend on
>>>> meaningful toString() impls on keys.  The only thing
>>>> we can really
>>>> rely on (which we can reasonably expect users to implement)
>>>> is hashcode
>>>> ().  So what would be ideal is to take the hashcode()
>>>> generated by the
>>>> user's algo, and use a bit spreader to ensure it is
>>>> properly
>>>> distributed.  A bit like the way JDKs do with HashMap,
>>>> etc.  I'm open
>>>> to suggestions as to the bit spreader algo to use.
>>>>
>>>>
>>>> Cheers
>>>> --
>>>> Manik Surtani
>>>> manik at jboss.org
>>>> Lead, Infinispan
>>>> Lead, JBoss Cache
>>>> http://www.infinispan.org
>>>> http://www.jbosscache.org
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> -- 
> Jason T. Greene
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org