[jira] [Commented] (AMQ-6613) CLONE - CLONE - Occaional hangs on ensureConnectionInfoSent

["Roy Dar (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15892368#comment-15892368 ] 

Roy Dar commented on AMQ-6613:
------------------------------

I cloned since the original issue cannot be reopened.

Issue still happening in 5.13.0:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:403)
org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:48)
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:87)
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1381)
org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1495)
org.apache.activemq.ActiveMQConnection.start(ActiveMQConnection.java:522)

From the original AMQ-2798 I can see that the patch was never merged, for some reason it is marked as fixed in version 5.5.0 but there this issue is still happening.
From the cloned AMQ-6043 it seems it was closed as incomplete without any verification if the issue still exists (which it does)


> CLONE - CLONE - Occaional hangs on ensureConnectionInfoSent
> -----------------------------------------------------------
>
>                 Key: AMQ-6613
>                 URL: https://issues.apache.org/jira/browse/AMQ-6613
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.13.0
>            Reporter: Roy Dar
>            Assignee: Timothy Bish
>
> 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&amp;initialReconnectDelay=15000



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)