Веб-приложение зависает при работе брокера Active MQ

У меня возникла странная проблема с моим весенним веб-приложением (работающим на локальном причале), которое подключается к локально работающему брокеру ActiveMQ для функций JMS. Как только я запускаю брокера, приложения становятся невероятно медленными, например. запуск ApplicationContext с активным брокером занимает вечность (т. е.> 10 минут, еще недостаточно долго для его завершения). Если я запускаю брокера после веб-приложения (т.е. после загрузки ApplicationContext), он работает, но очень-очень медленно (запросы, которые обычно занимают ‹1 с, занимают> 30 с). Все операции занимают больше времени, даже без участия JMS. Когда я запускаю приложение без брокера activemq, все работает гладко (конечно, кроме вещей, связанных с JMS ;-))

Вот что я пробовал до сих пор:

  1. Обновлена ​​версия ActiveMQ до 5.10.1.
  2. Используется автономный ActiveMQ вместо maven-плагина
  3. переместил брокера, работающего с отдельной JVM (через активный плагин mq maven, подключение через поиск JNDI в конфигурации причала) в ту же JVM (запущенную через конфигурацию spring, без JNDI)
  4. изменил активный транспорт mq с tcp на vm
  5. несколько настроек activemq (alwaysSyncSend, alwaysSessionAsync, ProducerWindowSize)
  6. Использование CachingConnectionFactory и PooledConnectionFactory

При анализе дампа потока (jstack) я вижу много потоков activemq, спящих на мониторе. Что выглядит так:

"ActiveMQ VMTransport: vm://localhost#0-3" daemon prio=6 tid=0x000000000b1a3000 nid=0x1840 waiting on condition [0x00000000177df000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000f786d670> (a java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:196)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
    at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:955)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:917)
    at java.lang.Thread.run(Thread.java:662)

Любая помощь очень ценится!


person Korgen    schedule 27.01.2015    source источник


Ответы (1)


Я нашел причину проблемы и смог ее исправить: мы передавали менеджер транзакций в AbstractMessageListenerContainer. В то время как в производстве используется XA-Transactionmanager в локальной среде причала, используется только JPATransactionManager. Судя по всему, JMS всегда ожидает подтверждения транзакции XA, чего никогда не происходит в локальной среде. Переопределяя определение bean-компонента AbstractMessageListenerContainer для локальной среды без установки менеджера транзакций, но вместо этого используя sessionTransacted="true", все работает нормально. У меня возникла идея, что это может быть связано с обработкой транзакций из-за включения ведения журнала ActiveMQ. При этом я увидел, что что-то не так с транзакцией (transactionContext.getTransactionId() вернул null).

person Korgen    schedule 27.01.2015