camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From almilo <>
Subject Re: Aggregator strategies (again)
Date Mon, 05 Nov 2007 15:39:29 GMT

James.Strachan wrote:
>> I wonder if the simplest way to implement the described split and
>> aggregate pattern could be to just combine the splitter and aggregator
>> into 1 delegate processor.  For example it would take it's input,
>> split it and forward each part to the delegate for processing.  Then
>> it would wait for the result of processing and aggregate those
>> results.  The delegate processor would know how many things it split
>> up so it would know how many things to aggregate.
> Thats a great idea for a nice simple solution that solves many
> problems :) Increasingly it might help if we can try to roll up
> smaller patterns into larger patterns (or protocols?) so combining a
> splitter and aggregator together into a single unit might help
> simplify things for folks (and make it easier to avoid making
> mistakes).
> I guess the downside of this approach is that only one large message
> can be processed at once. For example using Invoices and LineItems as
> an example; if you had a pool of processors, you could only let folks
> process one Invoice at once (as the thread would block before sending
> any other invoice's LineItems to be processed) but that might avoid
> complications.

Not sure if I got it but seems simpler and higher level (more like patterns
:). Could anybody point me to an example, similar testcase or so with a

Tahnks a lot, Alberto.

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message