[jboss-dev-forums] [JBoss AS 7 Development] - Re: connecting a remote hornetQ server

andrzej sochal do-not-reply at jboss.com
Thu Sep 13 10:03:09 EDT 2012


andrzej sochal [https://community.jboss.org/people/anso2] created the discussion

"Re: connecting a remote hornetQ server"

To view the discussion, visit: https://community.jboss.org/message/759409#759409

--------------------------------------------------------------
I have a similar problem. My scenario is as follows:
Messages are being sent from jboss-4.2.1.GA to a remote stand alone hornetq-2.2.14.Final.
There is an MDB deployed on jboss-7.1.1.Final node that listens to the remote stand alone hornetq-2.2.14.Final queue.
Everything seems to be working fine up to the point where there is a disconnection 
between jboss 7 node and hornetq. For example, when hornetq is shut down and then brought back up, jboss
jboss 7 is not able to reconnect to hornetq. Jboss 4 on the other hand is able to send messages to hornetq but messages are not
being consumed by MDB.


This warning happens every two minutes on jboss 7 node:

2012-09-13 07:59:26,904 WARN  [com.arjuna.ats.jta] (Periodic Recovery:) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Error
 trying to connect to any providers for xa recovery
        at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:275)
        at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:77)
        at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:503)
        at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:471)
        at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:385)
        at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:166)
        at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)
        at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)
Caused by: java.lang.IllegalStateException: Cannot create session factory, server locator is closed (maybe it has been garbage collected)
        at org.hornetq.core.client.impl.ServerLocatorImpl.assertOpen(ServerLocatorImpl.java:1823)
        at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:699)
        at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:321)
        at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:251)
        ... 7 more




After doing some research, I found that:

HornetQXAResourceWrapper located in JBOSS_HOME\modules\org\hornetq\main\hornetq-jms-2.2.13.Final.jar
is trying to connect to HornetQ in this method:
 public XAResource getDelegate(boolean retry){
  XAResource result = null;
     Exception error = null;
     try
     {
 *result = connect();*
     }
     catch (Exception e)
     {
       error = e;
     }
     ...


 The connect method is getting ServerLocatorImp object and calls createSessionFactory method on it


    ... 
    this.serverLocator = xaRecoveryConfig.getHornetQConnectionFactory().getServerLocator();
    this.serverLocator.disableFinalizeCheck();
    this.csf = this.serverLocator.createSessionFactory();
    ...


The createSessionFactory method of ServerLocatorImpl (hornetq-core-2.2.13.Final) is checking for ServerLocator state.
If it is NOT null and NOT initialized then it throws this exception.



    if (state != null && state != STATE.INITIALIZED)
    {
         throw new IllegalStateException("Cannot create session factory, server locator is closed (maybe it has been garbage collected)");
    }


When I manually change state to null, this exception is no longer thrown and the state gets initialized again.



When there is a disconnection, it looks like state gets set to CLOSED which is triggering this exception. 
Instead, shouldn't state be set to NULL on disconnect to allow for reconnections. 
Is this a bug???
--------------------------------------------------------------

Reply to this message by going to Community
[https://community.jboss.org/message/759409#759409]

Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2225]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20120913/9fc6367d/attachment.html 


More information about the jboss-dev-forums mailing list