2017-01-27 17 views
2

У меня проблема с одним из наших приложений. Приложение является самозаписывающимся Java-приложением, которое подключается через JMS к более чем 50 различным очередям сообщений и потребляет сообщения из этих очередей.Блокировка потоков с помощью bitronix

С функциональной точки зрения обработка всех сообщений из разных очередей работает нормально. Однако во время тестирования мы выяснили, что обработка разных сообщений далека. Мы можем обрабатывать только несколько сообщений в очереди в минуту.

Чтобы лучше понять, что происходит, я сделал с СВК flightrecording и увидел, что есть много времени блокировки для каждого потока, потребляющего сообщения из очереди сообщений:

Picture: Blocking JMS threads

Кроме этот график я видел также в записи полета, что много времени тратится на то, чтобы присоединиться к определенной WeakHashMap, чтобы закрыть и получить и XAResource.

Picture: Lock instances

Следующим шагом, что я сделал, анализируя, как конфигурация bitronix JMS выглядит. Вот соответствующие части:

На уровне сервера Tomcat я получил файл resource.properties, который загружается bitronix:

resource.cf1.className=com.ibm.mq.jms.MQXAQueueConnectionFactory 
resource.cf1.uniqueName=jms/cf 
resource.cf1.minPoolSize=1 
resource.cf1.maxPoolSize=60 
resource.cf1.driverProperties.hostName=genadev0059.mycompnany.com 
resource.cf1.driverProperties.port=1515 
resource.cf1.driverProperties.channel=APPL_CHL 
resource.cf1.driverProperties.transportType=1 
resource.cf1.driverProperties.queueManager=DEV 

Внутри Spring приложения XML У меня есть следующие определения боба в settup соединение:

<jee:jndi-lookup id="connectionFactory" jndi-name="jms/cf" resource-ref="true" proxy-interface="javax.jms.ConnectionFactory"/> 

<bean id="userCredentialsConnectionFactory" class="org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapter" p:targetConnectionFactory-ref="connectionFactory" p:username="$jms{jmsuser}" p:password="$jms{jmspwd}"/> 

<bean id="cachedConnectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory" p:sessionCacheSize="$fwk{jms.connectionFactory.sessionCacheSize}" p:targetConnectionFactory-ref="userCredentialsConnectionFactory"/> 

<bean id="parentJmsContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer" abstract="true" p:connectionFactory-ref="cachedConnectionFactory" p:sessionTransacted="true" p:transactionManager-ref="transactionManager" 

р: autoStartup = "$ {FWK jms.listener.start}" />

Дополнительно к этому, у меня есть для каждой очереди сообщений и самостоятельно класс, который обрабатывает сообщения из этой очереди:

<bean id="messageQueueThread1" parent="parentJmsContainer"> 
    <property name="destinationName" value="queue1" /> 
    <property name="messageListener"> 
      <bean class="com.mycompany.service.jms.Queue1Listener" /> 
    </property> 
</bean> 

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

Любые материалы или предложения приветствуются.

ответ

1

Сколько продуктов со значением "фактическое" есть в очереди менеджера? Вы должны использовать 1 соединение на поток. Если вы разделяете соединение между потоками, именно поэтому вы видите блокировку.

+0

Основываясь на том, что я контролировал через WebSphere MQ Administrator, я вижу, что существует много ** общих ** соединений для очередей, которые потребляются этим приложением. Далее я отслеживал с netstat, что происходит на стороне клиента, и там я вижу также много исходящих подключений к серверу MQ. Все они пересекают один и тот же порт 1515. Далее PID для всех из них - 2488. Интересно, что около 80% из них, состояние соединения «установлено», а на 20% оно «ждет» (с PID 0). Вопрос в том, как я могу влиять на это поведение по конфигурации – Tianico