activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (Resolved) (JIRA)" <>
Subject [jira] [Resolved] (AMQ-2526) Questionable processing of interruptions in TcpTransport::doStop
Date Tue, 25 Oct 2011 21:22:32 GMT


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
> Questionable processing of interruptions in TcpTransport::doStop
> ----------------------------------------------------------------
>                 Key: AMQ-2526
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 5.2.0, 5.3.0
>            Reporter: Nick
>             Fix For: 5.6.0
>         Attachments:
> 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(
> 	at java.util.concurrent.CountDownLatch.await(
> 	at org.apache.activemq.transport.tcp.TcpTransport.doStop(
> 	at org.apache.activemq.util.ServiceSupport.stop(
> 	at org.apache.activemq.transport.tcp.TcpTransport.stop(
> 	at org.apache.activemq.transport.InactivityMonitor.stop(
> 	at org.apache.activemq.transport.TransportFilter.stop(
> 	at org.apache.activemq.transport.WireFormatNegotiator.stop(
> 	at org.apache.activemq.util.ServiceSupport.dispose(
> 	at org.apache.activemq.transport.failover.FailoverTransport.handleTransportFailure(
> 	at org.apache.activemq.transport.failover.FailoverTransport.oneway(
> 	at org.apache.activemq.transport.MutexTransport.oneway(
> 	at org.apache.activemq.transport.ResponseCorrelator.oneway(
> 	at org.apache.activemq.ActiveMQConnection.doAsyncSendPacket(
> 	at org.apache.activemq.ActiveMQConnection.asyncSendPacket(
> 	at org.apache.activemq.ActiveMQSession.send(
> 	at org.apache.activemq.ActiveMQMessageProducer.send(
> 	at org.apache.activemq.ActiveMQMessageProducerSupport.send(
> 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:!default.jspa
For more information on JIRA, see:


View raw message