ActiveMQ Ожидающие сообщения - PullRequest
0 голосов
/ 07 января 2019

У меня проблема с ActiveMQ, похожая на эту: http://activemq.2283324.n4.nabble.com/Messages-stuck-in-pending-td4617979.html и уже попробовал решение, выложенное здесь.

Некоторые сообщения, похоже, застряли в очереди и могут оставаться там буквально несколько дней без потребления. У меня более чем достаточно потребителей, которые свободны большую часть времени, поэтому проблема не в «насыщении» потребителей.

При перезапуске ActiveMQ НЕКОТОРЫЕ ожидающие сообщения расходуются сразу. Буквально минуту назад у меня была ситуация, когда у меня было 25 свободных потребителей, доступных для очереди (они видны в панели администратора) с 7 из этих «застрявших» сообщений. Четыре из них были уничтожены сразу, а остальные 3 все еще застряли. Еще одна странная вещь - новые сообщения продолжали поступать в очередь и сразу же были уничтожены, а 3 старых все еще застряли.

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

<jms:listener-container concurrency="${activemq.concurrent.consumers}" prefetch="1">
    <jms:listener destination="queue.request" response-destination="queue.response" ref="requestConsumer" method="onRequest"/>
</jms:listener-container>

<bean id="prefetchPolicy" class="org.apache.activemq.ActiveMQPrefetchPolicy">
        <property name="queuePrefetch" value="1" />
</bean>

<bean id="connectionFactory" class="org.apache.activemq.spring.ActiveMQConnectionFactory">
    <property name="brokerURL" value="${activemq.broker.url}?initialReconnectDelay=100&amp;maxReconnectDelay=10000&amp;startupMaxReconnectAttempts=3"/>
    <property name="prefetchPolicy" ref="prefetchPolicy"/>
</bean>

1 Ответ

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

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

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

...