If the drop-outs occur while there is heavy traffic flowing over the bridge, keep-alive packets are not even part of the problem. Keep-alive packets are only sent when the connection is idle for a period.
EOF Exception means "End-Of-File" on input, not a bad value read. In this case it means the underlying socket closed while the transport was waiting for traffic (messages, acknowledgements, keep-alive packets, etc); the side of the connection reporting the error unexpectedly lost the connection coming from the other side. Since the inactivity message appears, I suspect that leads to the EOF exception - one side decides the other is idle for too long and just drops the connection, then the other side complains the connection dropped unexpectedly. Which side is giving the EOF exception? The producing or consuming side of the bridge? Inactivity checking is on by default. Both sides of the connection perform Inactivity checks and send keep-alive packets. They are enabled by default. It is possible to disable them through settings (url-encoded parameters on the client side; not sure about the server-side); I do not recommend disabling them though - the checking is not the problem. One thing to check after a reconnect: see if the consumer to the destinations going over the bridge return on the configured destinations. The failover transport should automatically recreate them, but it's worth verifying. Note that's secondary to determining the cause of the inactivity timeouts since the timeouts point to a tangible, likely external, issue, but still valuable. -- View this message in context: http://activemq.2283324.n4.nabble.com/JMS-to-JMS-Bridge-Connection-tp4684129p4684151.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
