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.
