camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Aggregator strategies (again)
Date Mon, 05 Nov 2007 13:55:45 GMT
Hi Alberto!

On 05/11/2007, almilo <> wrote:
> Hi all:
> First, Camel is a very interesting project. Congrats to the team!!

Many thanks! :)

> Now the question...
> I´ve seen a post about better support for Aggregator pattern but with no
> answer. The testcases seem to be very simple and I think this is a really
> relevant pattern for distributed processing. But, being based in "a priori"
> batch size and timeout it lacks value for most of the uses I can think of.

Yeah! That design BTW was done purely to work nicely with JMS
transactions. There are other designs and use cases in the Aggregator
space though! :)

> Any plans for an Aggregator face-lift? :)

We love contributions! :)

> I attach an imaginative testcase :O) with some comments on FIXMEs

I wonder if we could create a StreamAggregator that works kinda like
the StreamResequencer that Martin Krasser contributed; where rather
than using a batch size, the aggregator could use some counters on the
message to know how many messages to consume before completing the
aggregation window?

Another approach is to persist the message state to a database to
store the previous state then using some kind of predicate to
determine when the aggregation has been completed so that it can be

e.g. if you want to split an Invoice message into LineItems then later
on aggregate it; you might want to store the LineItems in some
persistent table somewhere and only send the aggregated Invoice
message when all the LineItems have been received. This is a little
like the BAM stuff...


Open Source SOA

View raw message