О структуре системы JMS - PullRequest
       79

О структуре системы JMS

1 голос
/ 24 октября 2011

Я пишу игру сервер / клиент, типичный сценарий выглядит следующим образом: один клиент (clientA) отправляет сообщение на сервер, на сервере имеется MessageDrivenBean для обработки таких сообщений.После того, как MDB завершил свою работу, он отправляет сообщение с результатом другому клиенту (clientB).

По моему мнению, мне нужны только две очереди для такой связи, одна для ввода, другая для вывода.Создание новой очереди для каждого соединения не очень хорошая идея, верно?Входная очередь относительно чиста: если больше клиентов отправляют сообщение одновременно, сообщения просто ожидают в очереди, в то время как на сервере больше экземпляров MDB, что не должно быть большой проблемой производительности.

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

Я новичок в системе сообщений.Есть ли какие-либо предложения о моей реализации?Спасибо!

Ответы [ 2 ]

1 голос
/ 25 октября 2011

MaDa;

Вы можете прикрепить одну очередь вывода (или тему) и просто пометить сообщение заголовком, который идентифицирует предполагаемого клиента.Затем клиенты могут прослушивать очередь / тему с помощью селектора.Надеемся, что ваша реализация JMS имеет эффективную оценку прослушивателя на стороне сервера.

1 голос
/ 24 октября 2011

Начнем с того, что выбор JMS в качестве игровой платформы необычен: предприятия используют JMS-брокеров для обеспечения надежности доставки и поддержки транзакций.Вам действительно нужен этот тяжелый подъем в игре?Разве вы не должны прибегать к своему собственному протоколу на основе HTTP, например?

При этом две очереди являются стандартным шаблоном для связи точка-точка.Создание очереди для нового соединения определенно не подходит - управляемые сообщениями компоненты присоединяются к очередям во время развертывания, поэтому вы не сможете отвечать на события создания очереди.Кроме того, очереди не предназначены для создания и уничтожения в короткие циклы, они скорее предназначены для долгоживущих объектов.Если вам необходимо доставить сообщение одному конкретному клиенту, попросите клиента прослушивать очередь ответов сервера с установленным селектором сообщений для фильтрации только сообщений, предназначенных для этого клиента (см. javax.jms.Message API).

СТемы, как вы и заметили - каждый подключенный клиент получит копию сообщения - так что, опять же, это не очень хороший способ отправить n клиентам сообщение, которое должно быть отклонено n-1 клиентов.

...