Hi Flo, I actually haven't tried the Aggregator use case. I believe your assumption is correct though that the transaction would be closed. The assumption is that transacted behavior must always be synchronous and the aggregator kind of blurs those lines.
This may be the case where a property driven que to the synchronizer would make better sense. The second use case could also be an issue if the messages are intermittent. I can take a look at having the timer reset the appearance of an exchange in the consumer vs. resetting the timer in the Synchronizer. Of course if you have some unit tests available to prove any of this, contributions are always welcome. :) Thanks for the input, Scott Es On Thu, Oct 10, 2013 at 8:16 AM, flovansi <florent.vansilie...@swift.com>wrote: > Hi, > > I’m interested in the feature “Batch Consumer” offered by SJMS. > > By looking at the code, I noticed that the commit of the JMS session is > done > in the completion of the last exchange of the batch > > (/org.apache.camel.component.sjms.tx.SessionBatchTransactionSynchronization.java/) > > Does SJMS Consumer support a route with the Aggregation Pattern? > > I’ll explain you my concern: > > When an exchange comes into an aggregate, a copy of this exchange is done > and the original exchange continues its processing. When the processing of > the original exchange is finished, its completion will be executed. > So with the SJMS component, the completion of the last exchange of the > batch > might occurs before the aggregated message finishes its processing. So even > if the aggregated exchange fails, the JMS session is already committed and > messages are lost. > > Is it right? Or does the thread executes first the processing inside > aggregate before executing the processing of the last exchange? > > Another question is about the timeout that’ll trigger the commit of the JMS > session. > It seems that when the timeout occurs, it tries to commit the session > directly > > (/org.apache.camel.component.sjms.tx.SessionBatchTransactionSynchronization.java > – line 136/), no matter if the exchange is still inflight. > > What happens if the exchange is still inflight and an exception occurs > after > the JMS session is committed (due to the timeout)? > > I hope someone can clarify these concerns with me :). > > Thank you, > > Flo > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/SJMS-implementation-Batch-Consumer-tp5741291.html > Sent from the Camel Development mailing list archive at Nabble.com. > -- -- Scott England-Sullivan Apache Camel Committer Principal Consultant / Sr. Architect | Red Hat, Inc. FuseSource is now part of Red Hat Web: fusesource.com <http://www.fusesource.com> | redhat.com<http://www.redhat.com> Blog: sully6768.blogspot.com Twitter: sully6768
