For keep-alive packets, I was referring to the inactivity monitor and not TCP keep-alive packets.
The documentation is correct - the default is not to enable TCP keep-alive packets on the socket. I don't think there is any conflict between the two. One thought is coming to mind here after re-reading the posts. Is it possible a transaction is involved here? Is JTA in-use on the JVMs with these embedded brokers? If there are transactions, that could explain the failure to send messages and why only a certain number of messages are ever consumed. To clarify, sends in a transaction only take effect after the commit, and receives are only acknowledged on commit. Note that the connection factory setup in the posted activemq configs are not explicitly using transactions, which is good. Transactions could also explain an apparent lack of resumed flow on reconnect - the consumer would receive the same messages again on every reconnect and would stop at the same point. One way to tell - try the same setup with a stand-alone broker using the configs provided to see if it has the same problems. -- View this message in context: http://activemq.2283324.n4.nabble.com/JMS-to-JMS-Bridge-Connection-tp4684129p4684193.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
