barbitoff programmer`s blog

Здесь я публикую заметки из программерской жизни: грабли, на которые мне случилось наступить, проблемы, для которых было найдено элегантное (или не очень) решение, а также все, с чем мне пришлось столкнуться и чем хотелось бы поделиться =)
PS Если хотите меня поблагодарить - на странице есть 3 места, чтобы это сделать =)

воскресенье, 18 декабря 2016 г.

WSO2 ESB: как отключить динамическую регулировку числа потоков, слушающих JMS-очередь

Есть прокси-сервис, слушающий JMS-очередь. Работа в несколько потоков для него настроена параметрами transport.jms.ConcurrentConsumers и transport.jms.MaxConcurrentConsumers (см. http://axis.apache.org/axis2/java/transports/jms.html). Однако, каким бы ни было значение transport.jms.ConcurrentConsumers, в "состоянии покоя", т.е. когда в очереди-источнике сообщений нет, на очереди висит только 1 получатель. По мере появления сообщений в очереди число получателей растет вплоть до указанного в transport.jms.MaxConcurrentConsumers ограничения. Затем, после опустошения очереди, получатели начинают отключаться, пока снова не остается только 1 получатель.
Объясняется такое поведение вот чем. Изначально шина создает для очереди столько слушателей, сколько указано в параметре transport.jms.ConcurrentConsumers. Каждый получатель начинает цикл опроса очереди, при этом на каждой итерации он ожидает получения сообщения в течение некоторого промежутка времени, заданного параметром transport.jms.ReceiveTimeout (по-умолчанию 1000мс). После определенного числа "холостых" итераций, в результате которых таймаут вышел, а сообщение так и не было получено, слушатель самозавершается. Число итерацией определяется параметром transport.jms.IdleTaskLimit и по-умолчанию равно 10. В итоге, через примерно 10 секунд завершаются все слушатели кроме одного "дежурного", который не завершается ни при каких обстоятельствах.
Данная ситуация не во всех случаях может устраивать, иногда нужно, чтобы очередь всегда слушало фиксированное число слушателей (например, при использовании группировки сообщеий). Тут варианта 2:
  1. Устанавливаем очень большое значение параметра transport.jms.IdleTaskLimit (т.к. бесконечное значение установить нельзя, можно поставить, к примеру, 2147483647)
  2. Устанавливаем бесконечный таймаут ожидания получателем сообщения путем установки параметра transport.jms.ReceiveTimeout в -1

Комментариев нет:

Отправить комментарий