Многопользовательский ActiveMQ перестает потреблять, когда один потребитель потерпел крах - PullRequest
0 голосов
/ 10 января 2019

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

3 корневых контейнера (ROOT 1, 2 и 3) У каждого корневого контейнера есть 2 дочерних контейнера (один для Active MQ-брокера и другой для верблюжьего контейнера).

ROOT 1 - AMQ 1 & CAMEL 1

ROOT 2 - AMQ 2 & CAMEL 2

ROOT 3 - AMQ 3 & CAMEL 3

AMQ 1,2 и 3 являются частью одной брокерской группы. Это означает, что одновременно активен только один экземпляр AMQ, а другие предназначены для восстановления после отказа.

CAMEL 1,2 и 3 обрабатывают сообщения от AMQ.

Проблема:

Мы обработали 1000 сообщений в AMQ, которые были использованы всеми потребителями, то есть CAMEL 1,2 и 3. Но когда любой из потребителей (CAMEL 1,2 или 3) был убит с помощью kill -9, тогда сообщения, присутствующие в AMQ, застряли и не обрабатываются остальными работающими потребителями.

Проверьте ниже конфигурацию, которую мы имеем в проекте ActiveMQComponent,

<bean class="org.apache.activemq.ActiveMQXAConnectionFactory" id="activeMqXaConnectionFactory">
    <property name="brokerURL" value="discovery:(fabric:test-broker-group)?wireFormat.maxInactivityDuration=30000&amp;jms.prefetchPolicy.queuePrefetch=0&amp;jms.rmIdFromConnectionId=true&amp;alwaysSessionAsync=true"/>
    <property name="trustAllPackages" value="true"/>
    <property name="xaAckMode" value="2"/>
    <property name="useAsyncSend" value="false"/>
    <property name="redeliveryPolicy">
        <bean class="org.apache.activemq.RedeliveryPolicy">
            <property name="maximumRedeliveries" value="5"/>
        </bean>
    </property>
</bean>

<bean class="org.apache.activemq.pool.JcaPooledConnectionFactory" id="jmsXaPoolConnectionFactory" init-method="start" destroy-method="stop">
    <property name="name" value="activemq.default"/>
    <property name="transactionManager" ref="jtaTxManager"/>
    <property name="connectionFactory" ref="activeMqXaConnectionFactory"/>
    <property name="maxConnections" value="50"/>
    <property name="idleTimeout" value="86400000"/>
</bean>
<bean class="org.apache.activemq.jms.pool.GenericResourceManager"
    id="amqresourceManager" init-method="recoverResource">
    <property name="transactionManager" ref="jtaTxManager"/>
    <property name="connectionFactory" ref="activeMqXaConnectionFactory"/>
    <property name="resourceName" value="activemq.default"/>
</bean>
<bean class="org.apache.activemq.camel.component.ActiveMQComponent" id="activemq">
    <property name="configuration">
        <bean class="org.apache.camel.component.jms.JmsConfiguration">
            <property name="connectionFactory" ref="jmsXaPoolConnectionFactory"/>
            <property name="transactionManager" ref="springJtaTxManager"/>
            <property name="transacted" value="false"/>
            <property name="cacheLevelName" value="CACHE_NONE"/>
            <property name="concurrentConsumers" value="5"/>
            <property name="acknowledgementModeName" value="CLIENT_ACKNOWLEDGE"/>
        </bean>
    </property>
</bean>
<service interface="org.apache.camel.Component" ref="activemq"/>

Примечание: не использовать темы. только очереди

Мы также попробовали AUTO_ACKNOWLEDGE. Но все равно ведут себя так же.

Ожидается - должен обрабатывать сообщения, даже если кто-то из потребителей был убит. Факт. AMQ-сообщения помещаются в очередь.

1 Ответ

0 голосов
/ 11 января 2019

Это странно. Сначала я подумал о размерах предварительной выборки, но вы уже установили их на ноль. Я бы предложил снова пройтись по сценарию. Когда описанная ситуация наступает

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

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

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