You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Nick (JIRA)" <ji...@apache.org> on 2009/12/09 03:37:53 UTC
[jira] Created: (AMQ-2526) Questionable processing of interruptions
in TcpTransport::doStop
Questionable processing of interruptions in TcpTransport::doStop
----------------------------------------------------------------
Key: AMQ-2526
URL: https://issues.apache.org/activemq/browse/AMQ-2526
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 5.3.0, 5.2.0
Reporter: Nick
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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2526) Questionable processing of interruptions
in TcpTransport::doStop
Posted by "Nick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick updated AMQ-2526:
----------------------
Attachment: Test.java
> Questionable processing of interruptions in TcpTransport::doStop
> ----------------------------------------------------------------
>
> Key: AMQ-2526
> URL: https://issues.apache.org/activemq/browse/AMQ-2526
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.2.0, 5.3.0
> Reporter: Nick
> 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.
-
You can reply to this email to add a comment to the issue online.