There should be no message loss in what you describe.
to try with synchronous sending use the following url parameter on the client broker url:
Okay, I have tested using jms.alwaysSyncSend=true in the connection URL in production environments for several clients and for several months and this small tweak has seemed to fixed the lost message problem.
Since setting this flag is not as efficient, I am trying to determine if this is a potential bug with ActiveMQ, or in our code, e.g. Sharing a MessgeProducer with multi-threads, etc.
Any thoughts as to why setting jms.alwaysSyncSend=true fixed the issue?
Hmm, with multiple threads using a producer (which is not typical) there is the possibility of a message with a higher sequence id being processed first by the broker.
With alwaysSyncSend, there will be serialized sending so there is no possibility of overlap of producer sequence ids.
I know both KahaDB and JDBC had message order issues with overlapping transactions that have been resolve in the past few months. Multiple threads sharing a producer may be able to reproduce a similar scenario from the store perspective.
I would be good to see if you can reproduce with a current 5.6-SNAPSHOT or the most recent 5.5.0-fuse-00-53
I am facing the same issue. I tried :
The message is lost after 6 attempts. It does not go to DLQ. DLQ is not even created.
Hi I am facing similar issue with Fuse ESB 1.7.0 (activemq 5.7.0)
See the details here
Did you get any further with your analysis?
Why is alwaysSyncSend flag considered as inefficient?