Вам надо использовать обыкновенный паттерн Request/Reply messages design. Суть в том что в заголовке сообщения нужно указывать JmsReplyTo - указатель на очередь для ответа, то есть поток 1 посылает запрос в очередь и устанваливает этот заголовок потом блокируется на receive() из этой очереди, поток 2 получает сообщение, что-то делает и отвечает в очередь указанную в заголовке, поток 1 разблокируется - и все тип топ

http://www.eaipatterns.com/RequestReplyJmsExample.html

GKS_SamaraДобрый день, забыл ник!

> Вам надо использовать обыкновенный паттерн Request/Reply messages
> design. Суть в том что в заголовке сообщения нужно указывать JmsReplyTo
> - указатель на очередь для ответа, то есть поток 1 посылает запрос в
> очередь и устанваливает этот заголовок потом блокируется на receive() из
> этой очереди, поток 2 получает сообщение, что-то делает и отвечает в
> очередь указанную в заголовке, поток 1 разблокируется - и все тип топ

А оно разве для моего случая подходит?

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

--
Алексей
JID: alxt@ya.ru


Ну не зря это паттерн, не важно сколько у вас отправителей - создание очереди - дело малозатратное, тем более можно создавать временные очереди. Я вам советую почитать Java Message Service 2 ed by Mark Richards, все расставляет по полочкам, в том числе там описан этот паттерн и некоторые другие.

авторзабыл ник,

Именно этот подход используется в Camel - причем бесшовно с точки зрения программиста - заголовки сообщений и временные очереди создаются автоматически. Автор, если есть возможность прикрутить верблюда в систему, думаю все будет просто и наглядно (и с минимальным вмешательством в логику).


Camel хорош бесспорно, но я бы не стал его прикручивать ради только одной этой задачи, но если автор почитает про Camel и подумает что он может заюзать его и в других местах - то я скажу вам только +1 :)

GKS_Samaraзабыл никНу не зря это паттерн, не важно сколько у вас отправителей - создание
очереди - дело малозатратное, тем более можно создавать временные
очереди.


Так можно в JavaEE создавать динамически слушателей, или это возможно
только в клиентском коде?

--
Алексей
JID: alxt@ya.ru


Можно, я же вам ссылку приводил, JMS как раз и создавался держа в уме J2EE, так что это было бы нелепо)


авторВообще в топике проблема встала именно в JMS в рамках EJB. Указанный выше патерн подходит для обычных jms приложений. Подумайте над вопросом как быть с транзакцией в случае:

> посылает запрос в
> очередь и устанваливает этот заголовок потом блокируется на receive()

Потомучто после блокировки на receive() транзакция не закончиться и соответственно получатель никакого месаджа не увидит, а отправитель так и будет висеть на receive()


Смотря какую вы транзакцию подразумеваете, локальную или распределенную и смотря какие требования для приложения.
В случае с локальной транзакцией никаких проблем нет - получаем транзакционную сессию, посылаем месседж, делаем коммит, блокируемся на ресив(). В рамках распределенной транзакции - в большинстве случаев, когда нужно воспользоваться паттерном Request/Reply - никакой речи о распределенных транзакциях вообще не идет, ибо это глупо и нужно искать другое решение или в принципе можно ослабить условие транзакционности именно для JMS, например можно приостановить транзакцию и вызвать JMS без транзакции или с локальной, потом восстановить и т.п. И только в случае если ну прям прям необходимо все обернуть в распределенную транзакцию - можно перейти с варианта с JmsReplyTo и временными очередями на JmsCorrelationId и постоянными очередями. Собственно это все хорошо известно, на самом деле это и есть главное ограничение при работе с JmsReplyTo и временными очередями

авторAnother limitation of the QueueRequestor is that the QueueSession cannot be transacted,
and will not support the CLIENT_ACKNOWLEDGE message acknowledgment mode. These
limitations should also be considered before using the QueueRequestor technique.

vas0GKS_Samara,

Если с точки зрения клиента идет синхронный вызов, то встраивание где то посередине асинхронной отправки и приема сообщений выглядит ни к месту. Почему бы просто не заменить MDB на Stateless bean и не мучатся?

У JMS есть вариант синхроного вызова, но такие вызовы не могут транзакционными.

+1

GKS_SamaraДобрый день, vas0!

> Если с точки зрения клиента идет синхронный вызов, то встраивание где то
> посередине асинхронной отправки и приема сообщений выглядит ни к месту.
> Почему бы просто не заменить MDB на Stateless bean и не мучатся?

Потому что через MDB идёт отсылка сообщения в другое приложение.
Оно слушает очередь и выдаёт ответ.
Как сделать прямой вызов из EJB я не понимаю :)

--
Алексей
JID: alxt@ya.ru


Что-то вы не договариваете, вы же выложили код и слушателя и отправителя, и из этого можно сделать вывод, что вы можете править код и там и там, так почему не заменить JMS на Stateless EJB?

OOsalivanGKS_SamaraДобрый день, OOsalivan!

> Все равно в вашей схеме без запуска потока который слушает респонс не
> обойтись (на стороне МДБ или стэтлес бина)

Я же логи привёл :)

Работают два потока- первый создан для обработки внешнего вызова
stateless-бином (он отсылает начальное сообщение и его я
приостанавливаю), второй - для обработки ответного JMS-сообщения с
помощью MDB (он разбудит первый поток).

НУ НЕТУ у меня в коде new Thread() как класса :)

--
Алексей
JID: alxt@ya.ru


а xто мешеает в стэйтлес бине использовать патерн синхронного jms, при отсылки сообщения в проперти реплайту задать очередь для ответа, а после отсылки заблокироваться на ресив из заданной очереди

Ну как бы разве не об этом я все время говорил:) И вы же правильно описали одно из ограничений - транзакции