Как реализовать парадигму FIFO с Open Liberty и IBM MQ?

Мы переносим приложения с WebSphere Application Server Full profile (WAS) на Open Liberty (OL)
Один из шаблонов, который у нас есть, заключается в использовании очереди в «строгом порядке FIFO» для некоторой очереди JMS. Многие экземпляры приложения выполняются одновременно («члены кластера» в WAS, «модули» в kubernetes/statefulset/docker для OL).
Для реализации FIFO один и только один процесс «JMS-активация»/MDB может потреблять Очередь и, если возникает исключение, остановить прослушиватель (активация JMS)

В WAS мы можем сделать это,

  • настройка"WAS_EndpointInitialState"на"ACTIVE"активации JMS для одного сервера и"INACTIVE"для остальных
  • set"Maximum server sessions"to 1 при активации JMS
  • проверить"Stop endpoint if message delivery fails"
  • отслеживать журналы, чтобы увидеть, прекратились ли активации

В OL мы можем in"server.xml":

  • set"autoStart="true"on the"jmsActivationSpec" stanza для одного из процессов и "false"для остальных
  • установить"maxEndpoints="1"на"jmsActivationSpec"

Но как сделать так, чтобы активация останавливалась, если приложение выдает исключение в методе "onMessage"" в MDB?

[EDIT 1 After @JoshMc comment]
В настоящее время сообщение перемещается в DLQ, и активация, кажется, никогда не останавливается, поэтому FIFO прерывается, поскольку следующее сообщение в очереди потребляется...
В настоящее время, когда метод "onMessage()"method генерирует исключение, сообщение помещается обратно в очередь и немедленно повторно обрабатывается бесконечно

Параметр in"server.xml" для подключения к IBM MQ из OL выполняется как описано здесь

[EDIT 2]
Эта функция (остановка активации в случае сбоя) реализована в IBM MQ rar v9.1.1 и WebSphere Liberty 18.0.0.4 путем установки свойства "maxSequentialDeliveryFailures" в спецификации активации в этом RFE. Он не работает на Open Liberty v19.0.0.2 и IBM MQ rar v9.1.1. rar специально предназначен для WebSphere Liberty, чтобы применить свойство, подтвержденное после активации трассировки на коннекторе:

March 7, 2019 1:17:38 EST PM[Default Executor-thread-7]     ResourceAdapterImpl
WMQ messaging : '9.1.1.0-p911-L181120.1'. 
MQJCA5003: 'maxSequentialFailureCount' cannot be set outside Websphere Liberty Profile

Таким образом, вопрос все еще существует: как остановить активацию в случае, если метод "onMessage"" в MDB не может использовать сообщение? Откройте RFE для IBM MQ с просьбой перенести эту функцию в Open Liberty?


person titou10    schedule 07.03.2019    source источник
comment
Каковы значения BOTHRESH и BOQNAME для используемой локальной очереди?   -  person JoshMc    schedule 07.03.2019
comment
@JoshMc, BOTHRESH и BOQNAME были установлены неправильно. Теперь есть BOQNAME = и BOTHRESH=0. Теперь циклы MDB постоянно терпят неудачу, и активация никогда не останавливается. я отредактирую свой пост   -  person titou10    schedule 07.03.2019
comment
В трассировке вы можете сказать, как RA проверяет, работает ли он в профиле Websphere Liberty? В случае того, как это работает сейчас с BOTHRESH = 0, есть ли проблема с получением сообщения несколько раз? Пока он отменяется, вы по-прежнему сохраняете порядок FIFO.   -  person JoshMc    schedule 08.03.2019
comment
@JoshMc в каком-то смысле вы правы, FIFO следует поддерживать, но сервер вращается, пытаясь обработать сообщение с кучей журналов, используя процессор и т. Д. Активация должна приостанавливаться, как в WAS и в WebSphere Liberty.   -  person titou10    schedule 08.03.2019
comment
Я не знаю, как он определяет WLP, OL и WAS. Я потратил некоторое время на поиск в самом rar, и было бы трудно переопределить, поскольку rar ожидает найти JMX-бины для активации в определенном пространстве имен, причем пространство имен различается между WLP и OL. Он использует JMX Bean для приостановки или возобновления MDB/активации, например, если достигнуто значениеmaxSequentialDeliveryFailures. Так что просто схитрите и найдите способ притвориться, что это сервер WLP, это не сработает.   -  person titou10    schedule 08.03.2019
comment
притворяться, что я собирался предложить, но имеет смысл, что это будет не так просто.   -  person JoshMc    schedule 08.03.2019
comment
Еще одно предложение: BOTHRESH(1) BOQNAME('') убедитесь, что у приложения НЕТ доступа для размещения в DLQ, убедитесь, что сообщение сохраняется. Обратите внимание, что сообщение также не может иметь параметр отчета MQRO_DISCARD_MSG, но на основании того, что вы описали ранее, он не установлен, иначе оно никогда не попыталось бы перейти к DLQ. На странице IBM KC 'Удаление сообщений из очереди в ASF документирует следующее:   -  person JoshMc    schedule 08.03.2019
comment
Если опасное сообщение не может быть повторно поставлено в очередь, возможно, из-за того, что очередь недоставленных сообщений заполнена или авторизация указана неправильно, то, что произойдет, зависит от сохраняемости сообщения. Если сообщение непостоянно, оно отбрасывается и отчетное сообщение не создается. Если сообщение сохраняется, доставка сообщений всем потребителям соединений, прослушивающим этот пункт назначения, прекращается. Такие потребители соединений должны быть закрыты, а проблема решена, прежде чем их можно будет воссоздать и перезапустить доставку сообщений.   -  person JoshMc    schedule 08.03.2019
comment
Это может быть обходной путь к тому, чего вы хотите достичь. Стоит попробовать.   -  person JoshMc    schedule 08.03.2019
comment
@JoshMc Я проверю это в понедельник. Тем временем я открыл билет для Open Liberty: github.com/OpenLiberty/open-liberty /вопросы/6839   -  person titou10    schedule 09.03.2019
comment
Как прошло тестирование? Было интересно узнать, что получилось :)   -  person JoshMc    schedule 11.03.2019
comment
Я не знаю. Мне довольно сложно быть уверенным, что приложение пока не имеет доступа к DLQ. сBOTHRESH(1)+BOQNAME('') сообщение идет в сSYSTEM.DEAD.LETTER.QUEUE. На данный момент мы решили разделить приложение на 2, 1 онлайн и один бесконечный пакет и удалить MDB из онлайн-приложения.   -  person titou10    schedule 12.03.2019
comment
Запускается ли ваше приложение от имени пользователя в группе mqm. Администраторы Windows также имеют полные права.   -  person JoshMc    schedule 12.03.2019