Hi,
I'´m currently twiddling with an application that has a setup matching the following chat analogy (the actual topic is chess, but this is simpler to explain):
- 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:
- Seam's events with the chat ID as a parameter and then each component checks the ID and either updates or ignores the message
- JMS Queues or one JMS topic where each component listenes on with a filter for just it's chat
- a 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 each time a new chat messages is posted, 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 a lot 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.
ciao,
elm
