activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathieu Baril (JIRA)" <>
Subject [jira] Created: (AMQ-1569) Dead lock during XA recovery when activeMq 5.0.0 is used with Atomikos
Date Fri, 25 Jan 2008 18:33:25 GMT
Dead lock during XA recovery when activeMq 5.0.0 is used with Atomikos

                 Key: AMQ-1569
             Project: ActiveMQ
          Issue Type: Bug
    Affects Versions: 5.0.0
            Reporter: Mathieu Baril


I developed an application that runs in an OSGI environment (Equinox). My application is developed
using Spring Dynamic Modules 1.0-rc2, ActiveMq 5.0.0 and Atomikos 3.2.2.

Sometimes (50% of the time) when I start my application, the bundle that declare the connection
factories to the jms broker runs into deadlock.

This is the declaration of my connection factories:

<bean id="activemq.connectionFactory" class="com.trilliantnetworks.griffin.utils.CustomXAJMSConnectionFactory">
    <property name="brokerURL" value=" failover:(tcp://software2:61616,tcp://software1:61616)"
  <!-- Configure the JMS connector; call init to register for recovery! -->
  <bean id="atomikos.connectionFactory"
        class="com.atomikos.jms.TopicConnectionFactoryBean" init-method="init">
    <property name="resourceName" value=" jms.connectionFactory"/>
    <property name="xaTopicConnectionFactory" ref=" activemq.connectionFactory "/>
  <bean id="listen.jms.spring.singleConnectionFactory" class="org.springframework.jms.connection.SingleConnectionFactory"
    <constructor-arg ref="atomikos.connectionFactory "/>

Looking deeper in the code I found that the application block when init is called in com.atomikos.jms.TopicConnectionFactoryBean.

The init method calls the method isSameRM of org.apache.activemq.TransactionContext that eventually
calls waitForBrokerInfo in org.apache.activemq.ActiveMQConnection. The method blocks on brokerInfoReceived.await().
So I tried to found why brokerInfoReceived.countDown() is never called...

I found that this is because createTransportListener of org.apache.activemq.transport.failover.FailoverTransport
is sometimes called before the member variable transportListener was set. createTransportListener
is called by the Thread ActiveMQ Transport: tcp://software2/ while setTransportListener
is called by the main Thread that initialize my bundle.

I am unable to reproduce the issue with activeMQ 4.1.1 so I think that is issue has been introduced
with version 5.0.0.

Also, when I use the connection URL "tcp://software2:61616" instead of "failover:(tcp://software2:61616,tcp://software1:61616)"
my application always start correctly.

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

View raw message