[infinispan-dev] KeyAffinityService

[Dan Berindei]

Ben, I'm pretty sure it's not possible to define getKeyForAddress as
returning the same type as its input key.

Let's say f1(address)(x) = getKeyForAddress(address, x)

f1(address) has to be injective for each address. So if the size of the key
domain is size(K) and the number of addresses is N, the number of unique
output values of getKeyForAddress is N * size(K), which is clearly not
possible.

It's probably possible to define something like this instead:

PinnedKey<K> getKeyForAddress(address, key)


Even so, keeping the result key pinned to the same address after a
rebalance would be tricky - probably requiring some changes to the
ConsistentHash implementation. Of course, the node to which the key is
pinned may also die, and I'm not sure where the keys should be located
then.

For the existing KeyAffinityService methods it's simple: they give you a
key that is currently mapped to a specific node, but they don't make any
guarantees about where that key will be located in the future.

Speaking of which, how do you know which keys should map to which node in
your application?

If the rules are simple enough, you may be able to create multiple caches,
each of them with a custom ConsistentHashFactory that locates *all* the
keys to the same primary node (with random backup owners).

Cheers
Dan


On Fri, Jun 14, 2013 at 3:43 PM, cotton-ben
<ben.cotton at alumni.rutgers.edu>wrote:

> Thanks for this reply, Mircea.
>
> Very interesting approach.  By dispatching a distributed executor back to
> the node (node 0) that produced the pinned key affinity for the object's
> natural key, we could indeed do an iterative search (from node 2) to find
> the original 'myObject' in the pinned cache (on node 0).  As you point out,
> however, this approach is prohibitively costly -- we are effectively doing
> an iterative search across nodes.
>
> Again, we see the best approach as being to use the enhancement to the Key
> Affinity Service API suggested in
> https://issues.jboss.org/browse/ISPN-3112.
> Once
>
> *K getKeyForAddress(Address pinnedNodeAddress, K objectNaturalKey);*
>
> is provided, we will be able to proceed as simply as follows:
>
> //given that all nodes "know" that all birthday Entry(s) are pinned to Node
> 0
>
> @t=0, from node=0, pin Entry to cache at Node 0
>
>       Object pinnedKey = getKeyForAddress(getAddress("Node0"),
> "1962-08-10");
>       cache.put(pinnedKey,"Ben D. Cotton III birthday");
>
>
> Later @t=1, from node =2, we can use the improved API (suggested in the
> JIRA) from a 'foreign' node without any need to do a distributed, iterative
> search, i.e.
>
>       Object pinnedKey = getKeyForAddress(getAddress("Node0"),
> "1962-08-10");
>       Object birthdayCelebrant = cache.get(pinnedKey);  //return "Ben D.
> Cotton III birthday"
>
>
> Of course, for us to be able to do this, the ISPN team would have to
> deliver
> to us the API recommended in the JIRA
> https://issues.jboss.org/browse/ISPN-3112.  Don't you agree such an API
> enhancement would be an awesome capability improvement for ISPN users
> wishing to operate in a distributed fashion on pinned Caches? :-)
>
> As always, thanks to you and this forum for its fine support,
> Ben
>
>
>
>
>
>
> --
> View this message in context:
> http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-nice-2-recommendations-tp4027152p4027401.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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130614/49ad1432/attachment.html