activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-2798) Occaional hangs on ensureConnectionInfoSent
Date Wed, 18 Aug 2010 21:48:48 GMT

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

Timothy Bish commented on AMQ-2798:
-----------------------------------

Version 5.4.0 adds a RequestTimeoutException that is thrown on timeout in ResponseCorrelator
so the NPE is not an issue any longer.

Currently the code is operating as designed, the case where the connection.start or createSession
is hanging is awaiting a response from the broker for its ConnectionInfo.  The case in which
this is happening in regards to this issue is when the Master broker is up but awaiting its
slave to start as well.  In this case the Master is there but it won't respond to the ConnectionInfo
and the connection breaks at which time the FailoverTransport tries again to connect.  This
explains why the maxReconnectAttempts and startupMaxReconnectAttempts don't apply here since
it is able to actually open a socket successfully to the Master broker, it just doesn't complete
the connect cycle because the master is awaiting its slave before it will allow any connections.
 Once the slave comes online and the Master completes its start-up then the Connection should
be established as normal.




> 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&amp;initialReconnectDelay=15000

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message