Fixes are available
Java SDK 1.5 SR8 Cumulative Fix for WebSphere Application Server
Java SDK 1.5 SR8 Cumulative Fix for WebSphere Application Server
Java SDK 1.5 SR10 Cumulative Fix for WebSphere Application Server
6.1.0.31: Java SDK 1.5 SR11 FP1 Cumulative Fix for WebSphere Application Server
6.1.0.33: Java SDK 1.5 SR12 FP1 Cumulative Fix for WebSphere
6.1.0.29: Java SDK 1.5 SR11 Cumulative Fix for WebSphere Application Server
6.1.0.35: Java SDK 1.5 SR12 FP2 Cumulative Fix for WebSphere
6.1.0.37: Java SDK 1.5 SR12 FP3 Cumulative Fix for WebSphere
6.1.0.39: Java SDK 1.5 SR12 FP4 Cumulative Fix for WebSphere Application Server
6.1.0.41: Java SDK 1.5 SR12 FP5 Cumulative Fix for WebSphere Application Server
6.1.0.43: Java SDK 1.5 SR13 Cumulative Fix for WebSphere Application Server
6.1.0.45: Java SDK 1.5 SR14 Cumulative Fix for WebSphere Application Server
6.1.0.47: WebSphere Application Server V6.1 Fix Pack 47
6.1.0.47: Java SDK 1.5 SR16 Cumulative Fix for WebSphere Application Server
6.1.0.9: WebSphere Application Server V6.1 Fix Pack 9 for Solaris
APAR status
Closed as program error.
Error description
::: SUMMARY ::: This symptom can be seen in below condition * Kill the TM2 in T6 status. Just before paticipant send back the "Prepared" to initiator. -> Pls see the ppt file sent to Ecurep . In this situation, "Peer recovery" function itself completes the transaction recovery properly, but the actuall ROLLBACK was done after AsyncResponseTimeout passed. . . <Expected Sequence> ￭Initiator ￭Paticipant *T6* (KILL) ROLLBACK ------------------> <------------------ HTTP/1.1 200 OK . <------------------ Avorted HTTP/1.1 200 OK ------------------> ROLLBACK FIRED . . <Actual Sequence> ￭Initiator ￭Paticipant *T6* (KILL) ROLLBACK ------------------> <------------------ HTTP/1.1 200 OK . <------------------ Avorted HTTP/1.1 200 OK ------------------> : : "wait till the AsyncResponseTimeout passed" : : ROLLBACK FIRED . . . In summerize, after sending ROLLBACK, and receiving ABORTED. But initiator didnt fire the Rollback promptly. It was fired after AsyncResponseTimeout would passed... . :: Question :: Do you think is it expected behavior? # We do think ROLLBACK operation should be fired right after respondi ng to ABORTED message. . . :: trace.log :: . You can see RollbackException was thrown after AsyncResponseTimeout 300000 have passed. . 1 SOAP Action:Prepare ( umi --> barca ) ￭1/9/07 13:22:55:656 JST 00000037 MessageTrace 3 WSWS3571I: Outbound HTTP SOAP request: 2 ￭1/9/07 13:23:15:152 JST 00000037 Configuration 1 getAsyncResponseTimeout 300000 3 SOAP Action:RollBack ( umi --> garuda ) ￭1/9/07 13:28:20:276 JST 00000037 MessageTrace 3 WSWS3571I: Outbound HTTP SOAP request: 4 ￭1/9/07 13:28:24:658 JST 00000037 Configuration 1 getAsyncResponseTimeout 300000 5 SOAP Action: Aborted ( garuda --> umi ) ￭1/9/07 13:28:45:303 JST 00000038 MessageTrace 3 WSWS3569I: Inbound HTTP SOAP request: 6 ￭1/9/07 13:33:24:719 JST 00000037 SystemErr R javax.transaction.RollbackException
Local fix
N/A
Problem summary
**************************************************************** * USERS AFFECTED: All Users of WebSphere Application Server * * version 6. * **************************************************************** * PROBLEM DESCRIPTION: Apparent delay in asynchronous response * * to 'aborted' messages in WS-AT * * processing * **************************************************************** * RECOMMENDATION: * **************************************************************** In WS-AT, the transaction initiator waits until asynchronous timeout has elapsed before responding to any incoming 'aborted' messages, rather than responding immediately. This situation occurs even if the initiator has received all outstanding asynchronous responses. The distributeOutcome() method in RegisteredResources class did not reset the asynchronous response counts. As a result, the response counts were never synchronised with the actual number of incoming responses, which meant that the trigger condition that processed the responses before the aynchronous timeout was fired could never be satisfied.
Problem conclusion
The distributeOutcome() method in RegisteredResources class was changed to correctly reset the number of outstanding asynchronous responses. The fix for this APAR is currently targeted for inclusion in fixpack 6.1.0.9 and 6.0.2.19. Please refer to the Recommended Updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
Temporary fix
Comments
APAR Information
APAR number
PK37481
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
61A
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2007-01-16
Closed date
2007-02-23
Last modified date
2007-02-23
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
WSAT
Fix information
Fixed component name
WEBS APP SERV N
Fixed component ID
5724H8800
Applicable component levels
R60A PSY
UP
R60H PSY
UP
R60I PSY
UP
R60P PSY
UP
R60S PSY
UP
R60W PSY
UP
R60Z PSY
UP
R61A PSY
UP
R61H PSY
UP
R61I PSY
UP
R61P PSY
UP
R61S PSY
UP
R61W PSY
UP
R61Z PSY
UP
Document Information
Modified date:
29 December 2021