[
https://issues.apache.org/jira/browse/AMQ-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599373#comment-13599373
]
Edwin Yu edited comment on AMQ-2798 at 3/11/13 9:58 PM:
--------------------------------------------------------
Hi SuoNayi,
Thank you for your feedback. Your second point about soTimeout is a valuable
suggestion for me to try! Since this issue happens rarely for us, I will tell
if this will fix our case over time.
About your first point, I'm confused. We're using the "shared storage
master/slave". The slave is simply standby and keeps trying to grab the
distributed file lock. The master has no knowledge of the slave(s). The Jms
clients (the mule connectors in our case) can establish connections only to the
master. I don't follow when you said "you can not talk to the master which the
slave is not attached." Or am I mistaken somewhere?
Thanks.
was (Author: windeyu):
Hi SuoNay,
Thank you for your feedback. Your second point about soTimeout is a valuable
suggestion for me to try! Since this issue happens rarely for us, I will tell
if this will fix our case over time.
About your first point, I'm confused. We're using the "shared storage
master/slave". The slave is simply standby and keeps trying to grab the
distributed file lock. The master has no knowledge of the slave(s). The Jms
clients (the mule connectors in our case) can establish connections only to the
master. I don't follow when you said "you can not talk to the master which the
slave is not attached." Or am I mistaken somewhere?
Thanks.
> Occaional hangs on ensureConnectionInfoSent
> -------------------------------------------
>
> Key: AMQ-2798
> URL: https://issues.apache.org/jira/browse/AMQ-2798
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
> Affects Versions: 5.3.2
> Reporter: Mark Chaimungkalanont
> Assignee: Timothy Bish
> Fix For: 5.5.0
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
