Потребление сообщений зависло от activemq с использованием компонента camel jms

У меня есть приложение с двумя верблюжьими маршрутами:

Маршрут 1 (Потребительский маршрут)

Читает текстовый файл без номера. записей (разделенных строками), разделяет их на основе каждой строки и отправляет каждую разделенную запись в другую очередь («промежуточная» очередь)

Маршрут 2 (Маршрут продюсера)

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

Я использую ActiveMQ с camel JmsComponent (concurrentConsumers=7, maxConcurrentConsumers=10). Я предполагаю, что верблюд использует Spring DMLC внизу для чтения из очереди.

Конфигурации:

activemq.broker.uri = tcp://0.0.0.0:61616?jms.useAsyncSend=true&jms.prefetchPolicy.queuePrefetch=1

<bean id="cachingConnectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory">
    <property name="targetConnectionFactory" ref="jmsmqConnectionFactory" />
    <property name="reconnectOnException" value="true" />
    <property name="sessionCacheSize" value="7" />
</bean>

<bean id="jmsComponent" class="org.apache.camel.component.jms.JmsComponent">
    <property name="connectionFactory" ref="cachingConnectionFactory" />
    <property name="cacheLevelName" value="CACHE_CONSUMER" />
    <property name="transacted" value="true" />
    <property name="transactionManager" ref="transactionManager" />
</bean>

jmsComponent:queue:INTERMEDIATE?concurrentConsumers=7&maxConcurrentConsumers=10

Теперь проблема в том, что если нет. записей в файле очень мало (10 или меньше), разделенные записи застревают в промежуточной очереди. Маршрут к источнику работает, но сообщения не принимаются. Никаких исключений не обнаружено ни в одном из журналов, и Consumer Route также работает.

Однако, если установить prefetch limit равным 0, эта проблема исчезнет, ​​но приведет к другой проблеме - маршруты верблюдов не могут быть принудительно остановлены ctrl+C с cacheLevel как CACHE_CONSUMER. Хотя CACHE_AUTO работает нормально, производительность падает.

Есть ли какая-нибудь известная проблема с prefetch > 0 и SpringDMLC, или мне что-то не хватает?


person KChakraborty    schedule 22.06.2016    source источник
comment
хм, я не могу отметить никаких известных проблем с предварительной выборкой больше нуля. Однако помните, что предварительная выборка извлекает записи из ActiveMQ до того, как вам потребуется их обработать. По умолчанию, когда верблюд получает остановку, он сначала пытается завершить обработку записей. Если компонент, который вы используете, завершает работу, пока вы пытаетесь завершить обработку, вы можете попасть в тупик. Вы смотрели на JMX, чтобы узнать, остались ли сообщения, застрявшие во время полета?   -  person Matthew Fontana    schedule 22.06.2016


Ответы (1)


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

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

person Paweł Motyl    schedule 27.02.2018