Camel transacted JMS component doesn't work with Aggregator

506 views Asked by At

I discovered that JMS component with option transacted=true doesn't work well with Aggregator. My route is transactional until it reach the Aggregator, after Aggregator my route is not anymore transactional. If I understood well, this is because Aggregator is starting new threads for every exchange transition, and this behaviour stops the first transactional thread, which leads to transaction commit and ack send to queue. So messages are not anymore in the queue. Is this correct?

What I need to do with Camel is to read all messages from a queue (RabbitMQ), then to transform them all in one List, and at the end to write data from a List into the File. All of this has to be transactional, if some error happens in the route, messages should remain in the queue. Basically what i did so far is reading from queue with jms component (with option transacted=true), then aggregate all the messages with aggregator, and after that send to file.

Shortened example of my code:

from("jms:queue:someQUeue?transacted=true")
    // some more processing in the route                          <- route is transactional here
    .aggregate((constant(true)), new MyAggregationStrategy())
    .completionInterval(500)
    .process(new Processor() {                                    <- route is not transactional anymore
               // some processing
    })
    .toD("file://C/tmp...")

I think that perfect component for this would be Simple JMS-batch, but we are using Camel 3.8 and this component doesn't exist anymore in this and newer versions. Why? Is there something new instead of this?

Also SJMS and SJMS2 don't help me, when I use them, consumer indeeed reads all the messages (all messages in queue are unacked - waiting to be acked), but the processing through the route is still one by one message. How can I make this to be one exchange with list of all messages?

Is there maybe some other solution? (For example to make some custom Aggregator - but how?)

1

There are 1 answers

1
Fábio Carmo Santos On

As far as I know, that's correct! If your intention is to achieve guaranteed-delivery, in this case, you'd better use a persistent aggregation repository.