On Fri, Jun 14, 2013 at 5:46 PM, cotton-ben <ben.cotton@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.