[
https://issues.apache.org/activemq/browse/AMQ-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61289#action_61289
]
Anish Khanzode commented on AMQ-2798:
-------------------------------------
I see that 5.4.0 behaves better. Is there any property that controlls the
timeout? Additionally I see excessive logging in this situation and activemq
takes over CPU.
Here is the exception:
2010-08-19 09:39:17,090 INFO
[org.apache.activemq.broker.TransportConnection.Transport] Transport failed:
java.io.IOException: The transport is not running.
java.io.IOException: The transport is not running.
at
org.apache.activemq.transport.TransportSupport.checkStarted(TransportSupport.java:107)
at
org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:179)
at
org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:244)
at
org.apache.activemq.transport.TransportFilter.oneway(TransportFilter.java:85)
at
org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:104)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
at
org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1247)
at
org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:808)
at
org.apache.activemq.broker.TransportConnection.dispatchSync(TransportConnection.java:768)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:187)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:69)
at
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
at
org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:217)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:219)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:201)
at java.lang.Thread.run(Thread.java:619)
> Occaional hangs on ensureConnectionInfoSent
> -------------------------------------------
>
> Key: AMQ-2798
> URL: https://issues.apache.org/activemq/browse/AMQ-2798
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
> Affects Versions: 5.3.2
> Reporter: Mark Chaimungkalanont
> Attachments: blocked-connection-patch3
>
>
> When connecting to the broker, the client occasionally starts to hang. A
> thread dump reveals:
> {noformat}
> "QuartzScheduler_Worker-7" prio=5 tid=0x0116f190 nid=0x1ce2400 waiting on
> condition [0xf1fae000..0xf1fafb30]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1767)
> at
> java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:341)
> at
> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40)
> at
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:80)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1233)
> at
> org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1339)
> - locked <0x10b9bdf8> (a java.lang.Object)
> at
> org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:298)
> at org.jencks.amqpool.SessionPool.createSession(SessionPool.java:110)
> at org.jencks.amqpool.SessionPool.makeObject(SessionPool.java:78)
> at
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:974)
> at org.jencks.amqpool.SessionPool.borrowSession(SessionPool.java:53)
> at
> org.jencks.amqpool.ConnectionPool.createSession(ConnectionPool.java:89)
> at
> org.jencks.amqpool.XaConnectionPool.createSession(XaConnectionPool.java:51)
> at
> org.jencks.amqpool.PooledConnection.createSession(PooledConnection.java:132)
> at
> org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:200)
> {noformat}
> Looking closer at the code of {{ensureConnectionInfoSent}} in
> {{ActiveMQConnection}}, it uses the method:
> {code}
> public Response syncSendPacket(Command command) throws JMSException {
> {code}
> which never times out, possibly causing everything to hang eternally. There
> does seem to be an identical method that allows for a timeout.
> {code}
> public Response syncSendPacket(Command command, int timeout) throws
> JMSException {
> {code}
> should / can ensureConnectionInfoSent use the one with the timeout instead?
> We're using the failover transport:
> failover:(tcp://<someIP>:54663?wireFormat.maxInactivityDuration=300000)?maxReconnectAttempts=10&initialReconnectDelay=15000
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.