[
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&initialReconnectDelay=15000
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
