Re: [infinispan-dev] Hash calculation in DefaultConsistentHash

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(a)jboss.org&gt; wrote: >> >>> From: Manik Surtani <manik(a)jboss.org&gt; >>> Subject: Re: [infinispan-dev] Hash calculation in >>> DefaultConsistentHash >>> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; >>> 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 > > -- > 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 -- Jason T. Greene JBoss, a division of Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev