Сбой адаптера канала, управляемого сообщениями Spring Integration, jms

Я использую весеннюю интеграцию 4.1.0 для реализации потребления сообщений из очереди TIBCO EMS с помощью jms-int: message-driven-channel-adapter

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

Ниже показано, как определяются адаптеры канала, управляемые сообщениями.

<int-jms:message-driven-channel-adapter
        id="mdca1" connection-factory="connectionFactory1"
        channel="jmsChannel1" destination="queueName1"
        error-channel="errorChannel" max-concurrent-consumers="5" auto-startup="true"/>

<int-jms:message-driven-channel-adapter
        id="mdca2" connection-factory="connectionFactory2"
        channel="jmsChannel2" destination="queueName2"
        error-channel="errorChannel" max-concurrent-consumers="5" auto-startup="true"/>

<bean id="connectionFactory1" class="org.springframework.jms.connection.CachingConnectionFactory">
    <property name="targetConnectionFactory" ref="tcf1"/>
    <property name="sessionCacheSize" value="${sessionCacheSize}"/>
    <property name="cacheProducers" value="${cacheProducers}"/>
    <property name="cacheConsumers" value="${cacheConsumers}"/>
</bean>
<bean id="tcf1" class="${connectionFactoryClassName}">
        <property name="serverUrl" value="${serverUrl1}" />
        <property name="userName" value="${username1}" />
        <property name="userPassword" value="${password1}" />
    </bean>

<bean id="connectionFactory2" class="org.springframework.jms.connection.CachingConnectionFactory">
    <property name="targetConnectionFactory" ref="tcf2"/>
    <property name="sessionCacheSize" value="${sessionCacheSize}"/>
    <property name="cacheProducers" value="${cacheProducers}"/>
    <property name="cacheConsumers" value="${cacheConsumers}"/>
</bean>
<bean id="tcf2" class="${connectionFactoryClassName}">
        <property name="serverUrl" value="${serverUrl2}" />
        <property name="userName" value="${username2}" />
        <property name="userPassword" value="${password2}" />
    </bean>

У меня есть приложение, развернутое на Tomcat, и все работает нормально. Все адаптер считывает сообщение из очереди и отправляет на обработку.

Но по какой-то причине через какое-то время сообщения не забираются из очереди. В настоящее время мне нужно перезапустить tomcat, чтобы адаптер снова заработал. У меня есть кнопка в пользовательском интерфейсе для запуска / остановки адаптера, но она не работает, когда адаптер перестает выбирать сообщение из очереди. Кнопки Start / Stop также работают нормально, когда сообщение принимает адаптер. Я могу остановиться, и адаптер перестанет собирать сообщение, и я могу начать, и адаптер начнет собирать сообщение. Проблема заключается в том, что мой адаптер какое-то время работает, и, скажем, через 5-10 часов в очереди появляется сообщение, адаптер не выбирает, даже если он находится в рабочем состоянии. Кнопка тоже перестает работать.

Может ли кто-нибудь помочь, в чем может быть проблема? Почему адаптеры выходят из строя через определенное время, например, 5-10 часов?

Любая помощь высоко ценится.

Обновление: вот трассировка стека из jstack, когда слушатель терпит неудачу.

"TIBCO EMS TCPLink Reader (Server-15108908)" daemon prio=10 tid=0x00007f1874115000 nid=0xc8f runnable [0x00007f18b2f1d000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:152)
    at java.net.SocketInputStream.read(SocketInputStream.java:122)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
    - locked <0x00000006c2d8ea68> (a java.io.BufferedInputStream)
    at java.io.DataInputStream.readInt(DataInputStream.java:387)
    at com.tibco.tibjms.TibjmsxLinkTcp._readWireMsg(TibjmsxLinkTcp.java:625)
    at com.tibco.tibjms.TibjmsxLinkTcp$LinkReader.work(TibjmsxLinkTcp.java:280)
    at com.tibco.tibjms.TibjmsxLinkTcp$LinkReader.run(TibjmsxLinkTcp.java:259)

"org.springframework.jms.listener.DefaultMessageListenerContainer#1-5" prio=10 tid=0x00000000019de000 nid=0xc8e in Object.wait() [0x00007f18b301e000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000006c2eabdf8> (a java.lang.Object)
    at com.tibco.tibjms.TibjmsxSessionImp._getSyncMessage(TibjmsxSessionImp.java:2288)
    at com.tibco.tibjms.TibjmsxSessionImp._receive(TibjmsxSessionImp.java:2122)
    - locked <0x00000006c2eabdf8> (a java.lang.Object)
    at com.tibco.tibjms.TibjmsMessageConsumer._receive(TibjmsMessageConsumer.java:276)
    at com.tibco.tibjms.TibjmsMessageConsumer.receive(TibjmsMessageConsumer.java:481)
    at        org.springframework.jms.connection.CachedMessageConsumer.receive(CachedMessageConsumer.java:82)
    at   org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveMessage(AbstractPollingMessageListenerContainer.java:413)
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:293)
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:246)
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1142)
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1134)
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1031)
    at java.lang.Thread.run(Thread.java:745)

"org.springframework.jms.listener.DefaultMessageListenerContainer#3-2" prio=10 tid=0x00007f18ac001000 nid=0xc8d in Object.wait() [0x00007f18b311f000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000006c2e30270> (a java.lang.Object)
    at com.tibco.tibjms.TibjmsxSessionImp._getSyncMessage(TibjmsxSessionImp.java:2288)
    at com.tibco.tibjms.TibjmsxSessionImp._receive(TibjmsxSessionImp.java:2122)
    - locked <0x00000006c2e30270> (a java.lang.Object)
    at com.tibco.tibjms.TibjmsMessageConsumer._receive(TibjmsMessageConsumer.java:276)
    at com.tibco.tibjms.TibjmsMessageConsumer.receive(TibjmsMessageConsumer.java:481)
    at org.springframework.jms.connection.CachedMessageConsumer.receive(CachedMessageConsumer.java:82)
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveMessage(AbstractPollingMessageListenerContainer.java:413)
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:293)
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:246)
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1142)
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1134)
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1031)
    at java.lang.Thread.run(Thread.java:745)

Любые комментарии?


person zdesam    schedule 24.06.2015    source источник


Ответы (1)


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

Для диагностики возьмите дамп потока (например, jstack), когда происходит зависание, чтобы узнать, что делают потоки контейнера слушателя.

person Gary Russell    schedule 24.06.2015
comment
Да, спасибо. Этого не происходит при локальном запуске activemq в качестве поставщика jms. Но на сервере, на котором используется очередь TIBCO ems, это происходит, когда в течение определенного периода времени в очереди нет сообщений, и после этого интервала, когда сообщение появляется в очереди, прослушиватель jms интеграции Spring не принимает их. . - person zdesam; 24.06.2015
comment
Есть ли способ повторно запустить адаптер канала, управляемый сообщениями, без перезапуска сервера после такого сбоя? - person zdesam; 24.06.2015
comment
Как я уже сказал, ничего нельзя сделать, если поток застрял в непрерывном состоянии в вашем пользовательском коде - вам нужно сделать дамп потока, чтобы выяснить, что происходит, и устранить основную причину. - person Gary Russell; 24.06.2015