Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
5.10.0
-
None
-
None
-
ActiveMQ client running in Karaf container
Description
ActiveMQ 5.10.0 client connects to broker with failover protocol and fails to stop from Karaf console in case of massive sending job. Here is the important part of a stacktrace:
17:31:17,254 | WARN | pool-47-thread-5 | FailoverTransport | sport.failover.FailoverTransport 260 | handleTransportFailure | Transport (tcp:///192.168.210.36:61616@57522) failed, reason: , attempting to automatically reconnect
java.io.InterruptedIOException
at org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:102)[418:ru.icl.osgi.TestMOMFailover:0.3.9]
at org.apache.activemq.transport.failover.FailoverTransport.oneway(FailoverTransport.java:658)[418:ru.icl.osgi.TestMOMFailover:0.3.9]
at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)[418:ru.icl.osgi.TestMOMFailover:0.3.9]
at org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:81)[418:ru.icl.osgi.TestMOMFailover:0.3.9]
at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:86)[418:ru.icl.osgi.TestMOMFailover:0.3.9]
at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1406)[418:ru.icl.osgi.TestMOMFailover:0.3.9]
at org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:2018)[418:ru.icl.osgi.TestMOMFailover:0.3.9]
at org.apache.activemq.ActiveMQMessageProducer.<init>(ActiveMQMessageProducer.java:125)[418:ru.icl.osgi.TestMOMFailover:0.3.9]
at org.apache.activemq.ActiveMQSession.createProducer(ActiveMQSession.java:1048)[418:ru.icl.osgi.TestMOMFailover:0.3.9]
.....
17:31:17,267 | INFO | ActiveMQ Task-2 | FailoverTransport | sport.failover.FailoverTransport 1057 | doReconnect | Successfully reconnected to tcp://192.168.210.78:61616
I've found that FailoverTransport.handleTransportFailure() method considers ANY exception as a transport failure. After that it successully reconnects and job continues running.
But InterruptedIOException is the consequence of an external job interruption and not of a transport failure.
So adding the next snippet into the head of FailoverTransport.handleTransportFailure() method became a solution for me:
if (e instanceof InterruptedIOException) {
throw new InterruptedException("handleTransportFailure is interrupted due to " + e.getMessage());
}
I've looked at the 5.14.1 sources a little bit and it seems they have the same problem toŠ¾.