Hide Forgot
Affects: Release Notes Date of First Response: 2009-11-27 08:07:48 Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/311053 project_key: SOA Current implementation of JBoss Transaction(4.2.3.SP5_CP05) for SOA-P 4.3.0_CP02 (EAP 4.3.0.GA_CP06) doesn't have a ExpiryScanner to clean up AtomicAction tx-logs. If there is an unrecoverable transaction (e.g. It might happen when JBoss instance is down before deleting tx-log after XAResource's commit is completed), periodic recovery will fail and WARN massages will be logged endlessly. ==== 2009-06-24 23:59:02,886 WARN [com.arjuna.ats.jta.logging.loggerI18N][com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa][com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource <131075, 31, 29, 1--53e1e740:1064:4a40cd21:2460b53e1e740:1064:4a40cd21:2460c
Link: Added: This issue incorporates JBPAPP-2514
EAP 4.3.0 CP07 is going to have AtomicActionExpiryScanner. But it's not complete. See my comment on JBTM-300
JBPAPP-2514 is now complete.
Steps to recreate bug: R+D added a unit test case (LogMoveTest.java)[1] which ensures the function. But in addition, I'd like to do a manual integration test in order to confirm that this one-off solves the problem which NTT encountered in SOA-P environment. The manual test procedure is like: ========= 1. Set up 2 SOA-P instances(ESB node and JMS node) and deploy a test ESB service. (I have a zip file which includes all stuff) 2. Start SOA-P instances. 3. Set a breakpoint on BasicAction.phase2Commit(boolean)[line2172:updateState()] using a debugger. 4. Invoke a test ESB client to start a transactional work. 5. After the ESB node stops at the breakpoint, kill(kill -9) the node. 6. Start the ESB node. 7. Priodic recovery (2min by default) kicks in. The following warning is logged because this is an unrecoverable transaction(Resources are already committed, but the tx-log remains) Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 30, 28, 1--3f57f59b:c51c:4a26721f:21b5-3f57f59b:c51c:4a26721f:21b6 > 8. [If the one-off works correctly] After the specified time (12hr by default), AtomicActionExpiryScanner should move the log to "Expired" directory. Then you can see the warning is not being logged any longer. ========== Yes, it's reproducible. Is this acceptable to QE team? It's a bit complex so I think I should test it by myself during the QE phase. [1] https://jira.jboss.org/jira/browse/JBTM-418 Regards, Toshiya
Added manual test instructions and files
Attachment: Added: manual-test.zip
Link: Added: This issue depends JBPAPP-3174
Link: Added: This issue is related to JBTM-418
Approved for SOA 4.3 CP03, but is dependent on inclusion into EAP 4.3 CP08 and the ability to include EAP 4.3 CP08 into SOA 4.3 CP03 per schedule.
JBPAPP-2514 has been resolved in EAP 4.3 CP07. So including EAP 4.3 CP07 will satisfy this JIRA.
ER1 contains EAP 4.3 CP07 so marking as resolved
The draft text for the Resolved Issues section of the Release Notes states: https://jira.jboss.org/jira/browse/JBPAPP-3174 The transaction functionality did not have an ExpiryScanner, (needed to "clean up" AtomicAction transaction logs). As a consequence, if a transaction could not be recovered, the periodic recovery mechanism would fail and an endless stream of WARN messages would be logged. An ExpiryScanner has now been backported. It cleans up the logs, meaning that the recovery mechanism is now much more reliable as a result.
Verified in ER1 - EAP 4.3 CP07 is base for SOA-P