That helps a lot.
The inactivity timer fires when there is no communication between the
brokers for more than the timeout period (apparently 30 seconds); keep-alive
packets are used to prevent inactivity timeouts. So, the fact that
inactivity timeouts occur means that either the keep-alives are not doing
the job (turned off, interval is too great, bug, etc) or there is a network
issue preventing keep-alives from being delivered in a timely manner (packet
drops; excessive delays; etc).
I would pull out wireshark or tcpdump and monitor the traffic. If the
problem is hard to reproduce and takes a lot of time to recreate, this could
be tough.
The following debug message in the inactivity monitor can help to confirm
send of keep-alive packets:
no message sent since last write check, sending a KeepAliveInfo
One data point for consideration: this is an area of code that every user of
ActiveMQ that uses the openwire transport over TCP (a very high percentage)
uses continually; given that, it seems likely the broker code is solid at
this point. That's not meant to dismiss your report - it is just something
to consider.
Another possibility comes to mind, although it doesn't fit the symptom
description too closely -- if the JVM on the keep-alive-sending side of the
connection is performing Garbage Collection excessively, it's possible
delays in keep-alive sends could occur. The debug message mentioned above
would help to confirm the timing of the sends.
Hope this helps.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/JMS-to-JMS-Bridge-Connection-tp4684129p4684149.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
