IBM MQ automatic client reconnection to multi-instance queue manager

В среде WebSphere MQ, где используется multi-instance менеджер очередей, необходимо обеспечить переподключение приложений-клиентов к другому инстансу менеджера в случае сбоев.

Начиная с версии WebSphere MQ V7.0.1.3, для поддержки автоматического переподключения клиентов, в фабрике соединений (Connection Factory, CF) добавлено свойство CLIENTRECONNECTOPTIONS.

Этот параметр используется в связке с одним из двух параметров CF: CONNECTIONNAMELIST и CCDTURL, которые определяют как и к каким менеджерам будет подключаться приложение. В данной статье мы рассмотрим автоматическое переподключение с использованием параметра CONNECTIONNAMELIST.

Свойство CLIENTRECONNECTOPTIONS может принимать следующие значения:

  • QMGR – Приложение переподключается к менеджеру очередей, к которому оно было подключено изначально, т.е. который определен в параметре  QMANAGER фабрики соединений.

    Выберите это значение, если приложению необходимо автоматически переподключиться к standby инстансу multi-instance менеджера очередей.

    Для использования этого значения в программе используется константа WMQConstants.WMQ_CLIENT_RECONNECT_Q_MGR.

  • ANY – Приложение может переподключиться к любому менеджеру очередей.

    Используется при подключении к менеджерам очередей через таблицу определений каналов (client channel definition table). Для этого параметр  QMANAGER фабрики соединений должен быть установлен в одно из значений:

    • Символ “*”;
    • Шаблон имени группы менеджеров очередей, в котором используется символ “*”;
    • Пустая строка или строка заполненная пробелами;

    Для использования этого значения в программе используется константа WMQConstants.WMQ_CLIENT_RECONNECT.

  • DISABLED – Переподключение не выполняется, в приложение возвращается JMSException.

    Для использования этого значения в программе используется константа WMQConstants.WMQ_CLIENT_RECONNECT_DISABLED.

  • ASDEF – Автоматическое переподключение приложения зависит от значения атрибута DefReconnect, установленного на канале.

    Для использования этого значения в программе используется константа WMQConstants.WMQ_CLIENT_RECONNECT_AS_DEF.

Приложение, по средствам классов WebSphere MQ для JMS, использует фабрику соединений, имеющую следующий набор параметров для обеспечения автоматического переподключения к multi-instance менеджеру очередей:

  • CHANNEL = имя канала для подключения к менеджеру (константа WMQConstants.WMQ_CHANNEL);
  • CLIENTRECONNECTOPTIONS = QMGR (константа WMQConstants.WMQ_CLIENT_RECONNECT_Q_MGR);
  • CONNECTIONNAMELIST = адреса хостов и порты multi-instance менеджера очередей в формате: hostname1(port1), hostname2(port2) (константа WMQConstants.WMQ_CONNECTION_NAME_LIST);
  • QMANAGER = имя менеджера очередей (константа WMQConstants.WMQ_QUEUE_MANAGER);

Подробнее вопрос автоматического переподключения клиентов рассматривается в техноуте, и в разделе “Automatic client reconnection” IBM Knowledge Center.

Мы же рассмотрим пример реализации автоматического переподключения к multi-instance менеджеру очередей из standalone java-приложения:

В нашем примере приложение, используя фабрику соединений, подключается по каналу TEST.CHANNEL к активному инстансу менеджера очередей QM1, расположенному на хосте my-wmq-test01(1414). В случае штатного или аварийного завершения работы активного инстанса, приложение переключится на stand-by инстанс менеджера очередей, который запущен на хосте my-wmq-test02(1414).

Параметр, задаваемый константой WMQConstants.WMQ_CLIENT_RECONNECT_TIMEOUT, определяет величину тайм-аута в секундах, по истечению которого клиент прекращает попытки соединиться с менеджером. Если этот параметр не установлен, то используется параметр WMQ_CLIENT_RECONNECT_TIMEOUT_DEFAULT, который равен 1800 секунд.

По умолчанию, переподключение происходит так:

  • Первая попытка производится после задержки в 1 секунду + случайный интервал, величиной до 250 миллисекунд;
  • Вторая попытка производится через 2 секунды + случайный интервал до 500 миллисекунд, после первой;
  • Третья попытка производится через 4 секунды + случайный интервал до 1 секунды, после неудачной второй попытки;
  • Четвертая попытка производится через 8 секунд + случайный интервал до 2 секунд, после третьей попытки;
  • Пятая попытка производится через 16 секунд + случайный интервал до 4 секунд, после четвертой попытки;
  • Шестая и все последующие попытки производятся через 25 секунд + случайный интервал до 6 секунд 250 миллисекунд, после предыдущей попытки.

24.01.2017 Update:
What reason codes should be used to drive reconnection logic in JMS applications?

VN:F [1.9.22_1171]
Rating: 4.8/5 (4 votes cast)
Метки: , , , ,
Опубликовано в Development, WebSphere MQ, Тюнинг
8 комментариев на “IBM MQ automatic client reconnection to multi-instance queue manager
  1. Иван:

    I have got few queries regarding switch over, fail over and auto reconnect in multi instance MQ. while going through IBM Documentation on this.

    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. cru5ader:

    Спасибо за пост.
    Вопрос, допустим после сбоя приложение переключилось на stand-by инстанс менеджера очередей , а спустя какое-то время активный инстанс поднялся/подняли, как сделать чтоб автоматически переехало приложение на активный?

    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
    • Sergey Kirsanov Sergey Kirsanov:

      Спасибо за комментарий.
      Дело в том, что IBM MQ в режиме multi-instance имеет один active instance и один standby instance на разных хостах.
      Приложения/клиенты всегда работают с active instance.
      В случае сбоя, когда active instance становится недоступен, standby instance становится активным и приложения переключаются на него.
      После устранения проблем бывший active instance можно поднять как новый standby.
      Надеюсь понятно ответил)

      VN:F [1.9.22_1171]
      Rating: 0 (from 0 votes)
      • cru5ader:

        Спасибо за оперативный ответ!
        Я только не понял , как после устранения проблем бывший active instance можно поднять как новый standby?

        VA:F [1.9.22_1171]
        Rating: 0 (from 0 votes)
        • Sergey Kirsanov Sergey Kirsanov:

          Это особенность работы IBM MQ в режиме multi-instance.
          Выполняешь команду на запуск инстанса, а менеджер смотрит, если ли сейчас нет активного инстанса, то он поднимет его, если активный инстанс уже запущен, то новый инстанс запустится как standby.

          VN:F [1.9.22_1171]
          Rating: 0 (from 0 votes)
  3. cru5ader:

    ………В случае штатного или аварийного завершения работы.
    Как IBM понимает что, аварийно или штатно завершилась работа, т.е. сколько попыток с каким интервалом он делает. прежде ем пытатсья подключиться к резервному узлу?

    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Выбор языка: