[infinispan-dev] KeyAffinityService

[Dan Berindei]

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

>
>
> /It's probably possible to define something like this instead:
>
> PinnedKey<K> getKeyForAddress(address, key)
> /
>
> This is fine.  Do it this way.
>
> /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.
> /
>
> But, shouldn't some combination of my usage of the ISPN Grouper<T> and the
> ISPN KeyAffintyService capabilities cover me?   In my understanding, the
> Grouper capability can allow me to "group" my keys to a specific node
> (however node identity is anonymous).  Grouper capability's ambition is to
> transparently survive topology changes of nodes participating in my grid.
> In my understanding, the KAS capability can allow me to "pin" my keys to a
> specific node (by node identity).   A potetnailly great tutorial document
> for ISPN users might be "How to harmoniously use the ISPN Grouper and ISP
> KeyAffinityService Capabilities".  How to use these 2 meritorious
> capabilies
> together (and in harmony) is still unclear to me.
>
>
Just to be clear, KAS doesn't really allow you to pin a key to a certain
node. It only gives you a key that maps to the given node the moment you
called KAS.getKeyForAddress(Address) - by the time you call cache.put()
with the "pinned" key, it may have already moved to a different node.

Would that be enough for you? If yes, adding the new method should be
relatively easy to accomplish with what we have now (although the fact that
a grouping key can only be a String does impose some limitations).

But it has been my impression that you want something that would keep the
key pinned to the same node as long as that node was alive. If that's the
case, then implementing it would require significant additional work.



> /Speaking of which, how do you know which keys should map to which node in
> your application?/
>
> We just know.  :-)   Seriously, we do have a mechanism for resolving
> pinnedKey identity to Node identity custody.
>
>
I'm just wondering, wouldn't it be simpler if you created a custom
ConsistentHashFactory to map keys to nodes using the same mechanism you
already have? Not as easy as the API you proposed, but it wouldn't require
a separate cache either...


/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)./
>
> Very true.  But we don't think that is as nice as extending the API in the
> way recommend.  To be blunt, we could just do something as simple as this:
>
> @t=0, from node=0, pin Entry to cache at Node 0
>
>       Object pinnedKey =
> getKeyForAddress(getAddress("Node0"),"1962-08-10");
>

I suppose you meant pinnedKey = getKeyForAddress(getAddress("
Node0")) here.

With this solution, "pinned" keys could also move from the initial target
node to another node as the cache topology changes (and not all keys will
move to the same node).


      globalReplicatedPinnedKeyCache.put("1962-08-10", pinnedKey); //cache
> the pinnedKeys globally
>       pinnedCache.put(pinnedKey,"Ben D. Cotton III birthday");
>
> Later @t=1, from node =2
>
>        Object pinnedKey =
>  globalReplicatedPinnedKeyCache.get("1962-08-10");
>        Object birthdayCelebrant = pinnedCache.get(pinnedKey);  //return
> "Ben
> D. Cotton III birthday"
>
> But that is effectively forcing us to do 2 explicit Cache<K,V>#get()
> operations in application code.  First to get the pinnedKey (given the
> naturalKey).  Second to get the pinnedValue (given the pinnedKey).  Not
> preferred -- but DOABLE, FOR SURE.
>
>
What do you think?  Just for the "niceness" of it, do you think  we might be
> able to have the API suggested at
> https://issues.jboss.org/browse/ISPN-3112
> ?
>

My main concern is that you actually want something more than the
KeyAffinityService is able to give you ATM - even if we did add the
"niceness" in the API, the keys still won't be pinned to a certain node for
as long as that node is alive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130614/aabf71d2/attachment-0001.html