Fixes are available
7.0.0.19: WebSphere Application Server V7.0 Fix Pack 19
7.0.0.21: WebSphere Application Server V7.0 Fix Pack 21
7.0.0.23: WebSphere Application Server V7.0 Fix Pack 23
7.0.0.25: WebSphere Application Server V7.0 Fix Pack 25
7.0.0.27: WebSphere Application Server V7.0 Fix Pack 27
7.0.0.29: WebSphere Application Server V7.0 Fix Pack 29
7.0.0.31: WebSphere Application Server V7.0 Fix Pack 31
7.0.0.27: Java SDK 1.6 SR13 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.33: WebSphere Application Server V7.0 Fix Pack 33
7.0.0.35: WebSphere Application Server V7.0 Fix Pack 35
7.0.0.37: WebSphere Application Server V7.0 Fix Pack 37
7.0.0.39: WebSphere Application Server V7.0 Fix Pack 39
7.0.0.41: WebSphere Application Server V7.0 Fix Pack 41
7.0.0.43: WebSphere Application Server V7.0 Fix Pack 43
7.0.0.45: WebSphere Application Server V7.0 Fix Pack 45
7.0.0.19: Java SDK 1.6 SR9 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.21: Java SDK 1.6 SR9 FP2 Cumulative Fix for WebSphere
7.0.0.23: Java SDK 1.6 SR10 FP1 Cumulative Fix for WebSphere
7.0.0.25: Java SDK 1.6 SR11 Cumulative Fix for WebSphere Application Server
7.0.0.27: Java SDK 1.6 SR12 Cumulative Fix for WebSphere Application Server
7.0.0.29: Java SDK 1.6 SR13 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.45: Java SDK 1.6 SR16 FP60 Cumulative Fix for WebSphere Application Server
7.0.0.31: Java SDK 1.6 SR15 Cumulative Fix for WebSphere Application Server
7.0.0.35: Java SDK 1.6 SR16 FP1 Cumulative Fix for WebSphere Application Server
7.0.0.37: Java SDK 1.6 SR16 FP3 Cumulative Fix for WebSphere Application Server
7.0.0.39: Java SDK 1.6 SR16 FP7 Cumulative Fix for WebSphere Application Server
7.0.0.41: Java SDK 1.6 SR16 FP20 Cumulative Fix for WebSphere Application Server
7.0.0.43: Java SDK 1.6 SR16 FP41 Cumulative Fix for WebSphere Application Server
Obtain the fix for this APAR.
APAR status
Closed as program error.
Error description
The websphere servant abends with ec3/0413007. In a particular case the http timeout was set to 1 hr and the request was hanging for 1 hr. The top of the java traceback looked like the following, Method ------ com/ibm/ws390/xmem/XMemSRCppUtilities.doFlushService com/ibm/ws390/channel/xmem/XMemWriteRequestContext.writeCommon com/ibm/ws390/channel/xmem/XMemWriteRequestContext.write com/ibm/ws/http/channel/impl/HttpServiceContextImpl.asynchWrite com/ibm/ws/http/channel/impl/HttpServiceContextImpl.sendOutgoing com/ibm/ws/http/channel/inbound/impl/HttpInboundServiceContextIm pl.sendResponseBody com/ibm/ws/webcontainer/channel/WCChannelLink.writeBufferAsynch com/ibm/ws/webcontainer/channel/WCChannelLink. writeBufferResponse com/ibm/ws/webcontainer/channel/WCChannelLink.writeBuffer com/ibm/ws/webcontainer/channel/WCCByteBufferOutputStream. flushWriteBuffer . . This can be seen after formatting the threads from the svcdump that is produced with the abend. There is a timing window in which if a request is destroyed for any reason before cleaning up the connection, the connection is destroyed but never released in the servant. This causes the servant to eventually time out due to a hang. This apar will address this problem.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM WebSphere Application Server * V7.0 * **************************************************************** * PROBLEM DESCRIPTION: A WebSphere for z/OS Application * * Server servant receives * * ABENDEC3/ABENDSEC3 with reason code * * 04130007. An examination of the svc * * dump will reveal one or more servant * * TCB's waiting with the following * * stack trace: * * * * com/ibm/ws390/xmem/XMemSRCppUtilities.d * * oFlushService * * XMemSRCppUtilities.java * * com/ibm/ws390/channel/xmem/XMemWriteReq * * uestContext.writeCommon * * XMemWriteRequestContext.java:636 * * com/ibm/ws390/channel/xmem/XMemWriteReq * * uestContext.write * * XMemWriteRequestContext.java:265 * * com/ibm/ws/http/channel/impl/HttpServic * * eContextImpl.asynchWrite * * HttpServiceContextImpl.java:2406 * **************************************************************** * RECOMMENDATION: * **************************************************************** During certain timing windows, where there is a deferred last chunk of request data, if the connection has been destroyed the waiting flag may be in an incorrect state resulting in issuing subsequent reads on the destroyed connection. This will result in the servant TCB being hung.
Problem conclusion
The code has been changed to reset the waiting flag to indicate when a connection has been destroyed to prevent waiting for additional deferred data to arrive in the servant from the destroyed connection. APAR PM39718 is currently targeted for inclusion in Service Level (Fix Pack) 7.0.0.19 of WebSphere Application Server V7.0. Please refer to URL: //www.ibm.com/support/docview.wss?rs=404&uid=swg27006970 for Fix Pack availability.
Temporary fix
Comments
APAR Information
APAR number
PM39718
Reported component name
WEBSPHERE FOR Z
Reported component ID
5655I3500
Reported release
700
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2011-05-20
Closed date
2011-06-07
Last modified date
2011-10-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
WEBSPHERE FOR Z
Fixed component ID
5655I3500
Applicable component levels
R700 PSY UK71297
UP11/09/10 P F109
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
Document Information
Modified date:
27 October 2021