[infinispan-dev] Hash calculation in DefaultConsistentHash

Alex Kluge java_kluge at yahoo.com
Mon Oct 12 01:54:08 EDT 2009


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
> 


      




More information about the infinispan-dev mailing list