On Fri, Dec 7, 2012 at 9:07 AM, Charles Moulliard <ch0...@gmail.com> wrote: > Hi Christian, > > What you suggest is really interesting and could be added to the existing > aggregator if we add some properties and global cache to inform the > aggregator that it will receive exchanges from different input. But the > question is "Is it still the role of the aggregator of doing that instead > of placing the messages aggregated in a (persisted) cache and consume them > from a separate component to verify if completion has been done globaly ?". > Which info are we gonna to provide to the camel routes if we have received > a part of the exchanges and not all ? This is an interesting business use > case but we should perhaps address it in a different way to avoid too much > complexity .... in our camel routes. >
No its way to complicated. The ideas and success of the EIPs is that they are very compose able, and you can build solutions like "lego bricks". The idea has never been that there is one giant EIP for every business problem out there. Instead you use the "lego bricks" to build your solution. > Just 2€ cents for the debate ;-) > > Regards, > > Charles > > > On Thu, Dec 6, 2012 at 11:56 PM, Christian Müller < > christian.muel...@gmail.com> wrote: > >> It would be great to improve the Aggregator to support a completion size >> which evaluates ALL exchanges (from all different aggregates). >> We ofter have the requirement to split a file which contains items which we >> process independently. At the end, we have to aggregate the items based on >> the customer. >> >> As an example, we have one input file with 1000 items which will result in >> 2 output files with 300 and 700 items (or 3 output files with 273, 493, 234 >> items - or 4 output files with ... I think you got it). At the end, the >> aggregator will receive in total 1000 files which should be trigger a flush >> on ALL existing aggregates. >> >> What do you think? >> Is there already a simple solution for this which I miss? >> >> At present we use a combination of two aggregators to do this. Each will >> receive a copy of an item. The second aggregator only counts the total >> number of all received exchanges (we are using the same aggragation key >> value for this aggregator). If this aggragor flushes the exchange, we send >> a "command message" to the first aggregator to flush all the aggregates. >> >> I think there should be a simpler solution out of the box which Camel >> should offer. E.g. completionRepositorySize or repositoryCompletionSize >> >> Best, >> Christian >> > > > > -- > Charles Moulliard > Apache Committer / Sr. Enterprise Architect (RedHat) > Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
