Atomikos Forum |
|
Hi to all,
I'm getting the following error within an spring (batch) application: 2016-07-14 08:49:51,370 [midxMessageDrivenAdapter.container-1177] ERROR com.atomikos.datasource.xa.XAResourceTransaction logError 62 - Heuristic termination of XAResourceTransaction: 636D61625F746D313436383437383632363332373238343334:636D61625F746D3535363230 with state HEUR_HAZARD 2016-07-14 08:59:24,415 [Atomikos:1 ] WARN com.atomikos.recovery.xa.XaResourceRecoveryManager logWarning 24 - Error while retrieving xids from resource - will retry later... ...................... 2016-07-14 09:45:24,474 [Atomikos:1 ] WARN com.atomikos.recovery.xa.XaResourceRecoveryManager logWarning 24 - Error while retrieving xids from resource - will retry later... We received this Atomikos WARN-message since approximately 1h in intervals of 60sec AFTER we had got a short WebsphereMQ Error ('2009' ('MQRC_CONNECTION_BROKEN')). During this 1 hour the Atomikos WARN message appeared the application did nothing else, it seemed to be reposed. In our jta (transactions) properties we registered the following properties: com.atomikos.icatch.max_timeout=100000 com.atomikos.icatch.default_jta_timeout=60000 Used Version: Atomikos Transaction Essentials Version: 4.0.2 What could cause the stagnation (1 hour!!) of the application during Atomikos tried to receive the xids? Any helps are appreciate :-) Many thanks in adavance and regards, Bodo
Have you found a solution to this issue ?
I integrated Atomikos into my Spring Batch application yesterday. I have been getting the same warning : WARN XaResourceRecoveryManager - Error while retrieving xids from resource - will retry later... My application seems to work fine but this warning message keeps showing up at regular intervals in my logs. What does this warning mean ?
Hi Radhika,
unfortunately, no. And I really don't know what's happend behind the atomikos Framework when this message occured. It's really nebulous and you won't find anything within the documentation. And in my case the application seems to be stuck over one hour. This is quite an overkill for a batch application :-( I think i will swich to bitronix in the hope it is quite more robust. If you'll get any further information about the error please let me know. I will be very appreciate. Kind regards, Bodo
The 4.0 has new recovery so it can be expected that not everything is perfect yet.
The warning you're seeing should have an additional stack trace in the logs. If not, then please try with the latest 4.0.4. Please post that stack trace also. If this is blocking, then you can always consider a commercial subscription so we can look into this more quickly. Thanks!
I too face the similar issue, following is the message logged
WARN [Atomikos:1] com.atomikos.recovery.xa.XaResourceRecoveryManager - Error while retrieving xids from resource - will retry later... javax.transaction.xa.XAException at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:709) at com.atomikos.datasource.xa.RecoveryScan.recoverXids(RecoveryScan.java:32) at com.atomikos.recovery.xa.XaResourceRecoveryManager.retrievePreparedXidsFromXaResource(XaResourceRecoveryManager.java:158) at com.atomikos.recovery.xa.XaResourceRecoveryManager.recover(XaResourceRecoveryManager.java:67) at com.atomikos.datasource.xa.XATransactionalResource.recover(XATransactionalResource.java:451) at com.atomikos.icatch.imp.TransactionServiceImp.performRecovery(TransactionServiceImp.java:490) at com.atomikos.icatch.imp.TransactionServiceImp.access$000(TransactionServiceImp.java:56) at com.atomikos.icatch.imp.TransactionServiceImp$1.alarm(TransactionServiceImp.java:471) at com.atomikos.timing.PooledAlarmTimer.notifyListeners(PooledAlarmTimer.java:95) at com.atomikos.timing.PooledAlarmTimer.run(PooledAlarmTimer.java:82) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) DBMS is Oracle 11g 11.2.0.3.0 and driver is ojdbc6-11.2.0.4.jar. Please advice.
The reason would be that the recovery process tries to contact the XAResource every X minutes and fails to do so.
One possible would reason would be the grants: if the recovery process does not have access to the catalog tables where the transaction Xids are kept, then this would fail. Hope that helps
FYI - this issue has been fixed in the commercial distro after after a few customers ran into it and helped us diagnose: https://www.atomikos.com/Blog/ExtremeTransactions4dot0dot46
|