<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 14, 2013 at 5:46 PM, cotton-ben <span dir="ltr"><<a href="mailto:ben.cotton@alumni.rutgers.edu" target="_blank">ben.cotton@alumni.rutgers.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
/It's probably possible to define something like this instead:<br>
<br>
PinnedKey<K> getKeyForAddress(address, key)<br>
/<br>
<br>
This is fine. Do it this way.<br>
<br>
/Even so, keeping the result key pinned to the same address after a<br>
<div class="im">rebalance would be tricky - probably requiring some changes to the<br>
ConsistentHash implementation. Of course, the node to which the key is<br>
pinned may also die, and I'm not sure where the keys should be located then.<br>
</div>/<br>
<br>
But, shouldn't some combination of my usage of the ISPN Grouper<T> and the<br>
ISPN KeyAffintyService capabilities cover me? In my understanding, the<br>
Grouper capability can allow me to "group" my keys to a specific node<br>
(however node identity is anonymous). Grouper capability's ambition is to<br>
transparently survive topology changes of nodes participating in my grid.<br>
In my understanding, the KAS capability can allow me to "pin" my keys to a<br>
specific node (by node identity). A potetnailly great tutorial document<br>
for ISPN users might be "How to harmoniously use the ISPN Grouper and ISP<br>
KeyAffinityService Capabilities". How to use these 2 meritorious capabilies<br>
together (and in harmony) is still unclear to me.<br>
<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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). <br>
<br>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.<br>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
/Speaking of which, how do you know which keys should map to which node in<br>
your application?/<br>
<br>
We just know. :-) Seriously, we do have a mechanism for resolving<br>
pinnedKey identity to Node identity custody.<br>
<br></blockquote><div><br></div><div>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...<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
/If the rules are simple enough, you may be able to create multiple caches,<br>
<div class="im">each of them with a custom ConsistentHashFactory that locates *all* the keys<br>
</div>to the same primary node (with random backup owners)./<br>
<br>
Very true. But we don't think that is as nice as extending the API in the<br>
way recommend. To be blunt, we could just do something as simple as this:<br>
<div class="im"><br>
@t=0, from node=0, pin Entry to cache at Node 0<br>
<br>
Object pinnedKey = getKeyForAddress(getAddress("Node0"),"1962-08-10");<br></div></blockquote><div><br></div><div>I suppose you meant pinnedKey = getKeyForAddress(getAddress("<div class="im">
Node0")) here.<br><div><br></div>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).<br>
<br><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
</div> globalReplicatedPinnedKeyCache.put("1962-08-10", pinnedKey); //cache<br>
the pinnedKeys globally<br>
pinnedCache.put(pinnedKey,"Ben D. Cotton III birthday");<br>
<div class="im"><br>
Later @t=1, from node =2<br>
<br>
</div> Object pinnedKey = globalReplicatedPinnedKeyCache.get("1962-08-10");<br>
Object birthdayCelebrant = pinnedCache.get(pinnedKey); //return "Ben<br>
D. Cotton III birthday"<br>
<br>
But that is effectively forcing us to do 2 explicit Cache<K,V>#get()<br>
operations in application code. First to get the pinnedKey (given the<br>
naturalKey). Second to get the pinnedValue (given the pinnedKey). Not<br>
preferred -- but DOABLE, FOR SURE.<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What do you think? Just for the "niceness" of it, do you think we might be<br>
able to have the API suggested at <a href="https://issues.jboss.org/browse/ISPN-3112" target="_blank">https://issues.jboss.org/browse/ISPN-3112</a><br>
?<br></blockquote><div><br></div><div>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.<br>
</div><br><div><br><br></div><div><br></div></div></div></div>