[infinispan-dev] Hash calculation in DefaultConsistentHash
Manik Surtani
manik at jboss.org
Tue Oct 13 06:14:58 EDT 2009
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
More information about the infinispan-dev
mailing list