camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose MarĂ­a Zaragoza <>
Subject Re: JMS Batch consumption
Date Sat, 09 Aug 2014 07:22:55 GMT
2014-08-09 8:42 GMT+02:00 Claus Ibsen <>:
> Hi
> There is camel-sjms component that supports batches.
> But the camel-jms component uses spring JMS and its DMLC which is one
> message at a time, and do not support batches.

A question from a newbie user:

if I wanted to read messages from a queue (amq) and insert them into a
database ( one by one ) ,
and if insertion fails , then the message be acknowledged ( removed
from queue)  and stored into a file

what is the best pattern to use ?

> On Fri, Aug 8, 2014 at 11:37 AM, Arnaud Deprez <> wrote:
>> Hi folks !
>> I'd like to write a camel route that consumes a group of messages from a
>> queue to persist it in a database in a single transaction and of course I
>> can't loose any message.
>> Basically, I was hoping it will work as expected by using a transacted
>> route with an aggregation strategy in memory, then split the aggregation
>> result, do a bit of business process and then store it in the database.
>> But it doesn't work. It seems that every message that goes to the
>> aggregator is commited/acknowledged just after the aggregator. So if
>> something goes wrong, I loose my message :-(.
>> I also read in chapter8's camel book that if we want to use a aggregation
>> strategy in a transactional way, we can use a persistent repository and use
>> one transaction from the queue to the aggregation repository and then
>> another transaction from the transaction repository to the database.
>> But I really don't like this solution. Why should I need another another
>> repository before persist my message in a database ?
>> I also read that the aggregator can be used with a batch consumer
>> But there is none for JMS and
>> I don't know if it will solve this problem.
>> According to me, it seems to be a design issue but I'm not sure and I'd
>> like your point of view about this ? If you have a workaround or another
>> solution that can suit to me, please share ! :-)
>> Arnaud Deprez
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email:
> Twitter: davsclaus
> Blog:
> Author of Camel in Action:
> hawtio:
> fabric8:

View raw message