I have reason to believe that on rare occasions a non-persistent message sent to a queue is lost and does not end up in the destination queue.  I am using ActiveMQ 5.4.2 and connect via failover transport over ssl to a single broker and I have the loggingBrokerPlugin enabled.  This error occurs in a highly active production environment and I haven't been able to reproduce the issue with any sort of unit test.

After the producer sends the non-persistent message (default is asynchronously), I print the JMS MsgId to a log file.  When an expected response message is not consumed by the client, I then check the activemq.log files for the loggingBrokerPlugin log entries matching that msgId but do not find any log entry matching the corresponding msgId.  However, messages sent before and after this message are found in the log files.

I also registered a failover transport listener on the consumer and producer that logs any transport changes to a log file, and the transport does not seem to experience any failure when the message is lost.  In addition, I have registered for all Advisory messages and am logging all messages as well.   I do see an occasion a SlowConsumer advisory, but No ActiveMQ.Advisory.FULL advisories are received, so I assume flow control logic is not being triggered.

My main question is under what circumstances can sending an asynchronous message to a queue fail after the producer.send() call returns, and is there a way to detect the failure via logging?  I was under the impression that asynchronous sends are only unreliable in the case of system, software or network failure, and that does not seem to be the case in my production environment.

Also, to test my theory about the non-persistent reliability issue, I would like to try sending all non-persistent messages synchronously, but can't seem to find an obvious way to do that besides setting the Delivery type to persistent which is not desirable for my application.  Am I missing something?

Thanks,

Rob