Потоки Spring JmsTemplate Daemon, которые остаются в живых после остановки приложения tomcat

1

Я отправляю сообщение в IBM WebSphere MQ (версия mq jar - 7.0.1.9, а javax.jms - 1.1), используя класс Spring JmsTemplate из моего веб-приложения.

Соединение, которое я использую, это MQQueueConnectionFactory.

Следующие темы демон созданы на выполнение отправки() на JmsTempalte и инстанцировании MQQueueConnectionFactory.

ПРОБЛЕМА

Я получаю сообщение в командной строке tomcat, показывающее эти три потока как утечку памяти, когда я останавливаю веб-приложение на странице администрирования tomcat. Нити демона

ОТ JCONSOLE

THREAD 1

Имя: JMSCCThreadPoolMaster Состояние: ОЖИДАНИЕ на java.lang.Object@9f6e3e9 Всего заблокировано: 3 Всего ждали: 4

Трассировка стека: java.lang.Object.wait (собственный метод) java.lang.Object.wait(Object.java:485) com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation $ WorkQueueManagerThread.waitForNotification(WorkQueueManagerImplementation. java: 651) com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation $ WorkQueueManagerThread.waitForNotification(WorkQueueManagerImplementation.java:621) com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation $ WorkQueueManagerThread.run( WorkQueueManagerImplementation.java:887)

РЕЗЬБА 2

Имя: JMSCCThreadPoolWorker-2 Состояние: ОЖИДАНИЕ на com.ibm.mq.jmqi.remote.internal.RemoteReconnectThread$ReconnectMutex@3d3c3e45 Всего заблокировано: 0 Всего ждали: 1

Трассировка стека: java.lang.Object.wait (собственный метод) java.lang.Object.wait(Object.java:485) com.ibm.mq.jmqi.remote.internal.RemoteReconnectThread.bestHconn(RemoteReconnectThread.java:672) com.ibm.mq.jmqi.remote.internal.RemoteReconnectThread.run(RemoteReconnectThread.java:129) com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:209) com.ibm.msg. client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:100) com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:224) com.ibm.msg.client.commonservices.workqueue. WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:298) com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation $ ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220)

THREAD 3 (умирает через минуту)

ЭТО ОДИН создан при создании MQQueueConnectionFactory

Имя: WebSphere MQ Trace Monitor Состояние: TIMED_WAITING Всего заблокировано: 0 Всего ждали: 5

Трассировка стека: java.lang.Thread.sleep (собственный метод) com.ibm.mq.commonservices.internal.monitor.TraceMonitor.run(TraceMonitor.java:134)

Как убедиться, что эти потоки демонов умирают.

Теги:
spring
ibm-mq
jmstemplate
tomcat6

2 ответа

0
Лучший ответ

мой контекст Spring не закрывался должным образом, и фабрика JMS Connection управлялась моим весенним контейнером, поэтому она вызвала утечку.

  • 0
    Вы пытались использовать транзакционный источник контекста?
  • 0
    Привет, да, я устал от фабрики соединений транзакций для JMS, имел ту же проблему.
0

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню