Hi Alberto! On 05/11/2007, almilo <[EMAIL PROTECTED]> 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! :) http://activemq.apache.org/camel/contributing.html > 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 sent. 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... http://activemq.apache.org/camel/bam.html -- James ------- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com
