I did some tests but still can't find correct solution... While aggregator/resequencer are asynchronous, configuring transactions didn't help - transaction is commited after invoking process() but messages are processed later, after batchTimeout. So I tried to change resequencer to process synchronously but there is a problem with concurrent consuming on transacted JMS component - multiple concurrent consumers cause high CPU usage and still some messages are queued before aggregating. Any further ideas?
Piotr RomKal wrote: > > 2008/4/11, Piotr Jagielski <[EMAIL PROTECTED]>: >> I've found an issue reported already : >> https://issues.apache.org/activemq/browse/CAMEL-217 >> >> What do you think of blocking an exchange by aggregator processor as in >> delayer processor? >> Processing could be continued after aggregating > > So this way we don't commit transactions associated with messages > unless they are aggregated? > > I'm not really sure if it could work, but there are people who have > better experience here.Maybe we could store AsyncCallbacks in > aggregator and asynchronously finish transactions when aggregator > finishes aggregation. > > The only problem here is that many our endpoints doesn't support > asynchronous invocations, so it would anyway block threads (JMS > Consumers), I believe. > > BTW Maybe aggregator should have such a flag that requires waiting at > aggregator unless things get aggregated? > > Roman > > -- View this message in context: http://www.nabble.com/Aggregator-resequencer-reliability-tp16617652s22882p16677428.html Sent from the Camel - Users mailing list archive at Nabble.com.
