title: HTTP Consumers of a JMS Topic In A Clustered Environment
body: <p>I've seen bits and pieces of this question, but nothing that directly answers it.</p>
  
  <p>Here is the hypothetical environment:</p>
  
  <ul>
  <li>20 Java centric servers (i.e. Tomcat / Glassfish / Jboss / whatever)
  talking with client via HTTP</li>
  <li>The HTTP load balancer in front of the servers is <em>not</em> guaranteed to
  bring you back to the same server with each client connection.</li>
  <li>Anything else is available technology wise. (JMS / Camel /
  Memcached / Hazelcast / Whatever)</li>
  </ul>
  
  <p>We want Joe and his browser (maybe using Flash or HTML5 or whatever client technology) to receive all messages that are published to a JMS topic available to all 20 servers. </p>
  
  <p>Here is an example : </p>
  
  <ul>
  <li>Joe's first HTTP connection hits server A</li>
  <li>Server A now has an HTTP session for Joe (via cookies, etc)</li>
  <li>Server A subscribes him to the topic (based on his session ID or the like)</li>
  <li>Joe's HTTP connection ends.</li>
  <li>A message is posted to the topic.</li>
  <li>Joe makes another connection, but this time it is handled by server F.</li>
  </ul>
  
  <p>This is where things get a little vague for me.</p>
  
  <ul>
  <li>We know Joe's session ID on his return (and maybe the session is shared across all servers), but what about the JMS subscription? If server F has to subscribe Joe again to the topic, did he just miss a message? Is A the only server that Joe can retrieve that message from or is there some kind of magic that can happen when he subscribes on F and it just knows that he didn't get the message (presumably waiting for him on A).</li>
  </ul>
  
  <p>I guess I'm a little unclear as to what "subscribing" does (process wise) and how it relates to clustered servers. I'm playing with long polling (cometd) and websockets to help client responsiveness when it comes to receiving topic messages, but have to consider how this will work when there are many servers that could handle the connection and subscription. I want to avoid server pinning.</p>
  
  <p>Thanks for any pointers.</p>
  
  <p>EDIT1 : Hopefully some clarification. There is something specific I'm referring to here that is available in the BlazeDS framework. It allows a HTTP client to subscribe to a JMS topic and uses long polling to achieve near real time client updates, but it requires that once a client hits a server, all requests must go back to that one server. So it must (somehow?) be keeping the topic subscription active for that client on that server. I want to get rid of that requirement (with any technology/framework).</p>