<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">On 9 Apr 2010, at 16:00, Brian Stansberry wrote:<br><br><blockquote type="cite">I'm putting this on the cluster-dev list as there's no reason for it to<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">continue in private.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Manik, I agree with your comment about avoiding tight coupling between<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">the ISPN hash algorithm and something inside mod_cluster. The approach<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">we decided to take was to change the jvmRoute -- see<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite"><a href="https://jira.jboss.org/jira/browse/JBAS-7853">https://jira.jboss.org/jira/browse/JBAS-7853</a>. The Mobicents folks are<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">already familiar with that approach since the AS has long done that on<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">failover. They've added a browser redirect technique that would even<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">avoid the "1 'inefficient' dispatch" issue you noted.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What's different about what Vladimir's raising here is the need to try<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">to group sessions together; i.e. use something other than the cache key<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">(i.e. jsessionid) as the factor in the hash algorithm. He mentioned a<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">use case for multiple users in a chat where the goal would be to cache<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">sessions locally with chat state. AIUI there's also a use case where a<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">user has a SIP session and an HTTP session, so the goal would be to have<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">both session cached together.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Doing that will clearly require quite a bit of AS work -- some pluggable<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">policy for determining what the "affinity key" is based on the call<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">context (null == use the cache key for hashing). Then use the<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">affinityKey can calling into ISPN (i.e. ISPN-359) and when determining<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">where to fail over to (JBAS-7853).<br></blockquote><br>I presume you're following the ISPN-359 thread on infinispan-dev...<span class="Apple-converted-space"> </span><br><br><blockquote type="cite">This will also be useful for the HTTPSession + SFSB in same request use<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">case, where colocating the SFSB and the web session is optimal.<br></blockquote><br>Right.<br><br><blockquote type="cite">I hadn't opened a JIRA for that yet; just tried to but JIRA seems to not<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">be working?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hmm, an issue is if the caches involved in the overall picture (e.g.<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">httpsession cache and "chat state" cache) end up using different<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">CacheManagers/JGroups Channels. This would quite likely happen (see<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite"><a href="http://community.jboss.org/thread/149868">http://community.jboss.org/thread/149868</a><span class="Apple-converted-space"> </span>for discussion why). If that's<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">the case, the views between the channels could end up slightly different<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">-- e.g. servers A and B are booting at the same time, so due to slight<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">differences in the boot, Channel for HTTPSession cache ends up with view<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">{A, B} and Channel for "chat state" cache ends up with {B, A}. In that<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">case I wouldn't expect there to be a reliable, performant way to ensure<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">affinity, since the view is a major factor in the hashing algorithm.<br></blockquote><br>Yes, it would not be useful at all if the 2 components end up with different views. It would only make sense if the web session cache and the SFSB session cache share the same CacheManager/Channel.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On 04/09/2010 04:53 AM, Manik Surtani wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">I made a few comments on the JIRA to respond to your comment; Brian, correct me if I have missed something, but this is pretty much what we spoke about in Brno? Do you have a JIRA in JBAS for this as well?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On 8 Apr 2010, at 19:39, Vladimir Ralev wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Thanks, this will work great for us. However, this issue seems to be scoped purely in Infinispan<span class="Apple-converted-space"> </span><a href="https://jira.jboss.org/jira/browse/ISPN-359">https://jira.jboss.org/jira/browse/ISPN-359</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">A reciprocal feature is needed in mod_cluster. Would it be possible mod_cluster to use a URI parameter, a cookie as affinity key. AFAIK from mod_jk, it only supports using the jsessionid cookie and uri param (hardcoded). Ultimately we'd like to have it use a customer GET param or cookie for affinity. I couldnt find any doc related to that. Would this be possible?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">----- Original Message -----<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">From: "Manik Surtani"<<a href="mailto:msurtani@redhat.com">msurtani@redhat.com</a>><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">To: "Brian Stansberry"<<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Cc: "Vladimir Ralev"<<a href="mailto:vralev@redhat.com">vralev@redhat.com</a>>, "Brian Stansberry"<<a href="mailto:bstansbe@redhat.com">bstansbe@redhat.com</a>>, "Jean Deruelle"<<a href="mailto:jderuell@redhat.com">jderuell@redhat.com</a>>, "Paul Ferraro"<<a href="mailto:paul.ferraro@redhat.com">paul.ferraro@redhat.com</a>><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Sent: Thursday, April 8, 2010 1:43:00 PM GMT +02:00 Athens, Bucharest, Istanbul<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Subject: Re: Consistent Hashing in mod_cluster<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 6 Apr 2010, at 20:02, Brian Stansberry wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi Vladimir,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I've been on vacation. I replied to your question on the wiki page, but what you're talking about here is a bigger picture thing.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Sounds like your situation is a good use case for<span class="Apple-converted-space"> </span><a href="https://jira.jboss.org/jira/browse/ISPN-359">https://jira.jboss.org/jira/browse/ISPN-359</a><span class="Apple-converted-space"> </span>which is an Infinispan JIRA. (At least I believe that's the JIRA that gets into allowing the caller to provide hints such that separate keys hash to the same storage nodes -- Manik, please correct me if I'm wrong.)<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Yup, this is correct.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 03/31/2010 01:58 PM, Vladimir Ralev wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hello Brian,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Not sure if you are following<span class="Apple-converted-space"> </span><a href="http://community.jboss.org/wiki/Consistent-hashingbasedJBCdatapartitioningwmodcluster">http://community.jboss.org/wiki/Consistent-hashingbasedJBCdatapartitioningwmodcluster</a><span class="Apple-converted-space"> </span>so decided to email you.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">We are very interested in the consistent hashing feature in the load balancer working cooperatively with the cache and would like to follow the development and contribute if needed. Particularly, we in Moicents already have a number of use-cases that concern bothtelecom and pure web applications. For example - a web based chat room will have a number of participants with different HTTP sessions and they share the same state somewhere in another cache at the same node. It would be desireable to failover such groups of users together to avoid having them to lookup the chat state in remote caches over the network. That is why, if possible, we are interested in using not just the HTTP session ID for lookups, but have a configurable affinity key/mask that is taken from the messages, so that you could route all requests with<span class="Apple-converted-space"> </span><a href="http://redhat.com/?chatroom=1">http://redhat.com/?chatroom=1</a><span class="Apple-converted-space"> </span>always to the same node, and "chatroom" as an URL param is the affinity key with value "1".<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Sailfin/Glassfish have something similar with their CLB.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">In Mobicents we would be using it to coordinate not only mod_cluster and cache, but the SIP load balancer and other protocol load balancers as well. In fact, our load balancer already supports HTTP consistent hashing, however it doesn't have the high performance of mod_cluster (no AJP either) and is only recommended when SIP+HTTP coordination is a requirement for our telco users.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://docs.google.com/present/view?id=dc5jp5vx_89cxdvtxcm">http://docs.google.com/present/view?id=dc5jp5vx_89cxdvtxcm</a><span class="Apple-converted-space"> </span>(Slide 17 has a helpful diagram)<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The other technique we are using to coordinate multiprotocol load balancers with local cache is this<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://docs.google.com/present/edit?id=0AdgrvwaZgnJ1ZGM1anA1dnhfOTZnZjYyc2ZwOQ&hl=en">http://docs.google.com/present/edit?id=0AdgrvwaZgnJ1ZGM1anA1dnhfOTZnZjYyc2ZwOQ&hl=en</a><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">--<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Brian Stansberry<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Lead, AS Clustering<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">JBoss by Red Hat<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">--<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">Brian Stansberry<br></blockquote><blockquote type="cite">Lead, AS Clustering<br></blockquote><blockquote type="cite">JBoss by Red Hat<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">jboss-cluster-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:jboss-cluster-dev@lists.jboss.org">jboss-cluster-dev@lists.jboss.org</a><br></blockquote><blockquote type="cite"><a href="https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev">https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev</a></blockquote></span></div></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org">manik@jboss.org</a></div><div>Lead, Infinispan</div><div>Lead, JBoss Cache</div><div><a href="http://www.infinispan.org">http://www.infinispan.org</a></div><div><a href="http://www.jbosscache.org">http://www.jbosscache.org</a></div><div><br></div></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br></body></html>