Posted: Fri Dec 20, 2013 2:12 am Post subject: JBoss EAP 6.2/WMQ 7.5: The method 'xa_recover' has failed
Newbie
Joined: 18 Dec 2013 Posts: 2
I have a simple application with a trivial MDB deployed into JBoss EAP 6.2 together with the resource adapter wmq.jmsra.rar from Websphere MQ 7.5.0.2.
After JBoss started the following exception is logged in JBoss' server.log every two minutes:
Code:
17:05:32,556 INFO (Controller Boot Thread) JBAS015874: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) started in 38835ms - Started 683 of 759 services (75 services are passive or on-demand)
17:07:33,763 WARN (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_INVAL: javax.transaction.xa.XAException: The method 'xa_recover' has failed with errorCode '-5'.
at com.ibm.mq.jmqi.JmqiXAResource.recover(JmqiXAResource.java:806)
at com.ibm.mq.connector.RecoveryXAResource.recover(RecoveryXAResource.java:448)
at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.recover(XAResourceWrapperImpl.java:177)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:709)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)
I tested the following combinations:
(a) JBoss EAP 6.2 / wmq.jmsra.rar 7.5.0.2 -> Exception
(b) JBoss EAP 6.2 / wmq.jmsra.rar 7.5.0.1 -> Exception
(c) JBoss EAP 6.2 / wmq.jmsra.rar 7.0.1.5 -> No Exception
(d) JBoss EAP 6.1 / wmq.jmsra.rar 7.5.0.1 -> No Exception
I debugged a little bit and it seems that EAP 6.1 does not call the XA revocery at all which would explain (c).
The other combination seem to imply that something changed in the resource adapter between 7.0 and 7.5.
It is relatively easy to reproduce this behavior with any application with an MDB and minimal configuration changes against the delivered configuration file.
It can do done with the following steps (if anybody wants to reproduce this behavior):
(1) Deploy wmq.jmsra.rar and an EAR containing an MDB
(2) Setup MDB section in standalone-full.xml to use wmq.jmsra.rar as resource adapter
(3) Setup resource adapter section in standalone-full.xml with at least an admin-object for the MDB in your application
Code:
<resource-adapters>
<resource-adapter id="wmq.jmsra.rar">
<archive>
wmq.jmsra.rar
</archive>
<transaction-support>NoTransaction</transaction-support>
<connection-definitions>
<!-- Not necessary to reproduce this problem -->
</connection-definitions>
<admin-objects>
<admin-object class-name="com.ibm.mq.connector.outbound.MQQueueProxy" jndi-name="mdb-request-queue-jndi-name" pool-name="mdb-request-queue--pool-name">
<config-property name="baseQueueManagerName">
wmq-hostname
</config-property>
<config-property name="baseQueueName">
mdb-request-queue-name
</config-property>
</admin-object>
</admin-objects>
</resource-adapter>
</resource-adapters>
(5) Start JBoss against the edited standalone-full.xml and wait about two minutes for the first exception to appear
Maybe
- there is a problem in my configuration
- or it could be a problem in MQ
- or in JBoss (which I would consider less probable because of the above working/non-working combinations)
- or the exception be safely ignored
Any hints are greatly appreciated. If any further information is needed I will gladly try to provide it.
The last method in the stack above - JmqiXAResource.recover() - is called twice during the recovery scenario:
From
- XARecoveryModule.periodicWorkFirstPass
- XARecoveryModule.periodicWorkSecondPass
It seems that the JmqiXAResource instance between these two calls is different.
But from what I understand there should be some "state" between the first and the second pass which is of course lost if a new/another instance of JmqiXAResource is used in the second pass.
So yes, to me it looks also like an issue in the code but my knowledge in that area is too limited to decide that.
Therefore I will probably raise a support request after the christmas season unless somebody else raises another idea on this topic.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum