WSO2 ESB 4.9.0: настройка числа слушателей JMS-очереди

Проблема

Есть несколько прокси-сервисов, слушающих различные JMS-очереди (в качестве JMS-сервера используется Apache ActiveMQ). В каждом прокси-сервисе число слушателей настроено через соотв. параметры:

<parameter name="transport.jms.ConcurrentConsumers">25</parameter>
<parameter name="transport.jms.MaxConcurrentConsumers">25</parameter>

Однако, в действительности при большой интенсивности поступления сообщений в очереди шина ведет себя достаточно странно. Суммарное число слушателей всех очередей никогда не превосходит 20, причем эти 20 слушателей иногда распределяются между очередями совершенно неприемлемым образом: одна из очередей остается вообще без слушателей (несмотря на поступление в нее сообщений), а все доступные слушатели переключаются на другую очередь, в которую интенсивно поступают сообщения.

Решение

Максимальное число слушателей для очередей ограничивается не только соотв. параметром, задаваемым на уровне прокси-сервиса. Во-первых, его можно настроить на глобально для всего JMSListener'а на уровне axis2.xml:

<transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">
 <parameter name="MYJMS" locked="false">
  <parameter name="java.naming.factory.initial" locked="false">
    org.apache.activemq.jndi.ActiveMQInitialContextFactory
  </parameter>
  <parameter name="java.naming.provider.url" locked="false">
    tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=0
  </parameter>
  <parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">
    QueueConnectionFactory
  </parameter>
  <parameter name="transport.jms.ConnectionFactoryType" locked="false">
    queue
  </parameter>
  <parameter name="transport.jms.ConcurrentConsumers" locked="false">
    50
  </parameter>
  <parameter name="transport.jms.MaxConcurrentConsumers" locked="false">
    50
  </parameter>
 </parameter>
</transportReceiver>

Задаваемые здесь ограничения имеют приоритет над указываемыми на уровне прокси-сервиса. Но в данном случае в axis2.xml никаких ограничений прописано не было, так что проблема была в другом. JMS-слушатели формируются из ограниченного пула "server workers", размер которого настраивается системными свойствами snd_t_core и snd_t_max. Значение по-умолчанию равно тем самым 20, в которые мы и упираемся. Прописываем в wso2seerver.sh параметр -Dsnd_t_max=<N>, где N нужно выбрать таким образом, чтобы сумма значений transport.jms.MaxConcurrentConsumers, заданных во всех прокси-сервисах, слушающих JMS-очереди, не превышала этого значения.

Спасибо http://wso2.com/library/articles/2012/06/wso2-esb-example-processing-long-message-backlog/.