Hi Claus That's very interesting because I observed the opposite. Some months ago I did ActiveMQ master/slave failover tests with a simple Camel JMS application that has the full Spring tx configuration and transacted Camel route. All was fine when I sent some messages per second. But when I sent 100 messages per second I was losing messages during the failover.
A Redhat engineer tracked this down to a problem of Spring JMS template that is used under the hood. When I remember it correctly, Spring JMS template creates a second txManager although there is one configured. Because of the two txManagers, there is a small time slice where messages can get lost and this only happens when loads of messages are sent. The Redhat engineer then recommended me to use the much simpler configuration with lazyCreateTransactionManager=false and to my big surprise (I would have bet that this does not work), no more messages got lost. Since then I am a bit unconfident how to configure the transaction stuff in my Camel applications. There was a Redhat ticket for this case but I don't know the number since I am not in the office. Best regards Stephan On Fri, Sep 25, 2015 at 5:57 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > If you just set transacted=true on a JMS route then the ACK mode is TX > and hence the message is not lost in case of an exception during > routing, as the ACK is deferred until the end. > > But if you want to both consume and send to JMS queues in the same TX, > you need all that glory TX setup. And also if you want to use other > resources such as JDBC. > > > > On Fri, Sep 25, 2015 at 5:47 PM, Stephan Burkard <sburk...@gmail.com> > wrote: > > Hi > > > > Since my question below was never answered, I have attached a small > example > > project that contains the 2 showcases. > > > > > > The first case is the well-known Camel-ActiveMQ configuration: > > - An ActiveMQ connection configuration with Spring jmsTransactionManager > and > > SpringTransactionPolicy > > - A Camel-Route with "transacted" Flag > > - A Testclass that runs a happy message without error and an unlucky > message > > where an error is injected > > > > As expected both cases are successful, we don't lose any messages. > > > > > > The second case is different: > > - An ActiveMQ connection configuration WITHOUT Spring > jmsTransactionManager > > and SpringTransactionPolicy > > - Instead the Camel ActiveMQ component is configured as transacted and > with > > <property name="lazyCreateTransactionManager" value="false"/> (see > > CAMEL-5055) > > - A Camel-Route WITHOUT "transacted" Flag > > - A Testclass that runs a happy message without error and an unlucky > message > > where an error is injected > > > > Surprisingly both cases are successful, we don't lose any messages. I > guess > > because the "lazyCreateTransactionManager" config creates a local JMS > > transaction. > > > > > > Are there technical differences between the two configurations? Are there > > consequences/downsides on using the second approach? For example when > other > > Camel components are used in the route? > > I see for example the DefaultErrorHandler of Camel kicks in in the second > > case while the TransactionErrorHandler is used in the first case. > > > > Thanks > > Stephan > > > > > > > > > > On Mon, Feb 23, 2015 at 3:01 PM, Stephan Burkard <sburk...@gmail.com> > wrote: > >> > >> Hi > >> > >> So far I always configured the Camel ActiveMQ component with a Spring > >> JmsTransactionManager etc and marked my routes explicit as "transacted" > >> since we must not lose any messages. This kind of configuration can be > found > >> at various places, for example the Camel docs at > >> http://camel.apache.org/transactional-client.html. > >> > >> However, we recently ran into a strange test case where we lost > messages. > >> We first suspected it to be an ActiveMQ problem that can arise during a > >> failover (because that was the test case), but Redhat support tracked it > >> down to an "interesting" behaviour of Spring JMS that arises due to the > >> configured JmsTransactionManager. > >> > >> Therefore I created a simple test case where I removed (as recommended > by > >> Redhat) the whole Spring JmsTransactionManager stuff as well as the > >> "transacted" flag on the Camel route and the route is still fully > >> transacted. The transacted flag on the JmsConfiguration of the Camel > >> ActiveMQ-Component seems to be the only needed piece to achieve this. > >> > >> Therefore my questions: > >> 1. Does the "transacted" flag on the Camel ActiveMQ component make all > >> routes with a JMS consumer [from(activemq:...)] automatically > transacted? > >> > >> 2. Has the reduced configuration (routes without "transacted" element, > no > >> "transactionManager" reference on Camel ActiveMQ component > configuration, no > >> JmsTransactionManager, no SpringTransactionPolicy) any obvious side > effects > >> we have to check and test? > >> > >> Thanks a lot > >> Stephan > >> > > > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2nd edition: > https://www.manning.com/books/camel-in-action-second-edition >
