Webapp зависает, когда работает активный брокер MQ

Question

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

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

1. Обновленный ActiveMQ Версия для 5.10.1
2. Используется автономный ActiveMQ вместо Maven-плагин
3. переехал брокер работает от отдельного JVM (с помощью активного MQ Maven плагина, подключения через JNDI поиск в причале конфигурации) в одной и тот же виртуальную машину Java (начатый с помощью пружинной конфигурации, без JNDI)
4. изменил активную mq транспорт из ТСРА 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) 

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

Answer 1

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