<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 24 May 2010, at 19:30, Brian Stansberry wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Thanks, Mircea:<br><br>A related use case I need to cover[1] is checking whether an existing <br>key still hashes to the local node and if not, where it hashes. This may <br>not belong in KeyAffinityService, but I'd like it in some place easily <br>accessible to the same caller the creates KeyAffinityService.<br><br>Set<Address> getAddressesForKey(K key)<br><br>Usage:<br><br>Set<Address> addresses = getAddressesForKey(sessionId);<br>if (!addresses.contains(localAddress)) {<br> redirectRequest(addresses);<br>}<br><br>getAddressesForKey() could return a List<Address> but then checking <br>whether the local address is OK would require a scan. AIUI there <br>ordering in the set of DIST nodes is not meaningful, so a Set should be <br>fine.<br></div></blockquote>there's already something similar in the cache API:</div><div>cache.getAdvancedCache().getDistributionManager().locate(Object key)::List<Address></div><div>If you have many sessions(which I think is the case), then transforming the List in a Set is quicker indeed. </div><div>Taking the idea one step further, this would be an possibly useful service as well: a notification service, to which </div><div>you register keys and listeners, and the service would call the listener whenever key's distribution is changed.</div><div>Wdyt? </div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Re: K getCollocatedKey(K otherKey) please note that for the AS use cases <br>I know of where colocation is helpful,</div></blockquote><div>I can't help but notice your American spelling of "colocation". I know, I know, you won a War :)</div><blockquote type="cite"><div> the colocated data will be stored <br>in separate Cache instances, while the KAS is scoped to a cache. The <br>method should still be helpful though, as long as the caches use the <br>same underlying CacheManager/Channel. It's up to the caller to check that.<br><br></div></blockquote>agreed. All the caches associated to a CM share the same transport. They can potentially have different ConsistentHash functions though, that's why the service runs per Cache instance, rather than running per CacheManager instance.<br><blockquote type="cite"><div>On KeyAffinityServiceFactory, there's the bufferSize param:<br><br> * @param keyBufferSize the number of generated keys per {@link <br>org.infinispan.remoting.transport.Address}.<br><br>That implies the factory will maintain a buffer of keys for *all* <br>addresses, not just the local address. The use cases I'm concerned with, <br>the only address for which I want keys is the local one. Perhaps it <br>makes sense to offer a separate param for the local address buffer size?<br><br>In a small cluster maintaining some keys in a buffer for irrelevant <br>addresses is no big deal, but for large clusters it may waste a fair <br>amount of memory.<br></div></blockquote><div>Good point! what about adding a new parameter to the factory's methods: Collection<Address> - to specify the list of addresses for which keys will be generated.</div><div>And another factory method that would transparently pass the local address to the previous method so that the caller won't be concerned with getting the local address.</div><div><br></div><div>Cheers,</div><div>Mircea</div><blockquote type="cite"><div><br>[1] <a href="https://jira.jboss.org/browse/JBAS-7853">https://jira.jboss.org/browse/JBAS-7853</a> plus a similar requirement <br>for EJB3 as discussed on <a href="https://community.jboss.org/docs/DOC-15052">https://community.jboss.org/docs/DOC-15052</a><br><br><br>On 05/24/2010 05:15 AM, Mircea Markus wrote:<br><blockquote type="cite">Hi,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I've committed[1] the interfaces for the key-affinity service in ISPN-232.<br></blockquote><blockquote type="cite">Would you mind taking a look and let me know what you think?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thanks!<br></blockquote><blockquote type="cite">Mircea<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">[1] <a href="http://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/infinispan/affinity/">http://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/infinispan/affinity/</a><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">infinispan-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br></blockquote><blockquote type="cite"><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></blockquote><br><br>-- <br>Brian Stansberry<br>Lead, AS Clustering<br>JBoss by Red Hat<br>_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/infinispan-dev<br></div></blockquote></div><br></body></html>