JBoss Seam — массовый обмен сообщениями в приложении

Question

В настоящее время я работаю над приложением, настройка которого соответствует следующей аналогии с чатом:

• чат - это объект, который удерживается в памяти и содержит список сообщений чата
• Чат отображается в нескольких окнах браузера, а обновления втянуты с A4J: push

Программная настройка выглядит так:экземпляр объекта чата с его сообщениями совместно используется компонентом шва области PAGE в разных сеансах.Теперь, когда какой-либо сеанс публикует новое сообщение, т.е.изменяет объект чата, все компоненты шва должны быть уведомлены о новом сообщении, чтобы новое состояние можно было передать в пользовательский интерфейс на всех клиентах.

Я могу придумать три способа добиться этого:

1. События шва с идентификатором чата в качестве параметра, а затем каждый компонент проверяет идентификатор и либо обновляет, либо игнорирует сообщение.
2. Очереди JMS или одна тема JMS, где каждый компонент прослушивает с помощью фильтра только свой чат.
3. чистый механизм прослушивания Java в общем объекте чата, т.е.каждый компонент шва регистрируется на нем, и уведомление является чистым и прямым Java

Для рассуждения предположим, что количество чатов велико (десятки тысяч), а количество пользователей чата мало (скажем, 2-10).

Как каждый из них масштабирует производительность?Есть ли у вас какие-либо другие предложения, как сделать это с помощью Seam и добиться хорошей производительности?

На мой взгляд, (1) будет интегрированным и чистым, но в конечном итоге вы уведомите десятки тысяч компонентов, тогда как на самом деле это нужно лишь немногим.Так что, вероятно, он не будет масштабироваться.

(2) будет интегрирован и будет зависеть только от производительности провайдера JMS (которого можно заменить), а также будет работать в кластерной среде без изменений.Я не уверен в производительности JMS здесь, т.е.несколько сотен сообщений в секунду и тысячи слушателей с разными фильтрами – это много или нет?

(3) будет быстрым, потому что будут уведомлены только необходимые компоненты, а уведомление будет чистым и прямым Java.Однако проблемы с параллелизмом/доступом могут возникнуть из-за того, что что-то выполняется между сеансами/компонентами/потоками.

Для (1) и (3) решение, поддерживающее кластеризацию, придется добавить вручную, если это потребуется в какой-то момент.

Answer 1

Я бы порекомендовал 2).Я бы также рекомендовал исключить JMS из уравнения — хотя он позволит вам переключаться между поставщиками сообщений, он также не позволит вам использовать более продвинутые функции вашей системы обмена сообщениями.Если вы используете базу данных Oracle АК сделал бы разумный выбор (кстати, он поддерживает JMS).В противном случае я бы рекомендовал использовать AMQP, который должен быть доступен через Обмен сообщениями JBoss или стороннее решение, например КроликMQ.

Поскольку у вас явно есть проблемы с обменом сообщениями, вам следует выбрать решение для обмена сообщениями.