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???