Question

I’´m currently twiddling with an application that has a setup matching the following chat analogy:

• a chat is an object that is held in memory and contains a list of chat
  messages
• a chat is rendered in several browser windows and updates are
  pulled in with a4j:push

The programmatic setup looks like this: an instance of a chat object with it’s messages is shared between PAGE scoped seam component in different sessions. Now, when any session posts a new message, i.e. modifies the chat object, all seam components should be notified of the new message so that the new state can be relayed to the UI on all clients.

I can think of three ways to achieve this:

1. Seam’s events with the chat ID as a parameter and then each component checks the ID and either updates or ignores the message
2. JMS Queues or one JMS topic where each component listenes on with a filter for just it’s chat
3. a pure Java listener mechanism in the shared chat object, i.e. each seam component registers to it and the notification is pure and direct java

For the sake of argument assume the number of chat’s is large (tens of thousands) and the number of chat users is small (let’s say 2-10).

How does each scale performance wise? Do you have any other suggestions how make this with Seam and performing well?

As I see it, (1) would be integrated and clean, but eventually you’d notify tens of thousand of components where only a few actually need it. So it probably won’t scale.

(2) would be integrated and only depend on the performance of the JMS provider (which can be exchanged) and would also work in a clustered environment without modifications. I’m not sure about the performance of JMS here, i.e. are a few hundred messages per second and thousand of listeners with different filters much or not?

(3) would be fast, because only the required components would be notified and the notification is pure and direct java. However, concurrency / access problems may arise because something cross session / component / thread is done.

For (1) and (3) a solution that supports clustering would have to be added manually if required at some point.

Answer 1

I’d recommend 2). I would also recommend cutting JMS out of the equation – even though it will enable you to switch messaging providers it will also make prevent you from using the more advanced features of your messaging system. If you are using an Oracle database AQ would make a sensible choice (it supports JMS btw.). Otherwise I’d recommend using AMQP which should be available through JBoss Messaging or a third party solution like RabbitMQ.

Since you clearly have a messaging problem you should opt for using a messaging solution.