Websphere MQ Message Бесконечный процесс

Question

Я новичок в очереди сообщений. Я собираюсь получать сообщения из очереди MQ, используя приведенный ниже код.

Я создаю одно соединение и получаю каждое сообщение из очереди, используя это соединение. Правильно ли это так, и нужно ли мне связывать это соединение.

Бесконечный для петли правильный способ получать сообщения все время от очереди, правильно? Прошу совета.

try { 
    createMQConnection(); // getting mq connection 
    createMQSession(); // getting mq session 
    createMQDestination(); // getting mq destination 

    for (; ;) { // infinite loop to receive message from Queue 
     consumer = session.createConsumer(mqQueue); 
     jmsTextMessage = (JMSTextMessage) consumer.receive(100); 
     // Calling application method to process the requested message from queue 
    } 
} catch (Exception e) { 
    throw e; 
} finally { 
    // closing consumer 
    // closing session 
    // closing connection 
} 

Answer 1

Я бы для многопоточных приложений, где каждый поток выполняет следующие функции:

1) Подключение к очереди менеджера.

2) Создайте потребителя для очереди.

3) Настройка прослушивателя сообщений для получения сообщений асинхронно. Если это не подходит, перейдите для получения синхронного сообщения, используя метод receive().

4) Очистите, когда будет выполнено сообщение.

Преимущество этого: нитки, получающие сообщения из соответствующей очереди и по какой-либо причине не блокируются.

Answer 2

Является ли это правильный способ сделать это, как

Определение "вправо". В зависимости от бизнес-требований это может быть правильным, или это может быть ужасно. Например, при времени ожидания 100 мс и глубине нулевого сообщения код будет тайм-аут, выбросить ошибку 2033 (MQRC_NO_MSG_AVAILABLE), закрыть сеанс и выйти. Это то, что вы хотите?

Вообще есть try/catch блок заключая GET и обрабатывает временные ошибки, как RC=2033 если намерение состоит в том, что программа продолжает работать даже тогда, когда очередь пуста. В этом случае, однако, принято устанавливать тайм-аут до 10 секунд или около того. При тайм-ауте 100 мс приложение, как написано, абсолютно забило бы слушателя, если бы оно было изменено, чтобы оставаться включенным.

Кроме того, обработка исключений не отображает код для печати связанного исключения. Исключениями JMS являются многоуровневые структуры данных, в которых собственный код ошибки поставщика транспорта находится в связанной части исключения. Если обработка ошибок не смотрит на связанное исключение, она не может даже рассказать разницу между MQRC=2033 (нет сообщений) по сравнению с MQRC=2035 (ошибка авторизации). Одна из них преходяща и должна быть сохранена программой, другая всегда смертельна. По крайней мере, код должен либо печатать связанное исключение, либо печатать сообщение, в котором не было обнаружено никакого связанного исключения.

Так что в отношении цикла и дизайна обработки невозможно получить значения «справа», не зная требований. Что касается обработки исключений, определенно не право, так как отсутствует связанная обработка исключений.

... и должен ли я зафиксировать соединение.

Зависит. Можно ли потерять или дублировать сообщения?Если это так, транзакции не нужны. Использование транзакционных сеансов защищает от потери сообщений, но не обманывает. Использование XA 2-Phase Commit защищает как от потери сообщений, так и от обманов. Идея состоит в том, чтобы выбрать класс обслуживания (обычно называемый «Не более одного раза», «По крайней мере один раз» или «Один раз и только один раз»), который соответствует бизнес-требованиям и коду соответственно.

Бесконечный для петли правильный способ получать сообщения все время от очереди, правильно?

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

Также принято, что GET в очереди указывает MQGMO_FAIL_IF_QUIESCING, что позволяет QMgr прерывать приложение, когда MQ Admin пытается закрыть QMgr. Если этот параметр не указан, единственное, что нужно для закрытия QMgr, - попросить его принудительно разорвать выдающиеся соединения, и это должно быть сделано только в крайнем случае.

Также возможно заставить MQ инициировать запуск приложения, когда сообщение поступило в очередь. Обычно это не делается, когда приложение работает на JEE-сервере, но очень полезно для stand = -alone приложений.