[infinispan-dev] Hash calculation in DefaultConsistentHash
Jason T. Greene
jason.greene at redhat.com
Tue Oct 13 10:30:57 EDT 2009
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.
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
More information about the infinispan-dev
mailing list