Есть прокси-сервис, слушающий 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:
- Устанавливаем очень большое значение параметра transport.jms.IdleTaskLimit (т.к. бесконечное значение установить нельзя, можно поставить, к примеру, 2147483647)
- Устанавливаем бесконечный таймаут ожидания получателем сообщения путем установки параметра transport.jms.ReceiveTimeout в -1
Комментариев нет:
Отправить комментарий