I’m still going through the project, but the first couple of things that jump out at me are you have two Spring versions - the one you explicitly put in your POM (3.2.8.RELEASE) and the one pulled in by camel-spring (3.2.11.RELEASE). Also, camel-spring should be included in the POM since you’re using Spring routes. I’m not sure if that’s enough to cause issues or not.
I believe what’s going on with the “no-tx” version is you’re actually using JMS transactions since you still have transacted set to true in the JmsConfiguration. I’m not sure what’s going in with the “standard” version - it looks similar to some XA stuff I’ve setup before (because I had multiple brokers involved) except I had to use XA Connection Factories. > On Feb 3, 2016, at 3:12 PM, Stephan Burkard <sburk...@gmail.com> wrote: > > Yes, same broker. There is only one ActiveMQ connection config in the > project. > > > > On Wed, Feb 3, 2016 at 8:00 PM, Quinn Stevenson <qu...@pronoia-solutions.com >> wrote: > >> Are both the source and destination queues hosted by the same ActiveMQ >> broker? >> >> >> >>> On Feb 3, 2016, at 8:21 AM, Stephan Burkard <sburk...@gmail.com> wrote: >>> >>> Hi >>> >>> I have built a small Maven project (attached) to demonstrate a JMS >> transaction problem in Camel routes under certain load conditions. In fact >> I am losing messages between two queues. >>> >>> The project contains two different flavours of the same test. One of >> them suffers from the problem, the other (due to my tests) not. >>> >>> >>> *** What does the testcase? >>> 1. Produces 1000 messages (100/s) and sends them to an "input" queue. >>> 2. Sends the messages from the "input" queue to an "output" queue. >>> 3. Finally consumes the messages from the "output" queue to count them. >>> >>> >>> *** What is the difference between the two test flavours? >>> - There is a "standard" flavour that suffers from the problem >>> - And there is a "noTxManager" flavour that seems to not have the problem >>> - The "standard" flavour is kind of a well known Camel/ActiveMQ >> configuration >>> - with a Spring transaction manager >>> - with a Spring transaction policy >>> - With a "transacted" flag in Camel routes >>> - The "noTxManager" flavour is a "simple" configuration >>> - no Spring transaction manager >>> - no Spring transaction policy >>> - no "transacted" flag in Camel routes >>> - BUT: "lazyCreateTransactionManager" = false (so routes are >> transacted too) >>> >>> >>> *** How to run the testcases? >>> 1. Replace "[yourBrokerHost]" with the hostname of your ActiveMQ broker >>> 2. Run the testcase as JUnit test >>> 3. When you see lots of console messages that messages are sent, stop >> your ActiveMQ broker (do not kill-9 it, just shut it down normally) >>> 4. Exceptions are thrown on the console output >>> 5. After some seconds start your broker again >>> 6. The test finish normally and after some seconds dumps a book keeping >> on the console >>> >>> >>> *** How to interpret the results? >>> - When the test is successful, no message is lost. You can run the test >> without broker shutdown/startup and it will obviously always be successful. >>> - When the test fails, one or more messages are lost between queue >> "input" and "output". In my tests I was not able to run the "standard" >> flavour three times in a row successfully. About every second run failed. >> In contrast, the "noTxManager" flavour never failed in my tests. >>> >>> The book keeping for a failed test looks like the following. In this >> example Message number 281 is arrived at the input queue but not at the >> output queue. So it is lost. >>> >>> Messages created by Client: 1000 >>> Client Exceptions during send: 0 [] >>> >>> Messages received at input queue: 993 >>> Missing Messages at input queue: 7 [282,283,284,285,286,287,288] >>> Duplicate Messages at input queue: 0 [] >>> >>> Messages received at output queue: 992 >>> Missing Messages at output queue: 8 [281,282,283,284,285,286,287,288] >>> Duplicate Messages at output queue: 0 [] >>> >>> Lost Messages between Queues: 1 [281] >>> >>> >>> *** What is the problem? >>> A Redhat engineer tracked the problem down to a Spring JMS template >> behaviour that is kind of strange. If a Spring transaction manager is >> defined in the config, it will end up with two of them. Therefore the small >> time range where messages can get lost that arises only when you have a >> certain load. >>> >>> >>> *** So, what is my question? >>> - Does this really mean that it is unsafe to use the "standard" flavour >> of configuration? >>> - Is there another config with TxManager etc that works correctly? >>> - What are limits of the "noTxManager" config? When is it not sufficent? >>> >>> Regards >>> Stephan >>> >>> >>> >>> >>> <CamelAmqTxTest.zip> >> >>
