camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From almilo <alberto.mija...@fundacionctic.org>
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
DelegateProcessor?

Tahnks a lot, Alberto.

-- 
View this message in context: http://www.nabble.com/Aggregator-strategies-%28again%29-tf4750834s22882.html#a13589059
Sent from the Camel - Users mailing list archive at Nabble.com.


Mime
View raw message