HTTP Consumers of a JMS Topic In A Clustered Environment

Question

I've seen bits and pieces of this question, but nothing that directly answers it.

Here is the hypothetical environment:

• 20 Java centric servers (i.e. Tomcat / Glassfish / Jboss / whatever) talking with client via HTTP
• The HTTP load balancer in front of the servers is not guaranteed to bring you back to the same server with each client connection.
• Anything else is available technology wise. (JMS / Camel / Memcached / Hazelcast / Whatever)

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.

Here is an example :

• Joe's first HTTP connection hits server A
• Server A now has an HTTP session for Joe (via cookies, etc)
• Server A subscribes him to the topic (based on his session ID or the like)
• Joe's HTTP connection ends.
• A message is posted to the topic.
• Joe makes another connection, but this time it is handled by server F.

This is where things get a little vague for me.

• 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).

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.

Thanks for any pointers.

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).

Answer 1

Virtual Topics is exactly the solution I have been looking for. It describes the problem and the solution (in a lot more concise words that I have :-) See "The limitations of JMS durable topics"

Answer 2

The JMS server keeps track of every subscription made and makes a difference between Durable vs. non Durable subscriptions. Suppose you have clients A, B, C and a topic T.

1. Client A subscribes to Topic T and waits for messages
2. Client B subscribes to topic T waits for messages
3. Client C dose a Durable subscription to topic T and waits for messages
4. Client B and C crashes seconds before a message M is put to topic T
5. Client A get a copy of the message M because it is subscribed and currently connected to the jms server
6. Client B restarts but does not get a copy of the message because it was not connected to the jms server when the message arrived on the topic
7. Client C restarts and gets the message M because it hand a durable subscription, the JMS server kept a copy of the message M while C was crashed and waited for C to come back and claim the message.

There are administrative settings on the message server to control how the length of time a jms server will wait for a durable subscriber to come back and claim messages before sending the message to the dead letter queue or a maximum number of message on a topic that are waiting for subscriber to come back and claim. You really need to balance the never loose a message against the flow messages and running out of memory, or disk space.

Please note that the concept of persistent queue is different than the concept of durable subscriber. Persistent queues and topics protect you against crashes of the JMS server, by writing the content of the queues and messages to disk before acknowledging receipt of the messages. Durable subscriber is about what happens to a message when a message arrive while a client is not connected.

---

Old answer.

Think of the JMS server the way you think of a SQL database. From the point of view of the web container there should be a pool of connections to the JMS server, So what you do is to grab a connection to the JMS server and subscribe to a topic. For example.

• JMS server has one topic called AddressChangeTopic
• Each tomcat instance has a subscription to AddressChangeTopic
• Address Change events for Joe / Jim / John ... etc all go to the same AddressChangeTopic rather than going to JohnAddressTopic, JimAddressTopic, ... etc it would be impractical to create a separate topic per user for an application what if you have 1 million users will you have one million topics?

So if one topic is being used, you must consume the message from that topic using a selective consumer, see http://www.eaipatterns.com/MessageSelector.html what the selective consumer will do is retrive message from the topic that match certain criteria. For example the message producer that published the JMS message to the topic should be including a header or a JMS property called targetUser or something like that, then the consumer can say give any messages that from the AddressChangeTopic where the custom property targetUser="Joe" see some example selectors examples Here

The key to this is to realize that you can query a queue or a topic the way that you can query a database table, but with much limited query syntax. From a conceptual view point I highly recommend the Enterprise Integration Patterns Book http://www.amazon.ca/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683