Как я могу обработать несколько сообщений одновременно от темы JMS (не очередь) с Java и пружина 3.0?

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

Пружинный DefaultMessageListenerContainer, кажется, поддерживает параллелизм для очередей JMS только.

Я должен инстанцировать нескольких DefaultMessageListenerContainers?

Если время течет вниз вертикальная ось:

ListenerA reads msg 1        ListenerB reads msg 2        ListenerC reads msg 3
ListenerA reads msg 4        ListenerB reads msg 5        ListenerC reads msg 6
ListenerA reads msg 7        ListenerB reads msg 8        ListenerC reads msg 9
ListenerA reads msg 10       ListenerB reads msg 11       ListenerC reads msg 12
...

ОБНОВЛЕНИЕ:
Спасибо за Вашу обратную связь @T.Rob и @skaffman.

То, что я закончил тем, что делал, создает несколько DefaultMessageListenerContainers с concurrency=1 и затем помещая логику в слушателя сообщения так, чтобы только один поток обработал бы данный идентификатор сообщения.

14
задан T.Rob 26 September 2012 в 10:19
поделиться

2 ответа

Вы не хотите, чтобы несколько экземпляров DefaultMessageListenerContainer , нет, но вам нужно настроить DefaultMessageListenerContainer для одновременного использования, используя свойство concurrentConsumers ]:

Укажите количество одновременных потребителей создавать. По умолчанию 1.

Указание более высокого значения для этого установка увеличит стандарт уровень запланированных одновременных потребители во время выполнения: это фактически минимальное количество одновременных потребителей, которые будут запланировано в любой момент времени. Это статическая настройка; для динамического масштабирования, рассмотреть возможность определения Параметр "maxConcurrentConsumers" вместо.

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

Однако внизу есть большое предупреждение:

Не увеличивайте количество одновременных потребителей для темы . Это приведет к одновременному потребление того же сообщения, которое вряд ли когда-либо желательно.

Это интересно и имеет смысл, если задуматься. То же самое произошло бы, если бы у вас было несколько экземпляров DefaultMessageListenerContainer .

Я думаю, что, возможно, вам нужно переосмыслить свой дизайн, хотя я не уверен, что я предлагаю.Одновременное использование сообщений pub / sub кажется вполне разумным делом, но как избежать доставки одного и того же сообщения всем вашим потребителям одновременно?

6
ответ дан 1 December 2019 в 15:01
поделиться

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

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

К сожалению, универсального переносимого с помощью JMS способа сделать это не существует.Вы в значительной степени зависите от реализации транспортного провайдера. Единственный из них, о котором я могу говорить, - это WebSphere MQ, но я уверен, что другие транспорты так или иначе поддерживают это, и в разной степени, если вы изобретательны.

1
ответ дан 1 December 2019 в 15:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: