2014-10-18 1 views
0

У меня есть сценарий, в котором я получаю входное сообщение. Сообщение A. Затем сообщение A должно быть разделено на 3 разных типа сообщений и перенаправлено на другие маршруты. Важно, чтобы сообщения поступали в точном порядке, т.е. A-1 должен быть отправлен до A-2, который должен быть отправлен до A-3.Подсветка многоадресной рассылки Camel не работает

Для этого я сделал следующее (контур):

from("activemq:queue:somequeue-local") 
    .multicast().to("direct:a1","direct:a2","direct:a3"); 

from("direct:a1) 
    //split incoming message and prepare output document for A-1 
    .to("activemq:queue:otherqueue") 

.from("direct:a2) 
    //split incoming message and prepare output document for A-2 
    .to("activemq:queue:otherqueue") 

.from("direct:a3) 
    //split incoming message and prepare output document for A-3 
    .to("activemq:queue:otherqueue") 

И в другом контексте, ответственность за рассылку информации к внешней системе, у меня есть

.from("activemq:queue:otherqueue?maxMessagesPerTask=1&concurrentConsumers=1&maxConcurrentConsumers=1") 
     // do different stuff based on which type we are called with then end with 
    .beanref("somebean","writeToFileAndCallImportbat"); 

Теперь, моя проблема в том, что когда я добираюсь до получателя, я получаю сообщения в случайном порядке. Иногда A-1, A-3, A-2, иногда справа, A-1, A-2, A-3.

Я попытался добавить JMSXGroupID и JMSXGroupSeq к сообщениям, но не повезло.

Я также пробовал полностью пропустить часть MQ и использовать direct-vm: для вызова общего приемника, но потом похоже, что у меня есть три одновременных вызова приемника одновременно и все еще в произвольном порядке выполнения.

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

Есть ли что-то принципиально неправильное с принятым подходом?

Я использую Верблюд версии 2.12.

Или, более ясно сказал:

  • Я хотел маршрут, который создает три выходных сообщений, и выполняет командный файл на них, в порядке. Как мне это сделать?

ответ

0

Если вы используете Splitter pattern, вы проверили, чтобы увидеть, если потоковое свойство имеет значение ложь.

Если включено, Camel будет разделяться потоковым способом, что означает, что он будет разбивать входное сообщение на куски. Это уменьшает издержки памяти. Например, если вы разделяете большие сообщения, рекомендуется использовать для потоковой передачи. Если потоковая передача включена, ответы суб-сообщения будут агрегированы не по порядку, например, в том порядке, в котором они возвращаются. Если он отключен, Camel будет обрабатывать ответы под-сообщения в том же порядке, в каком они были разделены.

+0

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

0

Итак, оказалось, что проблема не связана с многоадресной рассылкой.

Скорее всего, в каждом из моих суб-маршрутов, я это сделал:

.split(..stax(SpecialClass)).streaming() 
.beanRef("transformationBean","somefunction") 
.aggregate(constant("1"), new MyAggregator()) 
.completionTimeout(5000) 
.completionSize(1000) 
.to(writeToFileAndRunBat) 

Который, я предполагал, означало «Процесс все элементы в расколе, и если вы еще не закончены в течение 5 секунд или после того, как 1000 элементов ".

Я изменил его

.split(..stax(SpecialClass), , new MyAggregator()).streaming() 
.beanRef("transformationBean","somefunction") 
.end() 
.to(writeToFileAndRunBat) 

Coming думать об этом, это имеет смысл, так как первая версия не мог знать, когда мы были сделаны, в то время как в прошлом (я предполагаю) просто перебрать все элементы в расколе и называет агрегатор для каждого.

Кроме того, мне пришлось использовать .end() в первой версии. Поэтому я думаю, что все это было просто случайным.