| Summary: | Backport AtomicActionExpiryScanner to EAP4.3 [JBPAPP-2514] | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise SOA Platform 4 | Reporter: | Toshiya Kobayashi <tkobayas> | ||||
| Component: | EAP, Support Patch, Component Upgrade | Assignee: | trev <tkirby> | ||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 4.3 CP02 | CC: | dlesage | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 4.3 CP04 ER1 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| URL: | http://jira.jboss.org/jira/browse/SOA-1613 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-03-23 15:05:45 UTC | Type: | Feature Request | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Deadline: | 2010-03-08 | ||||||
| Attachments: |
|
||||||
|
Description
Toshiya Kobayashi
2009-11-18 01:58:12 UTC
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 |