[infinispan-dev] ISPN-359 and grouping entries for distribution

[galder at jboss.org]

See below:

----- "Manik Surtani" <manik at jboss.org> wrote:

> On 19 May 2010, at 17:44, galder at jboss.org wrote:
> 
> > 
> > ----- "Manik Surtani" <manik at jboss.org> wrote:
> > 
> >> So thinking about this some more, it would seem that there is a
> bit
> >> more to this.  We can add the functionality easily enough, and add
> the
> >> API to the Cache interface.  
> >> 
> >> But would people would reasonably expect this kind of
> functionality
> >> over Hot Rod as well?  And would we need to think about exposing
> this
> >> in Hot Rod too?  Or would this kind of functionality be implemented
> in
> >> the Hot Rod client if needed, so the protocol remains unchanged?
> > 
> > Does the affinity mean that all k,v pairs within an affinity group
> would be stored under the same node in distribution mode? Or this a
> wrong assumption about how affinity works? Judging by
> https://jira.jboss.org/browse/ISPN-312, the grouping is more directed
> at flushing, but https://jira.jboss.org/browse/ISPN-359 suggests it
> could be used for distribution.
> 
> Primarily for affinity with distribution.  I.e., all entries under the
> same affinity key will be colocated on the same server.
> 
> > Bearing in mind I need to clarify my understanding of affinity
> groups, baking it into the protocol means that is less work for
> clients in terms of implementations. If you have 3 client impls, you'd
> have to implement it in all 3. If it's baked in protocol, it's down to
> the server implementation.
> 
> Right, but it also gives clients flexibility in *how* they implement
> affinity.

Not sure whether flexibility would be a good thing here? AFAIK, affinity on a group would be based on the hash of the group name and then find the spot in the wheel? I would imagine server side affinity would do a similar thing. 

I can see however how letting clients how to deal with affinity could speed things up. If an intelligent client can figure out how to make all the data go to the server where it should be stored, it would be faster than handing it over to the server and the server then figuring out how to bundle that into the corresponding node. 
  
> 
> > 
> >> 
> >> On 13 Apr 2010, at 11:01, Manik Surtani wrote:
> >> 
> >>> 
> >>> On 13 Apr 2010, at 10:50, Sanne Grinovero wrote:
> >>> 
> >>>> rightfull concern, I wouldn't personally have expected that but
> >> I'm
> >>>> biased as I follow this thread; it's not hard to imagine some
> >> people
> >>>> falling in this trap.
> >>> 
> >>> 
> >>> Yes; how do we make sure no one falls into this trap?  :)  How
> >> about:
> >>> 
> >>> cache.affinityKey("Blah").put(k, v)
> >>> 
> >>> The problem with "group" or even location/locality/colocation is
> >> that they can all be misconstrued to mean "scope".  With something
> >> like "affinity", I suppose it is clearer?
> >>> 
> >>> WDYT?
> >>> 
> >>> 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
> >> 
> >> --
> >> 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