[infinispan-dev] KeyAffinityService, GroupingConsistentHash et. al. Infinispan tactical APIs

[Mircea Markus]

On 8 May 2013, at 18:11, cotton-ben wrote:

> Hi Infinispan-DEV team,
> 
> Could anyone provide pointers to Infinispan API sample code that could
> assist us w/ our ambition to start building the attached distributed grid
> use-case?
> 
> Any wiki "how-to" (or full code samples) would be especially helpful. 
> Specifically, how to use
> 
> KeyAffinityService,
> GroupingConsistentHash,
> JGroupsTopologyAwareAddress,
> etc.
and in general: https://docs.jboss.org/author/display/ISPN/User+Guide
> 
> would be ideal.
> 
> Thanks,Ben
> 
> 
> 
> /
> by Ben.Cotton at jpmorgan.com   May 8, 2013 9:45 AM
> 
> Ambition =  on an Infinispan 5.3 grid of 4 nodes (4 x JVM,  all nodes have
> same IP address, each node has a different socket port)
> 
> 
> I.   distribute/partition a <K,V> set (call it set-A) uniformly across the
> grid and
that would be a distributed cache.
> II.  pin a separate <K,V> set (call it set-B) at exactly 1 node on the grid.
so for this one you'd want all the 4 nodes to be able to read this set and it should always reside on one node only?
If I got your requirements correctly you might use either the grouping API. You might use the same cache as I., or if you don't need redundant copies configure a different distributed cache with numOwner=1

> 
> How do I best do this in 5.3?
> 
> Questions:
> 
> JGroupsTopologyAwareAddress - is it configurable to include at least 
> "ip_address+port"?  what is the physical  anatomy of a
> jGroupsTopologyAwareAddress?

you shouldn't need to control this explicitly. This is something we use internally for server hinting: https://docs.jboss.org/author/display/ISPN/ServerHinting 
> 
> GroupingConsistentHash - this looks like a good starting basis for achieving
> our ambition.  Are there code samples that demonstrate how to use this?
Normally you wouldn't need to dig that deep as GroupingConsistentHash, but use a higher level API:
https://docs.jboss.org/author/display/ISPN/The+Grouping+API
> 
> 
> KeyAffinityService - is this API intended to insulate the User from having
> to worry about JGroups specific details?  i.e  If I use the
> KeyAffinityService, can I get away without having to know how to code via
> JGroupsTopologyAwareAddress a/o GroupingConsistentHash?
https://docs.jboss.org/author/display/ISPN/Key+affinity+service

> 
> 
> Once we get our ambition realized in a running Infinispan 5.3 grid instance
> of 4 nodes:
> 
> Assume that node #1 has set-B pinned to it (exclusively).   Is there any way
> that nodes #2,#3,#4 can then operate on set-B *by reference* (sort of like
> RMI operations over a network-stub to the operand implementation), or is it
> necessary that nodes #2,#3,#4 must consume *by value* a copy of set-B into
> its' JVM address space before they can operate on set-B?
on every access on #2,#3 or #4 the values will be brought on demand over the network.
if you modify such a value on e.g. #2 you'd have to re-write it to the cache in order to be updated, so it's up to you if you want by-reference or by-value updates.
> 
> Thanks for any helpful insights, tactics and code samples.
> 
> Thanks,
> Ben
> /
> *by Bela Ban  on May 8, 2013 12:07 PM
> 
> I'll try to address this in generic terms, for details (e.g. which classes
> to use etc) contact the Infinispan team.
> 
> To distribute set A (more or less) evenly across a cluster, use mode=DIST.
> 
> To ping set B to a single node, also use DIST, but set numOwners=1 and plug
> in your own consistent hashing function which pins all keys to a given node.
> E.g. if you have view {M,N,O,P}, the consistent hash could pin all keys to
> the first member of the list, M. This works because every member in a
> cluster has the same view (unless there's a split).
> 
> However, this *will* lead to uneven distribution, so if set B is large, node
> M will bear more of the work than other nodes.
> 
> Also, numOwners=1 is usually only advisable if you can fetch the data from
> somewhere, e.g. a DB, and use the cluster only as a front-end cache to a DB,
> for example.
> 
> You could fix this by setting numOwners=2, and coming up with a consistent
> hash function which always pins the first of the 2 return values, e.g.
> [M->N], [M->O], [M->P], [M->N] etc.
> 
> Once key set B is pinned to M, all access (using DIST) on other nodes will
> be routed to M. Note that you *could* use an L1 cache, which caches locally,
> but you stated you don't want to do that.*
> 
> 
> 
> --
> View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-GroupingConsistentHash-et-al-Infinispan-tactical-APIs-tp4027042.html
> Sent from the Infinispan Developer List mailing list archive at Nabble.com.
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)