[
https://issues.apache.org/jira/browse/AMQ-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQ-2526.
-------------------------------
Resolution: Fixed
Fix Version/s: 5.6.0
Fix applied in trunk, handle the interrupted exception and reset the thread's
interrupted state.
> Questionable processing of interruptions in TcpTransport::doStop
> ----------------------------------------------------------------
>
> Key: AMQ-2526
> URL: https://issues.apache.org/jira/browse/AMQ-2526
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.2.0, 5.3.0
> Reporter: Nick
> Fix For: 5.6.0
>
> Attachments: Test.java
>
>
> Imagine you are processing a few jobs by a thread pool. A timeout is set for
> the whole batch. A job should send a JMS message. If the timeout expires
> before all the jobs are completed the pool will interrupt still running jobs.
> Most of the time the interruption will be caught and processed deep inside of
> ActiveMQ TCP transport classes. While I'm not entirely convinced it's a good
> idea to shut down and reopen the connection to the ActiveMQ server if a
> client thread is merely interrupted what really seems ugly is:
> 15:12:53,745 ERROR [org.apache.activemq.transport.tcp.TcpTransport] Could not
> stop service: tcp:///x.x.x.x:61616. Reason: java.lang.InterruptedException
> java.lang.InterruptedException
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1200)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:245)
> at
> org.apache.activemq.transport.tcp.TcpTransport.doStop(TcpTransport.java:482)
> at org.apache.activemq.util.ServiceSupport.stop(ServiceSupport.java:69)
> at
> org.apache.activemq.transport.tcp.TcpTransport.stop(TcpTransport.java:499)
> at
> org.apache.activemq.transport.InactivityMonitor.stop(InactivityMonitor.java:113)
> at
> org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:64)
> at
> org.apache.activemq.transport.WireFormatNegotiator.stop(WireFormatNegotiator.java:87)
> at
> org.apache.activemq.util.ServiceSupport.dispose(ServiceSupport.java:43)
> at
> org.apache.activemq.transport.failover.FailoverTransport.handleTransportFailure(FailoverTransport.java:201)
> at
> org.apache.activemq.transport.failover.FailoverTransport.oneway(FailoverTransport.java:471)
> at
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
> at
> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
> at
> org.apache.activemq.ActiveMQConnection.doAsyncSendPacket(ActiveMQConnection.java:1214)
> at
> org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1208)
> at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1643)
> at
> org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:227)
> at
> org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:241)
> and the reason for it is that the await call on the CountDownLatch in
> TcpTransport::doStop will throws an InterruptedException if the calling
> thread is already interrupted. No attempt is made (in both 5.2 or 5.3) to
> gracefully process InterruptedException, the exception itself is logged as
> ERROR with a rather menacing message and the log file gets full of
> meaningless stack traces although no real harm was done.
> Calling latch.await(1,TimeUnit.SECONDS) in a try block seems like a
> no-brainer but there could be even smarted approaches to processing
> InterruptedExceptions differently than, say, IOEs and other genuine problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
