Регулирование сообщений IBM MQ

Question

Мы используем IBM MQ и сталкиваемся с некоторыми серьезными проблемами, связанными с управлением его асинхронной доставкой получателю. У нас настроены некоторые слушатели java, теперь проблема заключается в том, что нам нужно контролировать сообщения, поступающие к слушателю, потому что сообщения количество обращений к серверу исчисляется миллионами, и серверная машина не имеет такой большой мощности, чтобы обрабатывать столько потоков одновременно, поэтому есть ли способ регулирования на стороне IBM MQ, где мы можем настроить ограничение числа предварительных запросов, как это делает Apache MQ?

или есть другой способ добиться этого?

В настоящее время мы закрываем соединение с IBM MQ, когда для прослушивателя достигнут некоторый предел X, но это не представляется эффективным способом.

Пожалуйста, ребята, помогите нам решить эту проблему.

Answer 1

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

Очевидный ответ - ограничить максимумколичество потоков, которые ваши слушатели могут принимать.Я предполагаю, что вы используете какой-то MQ threadpool?Какую платформу вы используете, которая предоставляет неограниченные потоки прослушивателей?

Из вашего описания почти похоже, что у вас запущен какой-то процесс, который - как только он обнаруживает сообщение в очереди - он читает сообщение, запускаетсяновый поток и возвращается и смотрит на очередь снова.Это неправильный подход.

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

Надеюсь, это поможет.

Answer 2

Если вы работаете в среде сервера приложений, то свойство maxPoolDepth в ActivationSpec определит максимальный размер ServerSessionPool для MDB - уменьшение этого значения приведет к снижению количества одновременно доставляемых сообщений.

Конечно, если ваш MDB (или javax.jms.MessageListener в среде JSE) не делает ничего, кроме как передает сообщение чему-то другому (или, что еще хуже, просто порождает неуправляемый поток и запускает его), onMessage будет вращатьсябыстро, и вы все еще можете столкнуться с проблемами.Таким образом, в этом случае вам также необходимо ограничить другие ресурсы, например, через конфигурацию пула потоков.

Закрытие соединения с QM никогда не является эффективным способом, поскольку цикл MQCONN / MQDISC стоит дорого.