Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-user@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of james.strachan@gmail.com
 designates 209.85.132.246 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=WGT54OtcGGUEJ3YHyIazT5QA/8vN4eWsTfyNqZOrzQaP0FzWYT5uvT/cHr/LevZpTeU8IDmnHYxOHoLthd/TVRaOgLU2mPqztmNtTielpeCK58kmqxw3eoKouMrC5tnzwKVTeXD/clwU54OHFF3gVAUfrLwV0JB7AUocDqyWSak=
Message-ID: <ec6e67fd0711050555i34d815baiffdd32f2927a67eb@mail.gmail.com>
Date: Mon, 5 Nov 2007 13:55:45 +0000
From: "James Strachan" <james.strachan@gmail.com>
To: camel-user@activemq.apache.org
Subject: Re: Aggregator strategies (again)
In-Reply-To: <13584751.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <13584751.post@talk.nabble.com>

Hi Alberto!

On 05/11/2007, almilo <alberto.mijares@fundacionctic.org> wrote:
> Hi all:
>
> First, Camel is a very interesting project. Congrats to the team!!

Many thanks! :)


> Now the question...
>
> I=B4ve seen a post about better support for Aggregator pattern but with n=
o
> 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 prior=
i"
> 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

--=20
James
-------
http://macstrac.blogspot.com/

Open Source SOA
http://open.iona.com