Потребление сообщений IBM Liberty с переключением при сбое - PullRequest
1 голос
/ 11 апреля 2019

Мы разрабатываем решение, которое будет использовать сообщения от IBM MQ с использованием JMS. Планируется использовать WAS Liberty, поэтому JMS - это технология выбора. Мы создадим компоненты Message-Drive, которые будут прослушивать сообщения в очередях MQ.

Мы рассматриваем как WAS Liberty, так и OpenLiberty.

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

Я знаю, что адаптер MQ необходимо установить, поскольку он не поставляется "из коробки".

У меня есть следующие вопросы:

  1. Поддерживает ли реализация обмена сообщениями WAS Liberty аварийное переключение? Это означает, что в случае сбоя узла-потребителя сообщений резервный узел автоматически мигрирует и начинает потреблять сообщения из MQ? А как насчет OpenLiberty?
  2. Как мне настроить систему сообщений таким образом? Можете ли вы указать на документацию?

Или эта функция предоставляется только WebSphere?

1 Ответ

2 голосов
/ 12 апреля 2019

В WebSphere Liberty или Open Liberty таких функций еще нет.Вы можете создать RFE здесь https://www.ibm.com/developerworks/rfe/?PROD_ID=544.Есть способы сделать это вручную, проверьте эти ссылки:

Решение, которое вы можете сделать:

  • создайте скрипт / приложение, которое будет отслеживать ваши серверы и вызывать этот API для включения/ отключить конечную точку на конкретном сервере
  • или использовать функцию динамического кластера / автоматического масштабирования Liberty и разделить ваше приложение на два кластера - один с MDB, другой без.И затем определите политику, что кластер MDBs всегда имеет 1 экземпляр.Поэтому, как только сервер умирает, он автоматически перезапускается где-нибудь в кластере
  • или использует платформу Kubernetes / ICP таким же образом - поэтому развертывание 2 версий приложения и определение различных параметров репликаций.
...