I'll start with the bad news. From what you've written, it could be either product (Camel or ActiveMQ) that's causing the problem, and the people that support the two products are both likely to initially assume it's the other product's doing. So one of the best things you can do is to figure out which product the problem is occurring in, so you can get the right people involved in troubleshooting what's going on.
To that end, one thing you could do is try cycling the ActiveMQ Broker and seeing whether the problem continues. Then wait for the problem to happen again, and cycle the Camel producer and see whether the problem continues. If cycling one product stops the problem from happening for a while and cycling the other has no effect, then the problem is almost certainly in the one that's fixed by cycling. If the behavior is the same no matter which you cycle, then you'll have to look for another way to determine where the problem lies. I'd also suggest turning on TRACE logging in both products to see if you can see a log dump of each message that's sent by Camel and received by the broker. If you can find a log line that's close to the sending of the message, and it shows that the message is correct at the time it crosses the wire to the broker, then the problem is likely in ActiveMQ; if it's already incorrect by the time it goes across the wire, then it's likely a Camel problem. Can you reproduce this problem reliably (even if it takes a few hours)? Or was this a one-time fluke that you've never seen happen again? Tim P.S. I also notice that the expiration is 0 in the message that's not right, whereas it's got a non-zero value for the correct message. On Thu, Mar 8, 2018 at 9:11 PM, Rajesh Malla <mallara...@gmail.com> wrote: > > we are using activemq : 5.12.3 > apache camel : 2.16.2 > > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html >
