On 18/11/2007, Roman Kalukiewicz <[EMAIL PROTECTED]> wrote: > > However, I've found out that the Aggregator might help me out of this. It > > has a time window. It needn't Spring's support, which makes it more doable > > for us. > > Just be warnined that aggregator and its timeout are not > message-based. I mean that aggregator timeouts purely on time basis > (1st, 2nd, 3rd second after context starts - not 1st, 2nd, 3rd second > after first message arrives). > That mean that you cannot predict how long this timeout will be for > given message - it depends on the time this message arrives.
Agreed. We might wanna support a persistent (JPA) Aggregator as an alternative to using the batch approach. The batch approach works great when using JMS transactions where you want high performance without using a database; though it does require on aggregation within batches which is not always possible. So you might wanna process each message one by one, using a database to keep track of the state (which in general is a better approach as it will work with any kind of message stream). There's an outstanding JIRA if anyone fancies trying to write a little JPA based Aggregator... http://issues.apache.org/activemq/browse/CAMEL-217 We've already got a JPA based Idempotent Consumer; a JPA based aggregator is kinda similar; apart from it'll be storing some blob of data for each message processed etc. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
