Я использую узел сборщика в своем потоке сообщений. Он настроен на сбор 50 сообщений или ожидание 30 секунд. При нагрузочном тестировании Websphere MQ иногда сообщает, что обнаружена длительная транзакция, и pid соответствует pid группы выполнения приложения. Возникает вопрос: возможно ли, что узел сборщика не зафиксирует свою внутреннюю транзакцию во время ожидания сообщений или истечения тайм-аута?
Коллекторный узел МИБ и транзакции
comment
Чтобы ответить на ваш вопрос: да, он не фиксируется, пока не истечет время ожидания или не достигнет счетчика. См. ibm.com /support/knowledgecenter/en/SSMKHH_10.0.0/
- person JoshMc schedule 07.09.2019
comment
@JoshMc, да, опубликуйте, пожалуйста. На самом деле, я не понял из ссылки при условии, что транзакция не завершится, пока все сообщения не будут получены, но я верю в ваш опыт работы с WebSphere
- person gisly schedule 09.09.2019
Ответы (2)
Узел MQInput - это место, где указывается транзакционность. Это описано на странице IIB v10 KC Разработка интеграционных решений> Разработка потоков сообщений> Поведение потока сообщений> Изменение поведения потока сообщений> Настройка транзакций для потоков сообщений> Настройка узлов MQ для транзакций
- Если вы установите для свойства значение Да (параметр по умолчанию): если транзакция еще не выполняется, узел запускает транзакцию.
Узел-сборщик не выполняет фиксацию, пока не истечет время ожидания или не достигнет счетчика. См. Страницу IIB v10 KC Справка> Разработка потока сообщений> Встроенные узлы> Узел сборщика
Все входные сообщения, полученные в точке синхронизации от транзакции или потока узлом сборщика, хранятся во внутренних очередях. Сохранение входных сообщений в точке синхронизации гарантирует, что сообщения остаются в согласованном состоянии для обработки исходящим потоком; такие сообщения доступны только в конце транзакции или потока, распространяющего входные сообщения.
A new transaction is created when a message collection is complete, and is propagated to the next node.
person
JoshMc
schedule
09.09.2019
Каждый раз, когда вы настраиваете какой-либо узел (который соответствует требованиям документации IBM) для работы в рамках транзакции, они не фиксируются, пока не будет завершена единица работы. В вашем случае, поскольку 50 сообщений (если они получены за 30 секунд) запрашиваются в одной единице работы, поток сообщений, который имеет узел сборщика и все другие узлы в этом потоке, фиксируется после успешной обработки всех 50 сообщений. В течение этого периода времени администратор очередей должен поддерживать это состояние «на лету» в своих журналах, о чем я говорил ранее, и которое необходимо было увеличить. Таким образом, любая большая единица работы вызывает эту проблему независимо от используемого узла.
Поскольку ваша проблема связана с длительной транзакцией MQ, убедитесь, что у вас достаточно места в журнале MQ для обработки транзакции диспетчером очередей.
Чтобы увеличить пространство журнала MQ, перейдите по указанному ниже пути и увеличьте первичный и вторичный номер.
==> IBM\WebSphere MQ\qmgrs\QMNAME\qm.ini
Ниже представлен контент, который вам нужно увеличить. По умолчанию это 3 и 2. Убедитесь, что на вашем диске достаточно места до любого числа, до которого вы его увеличиваете. После обновления файла qm.ini перезапустите диспетчер очередей.
Log:
LogPrimaryFiles=3
LogSecondaryFiles=2
Ссылка на конфигурацию MQ на: https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.con.doc/q018710_.htm
Надеюсь это поможет.
person
Rohan
schedule
06.09.2019
Спасибо, вот что мы сделали. Но вопрос заключался в том, является ли узел-сборщик причиной длительной транзакции.
- person gisly; 09.09.2019
Каждый раз, когда вы настраиваете какой-либо узел (который соответствует требованиям документации IBM) для работы в рамках транзакции, они не фиксируются, пока не будет завершена единица работы. В вашем случае, поскольку 50 сообщений (если они получены за 30 секунд) запрашиваются в одной единице работы, поток сообщений, который имеет узел сборщика и все другие узлы в этом потоке, фиксируется после успешной обработки всех 50 сообщений. В течение этого периода времени администратор очередей должен поддерживать это состояние «на лету» в своих журналах, о чем я говорил ранее, и которое необходимо было увеличить. Таким образом, любая большая единица работы вызывает эту проблему независимо от используемого узла.
- person Rohan; 09.09.2019
