Сценарий потери сообщений интеграции Spring - PullRequest
0 голосов
/ 15 ноября 2018

Сводка - Потеря сообщений во время систематического завершения работы приложения.

У меня есть приложение, написанное в весенней интеграции, и я принимаю запросы от внешних систем, использующих 'jms: message-driven-channel-adapter'.Это конфигурация адаптера канала -

<jms:message-driven-channel-adapter id="InboundAdapter" destination="InQueue"
                                        connection-factory="connectionFactory"
                                        channel="responseChannel"
                                        error-channel="errorChannel"
                                        acknowledge="transacted"
                                        receive-timeout="50000"
                                        auto-startup="true"/>

мой канал ответа выглядит следующим образом -

 <int:chain id="processorChain" input-channel="responseChannel">
        <int:service-activator method="doProcess" ref="inputProcessor" />

        <int:router id="inputRouter" method="route">
            <int:mapping value="REQUIRED" channel="builderChannel"/>
            <int:mapping value="NOT_REQUIRED" channel="TerminateChannel"/>
            <bean id="Router" class="xxx.xxx.Router">
            </bean>
        </int:router>
    </int:chain>

Теперь, когда я выполняю команду kill -9 pid, я вижу, чтосообщение откатывается в очередь и все хорошо.Но когда я выполняю команду kill pid, сообщение где-то теряется.Я включил журналы jms и вижу, что JMS-прослушиватель ожидает завершения транзитного сообщения перед закрытием JMS-потребителя, но все равно не возвращает сообщение обратно в мою очередь.Это фрагмент журнала, который я вижу в своих журналах

trace: 15.11.18 15: 42: 46.619 [Thread-10] DEBUG org.springframework.jms.listener.DefaultMessageListenerContainer - Ожидание завершения работы вызывающих прослушивателей сообщенийtrace: 15.11.18 15: 42: 46.619 [Thread-10] DEBUG org.springframework.jms.listener.DefaultMessageListenerContainer - все еще ожидает отключения 1 вызывающих прослушивателей сообщений (итерация 0)

После этого регистрируетсявызывает активаторы службы, которые определены в канале ответа.

Может кто-нибудь пролить свет на вышеуказанное поведение, я ожидал, что когда мы выдаем команду kill, все сообщения, находящиеся в процессе передачи, должны быть откачены довместо этого она пытается вызвать активаторы, определенные в канале, и после вызова последнего компонента, который является маршрутизатором, она просто завершается.

Любая помощь по этой теме будет действительно полезна !!


После некоторой дополнительной отладки и стука моей головы с системой, которую я нашелточный сценарий, где это происходит.Позвольте мне рассказать об этом, чтобы понять, имеет ли это смысл.Когда происходит систематическое завершение работы, JMS ожидает окончания передачи сообщений, прежде чем остановить приложение, пока все не будет исправно.В настоящее время эта цепочка выполняется -

<int:chain input-channel="inputchain">
    <int:transformer id="xxx" method="transform">
        <bean class="xxx" />
    </int:transformer>

    <int:service-activator  id="xxx" method="doProcess">
        <bean class="xx">
            <constructor-arg ref="xxx"/>
        </bean>
    </int:service-activator>

    <int:service-activator id="xxx" ref="rulesProcessor" method="doProcess"/>
    <int:service-activator id="xxx" ref="xxx" method="doProcess"/>

    <!-- Existing Flow Continues -->
    <int:router id="xxxRequiredRouter" method="xxxRequired">
        <int:mapping value="Required" channel="firstChannel"/>
        <int:mapping value="NotRequired" channel="secondChannel"/>
        <bean id="xxxRouter" class="xxx.Router" />
        </bean>
    </int:router>

</int:chain>

<int:chain input-channel="secondChannel">

   some logic

</int:chain>

Таким образом, поток завершает эту цепочку и завершает работу корректно.Моя следующая цепочка не называется «secondChannel».Моя граница транзакции не заканчивается в этой цепочке 'inputchain', она заканчивается в конце secondChannel.Таким образом, я не отправил этот переход в базу данных, поскольку граница транзакции находится в конце следующей цепочки, поэтому он недоступен в БД, и приложение думает, что выполнение цепочки завершено, поэтому оно завершено, поэтому оно не откатывается в очередьтакже.Так что, в конце концов, у меня нет этого сообщения в моей базе данных, и его нет в очереди.

Значит ли это так, что завершится только цепочка, которая выполняется, когда было запущено отключение, и она не будет делегировать обработку последующим цепочкам?

1 Ответ

0 голосов
/ 15 ноября 2018

SIGTERM kill будет ожидать завершения работы потока.

В конце концов контейнер прервет его, но это поможет, только если он делает что-то, что может прерваться.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...