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(a)jboss.org> wrote:
> From: Manik Surtani <manik(a)jboss.org>
> Subject: Re: [infinispan-dev] Hash calculation in
> DefaultConsistentHash
> To: "infinispan -Dev List" <infinispan-dev(a)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(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
>
http://www.infinispan.org
>
http://www.jbosscache.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev